Which AI agent architecture fits a high-stakes workflow?

01Start with one agent, and know when to stop

Anthropic's guidance on building agents recommends starting with the simplest solution possible and adding complexity only when it is needed. LangChain's multi-agent documentation makes a similar point: a single agent with well-chosen tools and prompts often performs comparably. Multi-agent designs pay off when one agent struggles with too many tools, needs deep domain context, or must follow sequential constraints.

We agree, and we turn those points into a test we run before splitting anything:

1. 01

   Tool count. When one agent holds dozens of tools across unrelated domains, it starts picking the wrong one. Routing errors show up as plausible actions in the wrong place, which is worse than an obvio

2. 02

   Domain depth. When each step needs its own rules, vocabulary and data, one prompt becomes a long list of exceptions that nobody can review with confidence.

3. 03

   Sequential constraints. When steps must happen in order and some may never be skipped, such as identity checks before approvals, the order should be enforced by the system, not remembered by a model.

4. 04

   Different owners. When different teams or roles own different steps, each step needs its own tests and its own audit record.

If none of these apply, keep one agent. If two or more apply, split the work.

02What a supervisor AI agent architecture looks like

In a supervisor design, a coordinating agent reads the request and decides which specialist should handle it. Each sub-agent has a narrow job and a short tool list. Anthropic describes a related pattern, orchestrator-workers, where a central model breaks a task down, delegates the parts to worker models and combines their results.

In practice, regulated products often combine the second and third rows. They use a fixed lifecycle that the system enforces, with a narrow agent doing the work inside each stage, and a supervisor only where requests arrive in free form.

03The contract every sub-agent needs

Splitting work into agents only helps if each agent is a well-defined unit. For each one we write down five things:

• Input contract: exactly what the agent receives, such as a document set scoped to one deal or one property, the user's role and the current state of the record.
• Tool allowlist: which real endpoints of your product it may call, and nothing else.
• Structured output: a schema the next step can validate, not free text. Risk findings, for example, come back as flags that reference their inputs.
• Decision point: where a person confirms, approves or rejects, and what happens to the work on rejection.
• Evaluation set: test cases for this agent on its own, plus routing tests for the supervisor that sends work to it.

This turns agents into components your team can review. A new engineer can read one contract and understand one job. A reviewer can see which agent produced which output. An auditor can follow a decision from the input documents to the person who approved it. For more on why agents break when these pieces are missing, see why AI agents fail in production.

04Managing the cost of many agents

The weaknesses of a supervisor design are real. Each extra agent is another prompt to maintain, another set of tests and another place for routing to go wrong. Agent counts also tend to grow once stakeholders see what one agent can do, and every new idea becomes a new agent.

We manage that in three ways. First, every new agent must justify itself against the test above, not against a new idea for the next demo. Second, routing gets its own evaluation: a set of requests with the expected agent for each, run on every change to any prompt or tool. Third, we trace every run, so when a user reports a problem we can see which agent was called, with which input, and which tool it used. Without tracing, a multi-agent system turns debugging into guesswork.

There is also a handover question. A product team that inherits a set of narrow agents can own them one at a time. A team that inherits one large agent has to understand all of it before changing any of it. If your team will run the system after launch, that difference matters more than any benchmark.

05Where the human decision sits

Narrow agents make human control easier to place. Instead of one agent that might do anything, you have a known list of actions, and you can decide for each action whether the AI suggests, drafts or acts. We use a simple rule: anything that commits money, changes a legal or compliance status, or sends a message to an outside party is drafted by AI and confirmed by a person. Everything else can be automated once its tests are stable. Some products let a user switch a specific job to automatic after they trust it, which keeps the default safe without blocking experienced users.

06What we see in production

For a regulated private investment marketplace, we kept the existing .NET application and its SQL Server database as the system of record. We built AI as separate services around it, connected through APIs rather than direct database access. Each step of the deal lifecycle got its own agent with a narrow job. The jobs are parsing pitch decks and deal documents into a structured deal template, market analysis, investor matching, investor communication and document generation. The design grew from five agents in the original scope to about seventeen, which is exactly the sprawl risk described above.

What kept it manageable was the boundary. AI never approves a deal, a KYC check or tokenization. It produces structured outputs and recommendations, the AI-generated deal sits side by side with the human-entered one, and a pre-publish gate needs human confirmation. Every risk output is traceable to its inputs and stored for audit.

For a short-term rental operations platform, we moved an embedded assistant from one agent to a supervisor that routes to domain agents for properties, cleaning, bookings, inventory, user management and onboarding. Later each channel and role got its own compiled graph and tool allowlist, so cleaners can only act on their own jobs while owners and managers have separate tool sets. In shared property channels, a decision node decides whether the AI should reply at all.

Contractor outreach is drafted for the owner and sent only after approval, unless the owner switches that job to automatic. Testing runs in tiers: unit tests on every push, routing evaluations, and model-graded quality evaluations, with traces in LangSmith and CloudWatch. In a log-verified QA review, reported bugs were traced to the exact tool calls behind them, which fed the fixes that followed. The client later reported that its app and AI agent were live.

The pattern in both builds is the same. Narrow agents are not the goal. Testable, auditable steps are the goal, and narrow agents are how you get them.

Most of these failures only show up under real traffic, which is why we also wrote about why AI agents fail in production and what to check before launch.

Frequently asked questions