Skip to main content
BiltIQ AI logoBiltIQ AI logo
Back to Blog
Agentic AI

One agent can't do it: why orchestration matters

The most common failure in agentic deployments is not a bad model. It is one general agent, given every tool and no budget, in a loop. It wanders, it loops, it over-reaches, and it cannot be debugged.

BiltIQ AI
7 min read

The demo works. That is the problem.


The most common failure in agentic deployments is not a bad model. It is one
general agent, given every tool and no budget, in a loop.

Single-agent demos are convincing precisely because a capable model with a broad
tool set handles a scripted task beautifully. The failure arrives later, at the
point where the task is real, the goal is under-specified, and nobody is
watching the trajectory.

Here are the four ways it goes wrong. Each one is a symptom of a specific
missing constraint, which is the useful part — they are not mysteries, they are
consequences.

It wanders

With a broad tool set and an under-specified goal, an agent explores. Every
individual step is locally reasonable and the trajectory as a whole is not.

Ask for exposure on an account. The agent searches for the account. It finds a
parent company and looks that up too. That surfaces a group structure, so it
starts mapping subsidiaries. Twenty steps later it is producing a corporate
family tree and has not looked at a single contract.

No step was wrong. There was simply nothing bounding the shape of the work.

Missing constraint: a step budget, and a role narrow enough to make the next
action obvious.

It loops

A tool returns something unhelpful, the agent retries with a small variation,
and the variation is not enough to change the result.

Search returns nothing. Try a synonym. Nothing. Try the plural. Nothing. Try it
capitalised. A person hits this and concludes after the second attempt that the
document is not there. An agent has no such instinct — from inside the loop,
each retry is a fresh reasonable idea.

The cost lands in two places: tokens, and the user waiting for an answer that
was never coming.

Missing constraint: a circuit breaker that halts on a repeating pattern rather
than waiting for the budget to run out.

It over-reaches

Given access to everything, an agent uses everything — including data the
requesting user was not entitled to see.

This one is worth stating carefully, because nothing malfunctions. The agent
does exactly what it was built to do: find relevant material and use it. If the
scope was never drawn, everything is in scope. The user asks a reasonable
question and receives an answer informed by the acquisition model, the salary
band, or another department's client file.

And it is invisible in testing, because the people running the pilot usually
have broad access.

Missing constraint: per-project scope isolation, enforced below the agent
rather than requested in its prompt.
A constraint expressed in a prompt is a
suggestion to a language model. A constraint enforced in the retrieval layer is
a boundary. The difference is not stylistic; it is whether an eloquent input can
argue its way past it.

It cannot be debugged

When a fifty-step trajectory produces a wrong answer, "which step went wrong"
has no cheap answer if every step had the same identity and the same
permissions.

You have a transcript. It is long, plausible-sounding throughout, and wrong at
the end. Somewhere in the middle a retrieval returned a superseded document and
everything after that inherited the error — but every step looks as reasonable
as every other, because they were all produced by the same undifferentiated
thing.

Missing constraint: named roles. When a wrong answer belongs to
contract-reader rather than to "the agent", the search space collapses.

What orchestration actually means

Not "more agents". Smaller ones, with explicit limits.

  • Role-scoped agents, each with the smallest useful tool set. This improves
    accuracy for a mundane reason — fewer choices per step — and makes failures
    attributable.
  • Explicit step and token budgets, turning an unbounded process into a
    bounded one.
  • Circuit breakers that halt on repetition instead of waiting for exhaustion.
  • Per-project scope isolation, enforced beneath the agent.
  • Authenticated delegation between agents. When one agent asks another to
    act, that is a privilege question — and without authentication, a successful
    prompt injection escalates from producing a bad answer to issuing instructions
    another agent executes with its own permissions.

That last point is the one most often missing elsewhere, and it is a security
control rather than a formality.

What it costs, because it does cost something

Orchestration is its own failure surface. More agents means more handoffs,
and handoffs lose context. A fact established in step two may not survive into
the agent handling step five unless something deliberately carries it.

Budgets truncate. A task that genuinely needed more steps returns an
incomplete answer, and the budget is the reason. That is the correct trade — an
incomplete answer you can see is better than an unbounded loop you cannot — but
it is only correct if the system says so. An answer cut short by a budget must
be distinguishable from an answer that is complete. Silently truncated output is
worse than either.

Scope isolation blocks legitimate questions. Someone will need to ask
something spanning two projects, and the system will refuse. Widening that scope
is an access-control decision, not a configuration convenience, and it should
feel like one.

And sometimes one agent is right

Multi-agent decomposition assumes the task decomposes. Some do not.

Forcing a decomposition onto a task that is genuinely one continuous piece of
reasoning produces worse results than one competent agent with a larger budget —
you have added handoffs, context loss and coordination overhead to buy nothing.

Single-step tasks are the clearest case. Draft an email, summarise this
document, classify this ticket. Agents add latency, cost and failure surface for
no benefit. Call the model.

Knowing which is which is judgment, not configuration, and anyone selling you a
framework that decides it automatically has not deployed one.

The question to ask a vendor

"What happens when your agent has been running for forty steps?"

If the answer is that it keeps going until it finds something, you are being
sold a demo. If the answer describes a budget, a breaker and what the user sees
when either fires, you are being sold infrastructure.


👨‍💻

BiltIQ AI

Expert team at BiltIQ AI providing cutting-edge AI solutions.

Contact our team →
Share this article:

Book an Architecture Consultation

30 minutes. No sales pitch. We assess your current stack, identify where agentic AI creates measurable value, and give you a concrete deployment path — with timelines and costs.

Your Data. Your Premises. Your AI.