Skip to main content
Gateway can help an application obtain an AI answer. It does not decide whether the application should accept that answer, pursue another business action or declare the work complete. That boundary lets the same execution engine support a simple authenticated client and a larger professional-work system without pretending that their responsibilities are identical.

​
One inference versus one piece of work

Consider an illustrative task: classify an invoice and prepare a proposed journal entry. A model call may produce a classification and suggested fields. The task still needs an owner to review the result, decide whether to accept it and authorize any posting. Gateway handles the inference: choose a compatible approved offering, execute within the permitted limits and report the outcome. It does not acquire authority to post the journal just because the model returned a tool-call description. Tool-call output is data. Executing the proposed tool is a separate authorized action.

​
Recovery is not an autonomous business loop

Gateway may make a permitted technical recovery attempt inside the original call. The attempt must satisfy the original plan, remaining budget, current authority and output rules. The task owner may separately decide that another inference is useful—for example, asking a new question after reviewing an incomplete result. That is deliberately new work, with a distinct durable identity and the owner’s aggregate limits. It is not a way to reset the old call’s budget invisibly.

​
Closing a viewer is not always cancelling work

A browser can be an observer of a durable task. Closing that browser does not necessarily revoke the task owner’s mandate. In other profiles, the HTTP response stream itself owns the call and its closure ends that ownership. The applicable ownership contract decides which signal cancels execution. Gateway must follow the real owner rather than assume that every disconnected viewer has cancelled the underlying work.

​
Why the separation matters

Without this boundary, a model success could be misreported as task fulfillment. A retry could silently become a new business decision. A generated tool request could be mistaken for permission to cause an external effect. With the boundary, each owner can answer its own question. Gateway reports model execution. The application evaluates and stores its result. The work owner manages the commitment. The tool and financial owners establish their own effects. The reviewed AccelMars arrangement uses Guild/Platform callers, with interim commitments remaining Guild-owned. Work/Execution is a target ownership arrangement where an accepted implementation transfer applies; it is not activated simply by appearing in a diagram. Continue with A model call inside a larger task or Restarting without repeating the work.