Separate Model, Agent, Workflow, and Team

Terms aren't for theory. They show where control lives, who holds state, and which component is responsible for stopping. Confuse them and you hide control flow where it can't be checked.

Entity · What it does · Where control is · Typical mistake

• Model call - Turns input into output; In the application code; Treating any answer as an autonomous agent
• Workflow - Runs a known graph of steps; In code or a workflow engine; Giving the model a choice you could express as a condition
• Agent - Chooses tools and the next step in a loop; The model within set boundaries; Not setting a stop condition and a budget
• Multi-agent system - Coordinates several agent loops; Supervisor, router, handoff, or a shared protocol; Confusing message exchange with useful cooperation

The OpenAI Agents SDK defines orchestration as the decision of which agents run, in what order, and who chooses the next step, and explicitly separates model-driven orchestration from orchestration via code, allowing them to mix. So choosing several agents doesn't require handing the model the whole control flow.

The same idea is convenient to see as a cycle centered on the application's control plane.

The control plane belongs to the application. It checks contracts, limits the number of calls, grants rights, saves events, and decides whether the result can be accepted. An agent may propose the next step but must not widen its own authority or budget.

A practical boundary. If you replace the model with a stub function and routing, budget, state, and acceptance still work, you have a controllable system. If all behavior is hidden in one huge prompt, you have a demonstration, not a reliable control plane.

The concepts are separated. But before assigning agents, the task must be decomposed into a graph - an agent executes a node, it doesn't decompose the work.