When Agent Architecture Is Too Much

When I built a multi-agent system that kept working across long-running jobs, the extra architecture solved real problems. It preserved ownership. It also gave results an explicit path back.

Then the bill arrived.

There were more endpoints to maintain, more state to inspect, and more callbacks to trace. A request could move correctly through the system and still fail at delivery. Recovery required more care because a blind retry could repeat work. A Practical Architecture for Reliable Multi-Agent Systems explains the larger model whose costs this article tests.

That experience changed my default. I no longer ask how much agent architecture I can add. I ask which failure I need to prevent, and what the lightest useful structure would be.

This article offers a practical test for that choice. For a closer explanation of goal-driven loops, read Loop Engineering: Goals, Feedback, and Better Agent Prompts.

Use the practical rule first

A task does not need a governed service layer just because several agents touch it.

Suppose one agent gathers sources, another checks claims, and a third edits the draft. That may sound like a multi-agent service. Yet the work could still have one clear owner and one predictable path.

In that case, a small workflow graph may be enough. It can show the order, retry a failed step, and return the final draft to the owner.

The opposite is also true. A workflow with only two roles may need a service boundary. One role may own a financial decision while another can only move data. If their authority must remain separate, the number of roles is not the main issue.

I use four questions to find the real problem:

1. Can one prompt produce the answer the work needs?
2. Does one owner need to pursue a goal through action, feedback, and verification?
3. Is the path predictable enough to describe as stages, branches, and joins?
4. Does work cross continuing owners, authority boundaries, distinct contexts, or a return obligation that one loop or graph cannot hold safely?

Those questions lead to a prompt, a loop, a graph, or a governed service layer. I call the last choice autonomous systems engineering when it also gives owners a way to recover, find help, and improve later work.

Use a loop when one owner can hold the whole job

An agent loop gives one owner a goal, a way to act, feedback to inspect, and a way to know when to stop. It is the right starting point when one owner can hold the full task.

Consider a customer-feedback summary. Its goal is a short, source-checked report that reaches the product team. The agent collects new comments, groups the themes, checks the sample, writes the report, and sends it. If the source is unavailable, it reports the gap and stops. The same loop might run daily, but the schedule is only the trigger.

That loop still needs discipline. It needs a stopping rule, an evidence standard, and a clear delivery step. It may also need a human gate for unusual findings.

It probably does not need standing service addresses, cross-owner callbacks, or a separate lifecycle tracker. Those parts would create work without solving an observed problem.

A loop is enough when the same owner can answer four questions:

• What does this request mean?
• What work should happen next?
• Is the result good enough?
• Where must the result go?

If all four answers fit in one stable context, keep the loop simple.

Use a graph when the path needs to be visible

A workflow graph earns its place when the process has a stable shape. It makes steps, branches, joins, pauses, and terminal states explicit.

For example, an article may move through drafting, source review, editing, approval, and publication. A sensitive claim can branch to legal review. A rejected draft can return to editing.

The graph gives operators something useful: visible process state. They can see where a run stopped and which step should follow.

That visibility has a cost. Every branch needs a condition. Every state needs a meaning. Every retry needs a rule. Changing the real process also means changing the graph.

Still, this is usually cheaper than adding a system of standing roles. Use a graph when the main failure is hidden sequence or unclear workflow state. Do not add separate roles unless the work also has an ownership problem.

Add a governed service layer only after two gates pass

My decision test for a governed service layer has two gates. Both should pass.

Gate One: The work needs continuing ownership beyond one path

At least one boundary must matter beyond the current run:

• Different owners must preserve separate knowledge or responsibility.
• One role may transport a request but may not approve its meaning.
• Work must survive after the caller or a temporary worker disappears.
• Several products need the same stable owner over time.
• Delivery is a separate obligation that needs evidence.
• An unfamiliar failure may require the owner to ask a tooling, integration, or operations role for help.
• The system needs to carry that diagnosis into a later run, guide, test, or graph change.

