Most people meet AI systems through prompt engineering. You give a model a task, useful context, and a clear output format. For one question, that can be enough.
The design changes when the work keeps coming back. It crosses teams. It hits a bad source, a wrong tool, a missing permission, or a result that finishes somewhere nobody sees. Each surprise becomes a fresh human intervention unless the system has a way to hold the work, find the right help, and return an answer.
That is the practical value of a multi-agent system. Not a collection of chats with impressive names. A way to keep a real job moving without losing the owner, the evidence, or the person who asked for it.
Four ways to engineer agent work
I find it useful to separate four design choices.
| Practice | What it designs | The question it answers |
|---|---|---|
| Prompt engineering | One request, its context, and the response you want. | What should the model do right now? |
| Loop engineering | Goal-directed action, observation, correction, verification, and learning. | How can one owner work toward this goal until the evidence says to stop? |
| Graph engineering | Known states, transitions, branches, joins, and recovery paths. | Which step should run next? |
| Autonomous systems engineering | A governed service layer around persistent owners, their authority, their return paths, and the control machinery that supports them. | Who owns cross-owner work, how can the system recover, and how does the answer get back? |
The last term is my editorial framing, not settled industry language. I use it for the layer above a loop or graph: a system where several continuing owners can accept work, coordinate it, recover from trouble, and improve the next run without losing accountability.
Adaptive help is one benefit. If a research owner uses the wrong API command, a graph can take a repair branch that already exists. A governed service layer gives the owner another option: ask the tooling owner for a diagnosis, bring that answer back into the work, and record the lesson for later. The system still has rules and approval limits. It simply does not treat every unplanned problem as the end of the job.
Loop Engineering: Goals, Feedback, and Better Agent Prompts goes deeper on the goal-and-feedback layer.
Choose the lightest structure first
Do not start with a fleet of agents. Start with the failure you need to prevent.
Use a prompt when one answer is enough. Add a loop when one owner needs feedback and iteration. Use a graph when the path should be visible and predictable. Add the service layer when work crosses continuing owners, authority boundaries, distinct contexts, or a requester-return obligation.
Those are not maturity levels. A graph is often the clearest answer. A small loop is often better than a service architecture. The larger system earns its cost only when a simpler arrangement leaves an important job unowned or unrecoverable.
When Agent Architecture Is Too Much is the full adoption test. When an Agent Needs to Be a Service, Not a Chat helps with the next decision: which roles deserve a continuing identity at all.
One request, several responsibilities
Once work passes among roles that keep their own context, it helps to separate the jobs.
If WordPress does not render Mermaid, read the diagram this way: a requester sends work through a request runtime to a public entry point. That entry point routes the work to one accountable owner. The owner may use private specialists or temporary workers. The approved result returns through the public entry point, which attempts delivery and records the handoff.
The diagram is not a prescription for a large organization. It is a way to avoid asking one role to be receptionist, domain expert, project manager, worker, historian, and messenger all at once.
| Responsibility | What it does | What it must not become |
|---|---|---|
| Request runtime | Records and moves requests, callbacks, and compact state. | The domain decision-maker. |
| Public entry point | Accepts a known route and returns an approved result. | The expert for every domain. |
| Owner | Interprets the request, chooses work, integrates evidence, and stands behind the answer. | A generic message relay. |
| Private specialist | Supplies recurring focused expertise to the owner. | A public shortcut around the owner. |
| Temporary worker | Does a focused piece of substantial or project-specific work. | A permanent service because it completed one task. |
| Lifecycle tracker | Keeps open obligations, update points, and recovery posture visible. | A second domain owner. |
| Delivery | Gets the approved result to the intended person or system. | An implied side effect of a completed task. |
The terms can change. The boundaries should not.
Transport moves work; the owner gives it meaning
The runtime can record a request, route it to the right role, and record a response. That is valuable. It still does not know whether the research is sufficient, whether a release is safe, or whether a result should be sent to a customer.
One owner has to make those calls. That owner may ask a specialist for advice or start a temporary worker for a larger task. Those returns are evidence, not automatic final answers.
The same boundary protects authority. Being able to send a message to a role does not grant permission to use its tools, change a system, or make an external commitment. The receiving owner checks the request against its own authority and can accept, narrow, ask for input, or reject it.
Transport Is Not Ownership explains the responsibility model. Authority Should Not Travel with the Prompt turns that principle into practical authority contracts and safe dispositions.
A result is not finished until someone receives it
Long-running work needs more than a background task. The system should create a compact ticket before work starts, prevent accidental duplicate admissions, protect a continuing agent context from conflicting turns, and leave a trustworthy trail if a worker fails.
The owner also needs an explicit return path. A worker response is not automatically delivered to the person who asked. The owner must accept the result, the public entry point must return it, and the system should record what happened next.
That is why these states are different:
work executed
!= owner accepted it
!= callback returned
!= requester received it
!= the result was usefulReliable Agent Work Needs Tickets, Locks, and Recovery covers the operational controls. Done Is Not Delivered follows the final leg to the requester.
Build, operate, and improve the system deliberately
An agent service is more than a prompt. It has a role definition, project context, interface, working instructions, model profile, current live identity, and a way to return work. The live system also needs several kinds of state in the right places: source definitions, compact runtime records, task-session context, substantial work, and reusable knowledge.
Creating or changing that system should happen in stages. Source code can define a role before any live endpoint exists. A new endpoint can exist before it has been validated. A routing test can pass before the system has produced useful work for a real requester. Keeping those claims separate makes changes easier to inspect and safer to reverse.
The system should also learn on purpose. A completed run can leave a closeout, a manager can look for a pattern, and larger changes can become reviewed proposals instead of quiet edits to the operating model.
For the Codex implementation pattern, read Building One Agent from Coordinated Roles in Codex and How to Layer AGENTS.md for Real Agent Work. Where an Agent System Keeps Its State, The Proof Ladder for AI Systems, How to Make an Agent System Learn, and How to Change an Agent System Without Breaking Live Work cover the operating side.
What this architecture is for
No architecture makes agents infallible. An owner can still choose the wrong specialist. A graph can still meet a path nobody planned. A delivery receipt can prove a handoff without proving the result helped.
The value is more practical. When recurring work meets a real problem, the system can show where the problem sits, keep the obligation visible, bring the right owner into the decision, return a result to the requester, and preserve a useful lesson for later.
That is the standard I would use: not whether a group of agents can talk to itself, but whether a real job can survive surprise without losing ownership, authority, evidence, or the human at the end.
Continue by reader need
Choose a structure
- When Agent Architecture Is Too Much
- Loop Engineering: Goals, Feedback, and Better Agent Prompts
- When an Agent Needs to Be a Service, Not a Chat
Design the boundaries
- Transport Is Not Ownership in Multi-Agent Systems
- Authority Should Not Travel with the Prompt
- Done Is Not Delivered: The Missing Leg in Agent Workflows
Build and operate
- Building One Agent from Coordinated Roles in Codex
- How to Layer AGENTS.md for Real Agent Work
- Where an Agent System Keeps Its State
- Reliable Agent Work Needs Tickets, Locks, and Recovery
- The Proof Ladder for AI Systems