These are not prompt-quality problems. They concern ownership, authority, continuity, return paths, recovery, and learning.

Gate Two: The Failure Costs More Than the Architecture

The boundary must protect something worth operating.

Ask what happens without it. Does work get silently duplicated? Can an unapproved result trigger an external change? Will an unfinished request be lost after a restart? Could a completed answer sit in storage while the requester waits?

Then compare that risk with the ongoing burden. An autonomous system layer needs clear roles, ways to ask for help, compact tickets, callbacks, recovery rules, delivery receipts, and a place to capture learning. Someone must test and maintain those parts.

If the likely failure is a minor delay, the service layer may cost more than it saves. If the failure can create an unauthorized change or lose important work, the weight may be justified.

Count the operating costs before you build

Architecture is easy to justify on a diagram. Its daily costs are less visible.

In our case, these were not theoretical concerns. The architecture created more endpoint generations, callback complexity, latency, and opportunities for stale context. Recovery also became harder.

That does not make the design wrong. It means the benefits need to be concrete.

Watch for signs that the pattern is premature

I would pause before building a governed service layer if several of these signs appear:

• The product is still changing enough that nobody can state the normal path.
• One agent already has the context and authority to own the result.
• The team has not observed lost ownership, unsafe authority, or failed delivery.
• The proposed roles mostly rename steps that belong in a graph.
• Nobody is responsible for ticket cleanup, recovery, or endpoint rotation.
• Success is still measured by whether workers produced files.
• The design adds persistent agents to improve answer quality alone.

The last sign matters. More standing roles do not automatically produce better answers. Better instructions, evidence checks, or review may improve quality with much less machinery.

Another warning sign is a diagram with many boxes but no named failure. If each component cannot state what it prevents, it may be architecture by analogy.

The heavier pattern is justified in specific cases

Some work really does need a governed service layer.

Imagine a recurring market report used by several products. A research owner interprets the question and integrates evidence. A separate approval owner controls sensitive claims. Temporary workers gather data, but they cannot approve publication. The requester may disconnect while the report runs.

Here, a governed service layer protects meaningful boundaries. The public entry point provides a stable address. The owner remains accountable for the answer. Authority stays with the approval role. A compact ticket preserves the obligation. An explicit callback returns work to the responsible owner. The public entry point then delivers the owner-approved result and records the handoff.

If a source connection fails in an unfamiliar way, the research owner can ask an integration role for help instead of ending the run at a generic error. The recovery should then leave a lesson for the next run or a change to the known graph.

Long-running operational work can justify the same pattern. If a worker may disappear after making partial progress, the system needs enough evidence to recover safely. Blind replay may duplicate changes. A completed response file is also not proof that the requester received it.

The architecture earns its cost when it makes those failures visible and recoverable.

Add one boundary at a time

A governed service layer does not need to arrive as a complete control plane.

Start with the smallest missing boundary. Give the work one semantic owner. Add an explicit callback path when results must return to that owner. Record a compact ticket if the request must survive a stopped caller.

Add locks only when overlapping work is possible. Add deduplication when equivalent requests can enter twice. Add lifecycle tracking when open obligations are otherwise hard to see. Add governed recovery when normal retries become unsafe.

Each addition should answer a failure you can describe.

This staged approach also gives you a useful exit test. If a component has no operator, no meaningful state, and no failure it prevents, remove it from the design before it becomes a dependency.

My practical rule

The short version is simple:

One owner, repeated work
  -> use a loop.

Several predictable stages
  -> use a graph.

Several continuing owners, authority boundaries, or requester-return obligations
  -> add a governed service layer.

Complex product with all three needs
  -> combine the layers, but keep their jobs separate.

This is not a maturity ladder. A loop is not an early version of an autonomous system. It may be the finished design.

In the end, good architecture is proportionate. Add structure when it preserves ownership, authority, delivery, recovery, or learning. Otherwise, let one clear owner do the work and keep the path short.