One Agent, a Suite, or an Agentic Workflow?

AI-Enabled Teams & Agent Ecosystems — 2 of 13

Three quite different things get called “an agent”. They cost different amounts to run, fail in different ways, and demand different things from the organisation. Placing a proposal on that scale is the whole of what a leader needs from the architecture — and it takes two questions.

In my work I have sat in this meeting countless times — and so, probably, have you. A supplier presents. The slides say agentic. Someone asks whether it is secure and is told yes. Someone asks about accuracy and is given a number. Forty minutes later the meeting ends, generally favourable, and not one person in the room could say what shape the thing is.

That is the gap this briefing closes. Not so you can evaluate an architecture — that is not your job unless you are the actual architect or engineer — and if it is not, you should be suspicious of anyone who suggests it is. So that you can establish, early and in plain language, which of three arrangements you are being offered. Because the answer decides what it costs to run, what can happen while nobody is watching, who has to own it afterwards, and how much of the rest of this series applies to you.

The demo answers a different question

A vendor demonstration shows a capable system doing a legible task under conditions the vendor chose. That is not dishonest; it is what a demo is for. But it can only tell you what the system can do. It cannot tell you whether that fits work nobody in the room has yet described.

This is why so many pilots impress everyone and change nothing. The technology was never the constraint. The constraint was that nobody had decided which work was in scope, what the system was permitted to do, who would catch it when it was wrong, and who would still be accountable a year later.

Those questions do not disappear when a purchase order is signed. They arrive later, with less time to answer them — usually during an incident, and usually landing on somebody who was not in the meeting.

Years of coaching software product teams showed me this constraint from the inside — most often, perhaps especially, with teams building for a supposedly defined user. Ask them to narrate that user’s actual day — how they move through the system, where the media breaks sit, the points where information leaves one screen and gets retyped into another — and the room goes quiet. The product still has to be finalised for the demo, so the client is shown a one-size-fits-all solution; the rare good product manager intercepts the demo exactly where it hurts that client today, but I saw that rarely. The teams that changed were the ones that worked one real case through, step by step, with named owners — the discipline the Use-Case Canvas teaches — and building agentic systems is the same work. Only when it is clear what happens, what must change, what can be deleted, and who owns each step does “agentic” earn a place in the conversation.

Shape one: a constrained assistant

One agent, a clear brief, a small set of tools, used by a person who stays in the work. It drafts the supplier summary, compares the three proposals, prepares the pack, reformats the evidence. The human does the job; the agent shortens parts of it.

What makes this shape forgiving is structural, not a matter of care: its output goes to a person before it goes anywhere else. A bad answer is a bad paragraph in a draft. The blast radius is one document and one reader.

What it still asks of you is modest but not nothing. Somebody has to decide what it may read and which sources count as authoritative. And somebody should expect it to be used for work outside its brief, because it will be — a tool that is good at summarising supplier documents gets pointed at contracts by the end of the month. That drift is the main risk in shape one, and it is a management question rather than an architectural one.

Most of the real value available to most teams this year sits here. It is also the one shape where the people who live with the work can explore without an engineer: a constrained assistant is how an operations team discovers, cheaply and reversibly, what a later suite or lane would even be for.

Shape two: a role-specific suite

Several specialised agents around one role, each with its own brief and boundary. For a Tester: a test generator, a regression runner, a data-quality checker, an evidence collector. For an Organizer: one that prepares status, one that chases, one that assembles the weekly report.

The human is still in the work, but the job has changed. They are no longer using a tool; they are coordinating several, and the coordination is now part of the role. That is the cost most proposals understate.

Because the interesting failure in a suite is rarely inside any one agent. Each does its own job correctly, and the mistake lives in the seam: the checker validates data the generator never used; the evidence collector gathers against last quarter’s criteria; two agents hold different versions of what “done” means and neither is wrong on its own terms. Nobody is watching the seam, because the seam was not assigned to anyone.

Teams running suites in earnest treat the seam as a design object. FundFrame, a small Copenhagen software team, deliberately has different models review one another’s output, precisely because an agent reviewing its own work carries the blind spots that produced it (FundFrame, March 2026). Independence at the seam does not happen; it is assigned.

Each agent added is another brief to maintain, another thing to evaluate when a model or a policy changes, and another identity with permissions. Four agents is not four times the work of one. It is four agents plus the relationships between them.

Shape three: a bounded workflow lane

A repeatable process where steps hand off to each other and the ordinary case completes without a person in the middle. Refund requests under a threshold are classified, checked and settled. Routine supplier records are validated and updated. The person appears at the exception, not at every case.

This shape exists well below enterprise scale. EMES Kabelbaum Konfektion, a Saxon switchboard manufacturer, is building precisely such a lane for order entry — email to ERP in seven steps, with a traffic light doing the routing: green books automatically, yellow stops for a person, red goes manual (Mittelstand-Digital Zentrum Chemnitz, 2026). Note the order of decisions: before the lane enters its proof of concept, the firm had already refused a cloud calculation route because margin data does not leave the company. The lane’s boundary was settled before its capability was tested.

This is the only one of the three that is meaningfully agentic in the sense the word is usually being sold, and the only one that can act while nobody is looking. Everything changes at that line.

A lane needs explicit routing, stop rules, escalation triggers, logging that someone actually reads, an evaluation set that says whether it is still good after a change, and a named person who operates it — not the person who championed it. It also needs an answer to a question the other two shapes never raise: what does this do at 2am on a bank holiday when the case is strange?

None of that is a reason to refuse a lane. It is the price of one, and a proposal that has not priced it is not finished.

Two questions that place any proposal

You do not need the architecture. You need the shape, and two questions get you there.

In my work, those two questions took years to compress. My method in these meetings was to play the character who says: explain that to me again, in plain English, as if I were not technical — which I am not. Ask that often enough, across enough technologies, and the same pattern surfaces every time, whatever is being sold. The two questions below are that pattern, written down; the four maps in the opening briefing are its longer form.

  1. Does anything take effect without a person seeing it first? Yes means shape three, whatever the slides call it. No means one or two.
  2. Does any part of this depend on another part’s output rather than on a person’s? Yes means shape two or three. No means shape one.

Ask them in that order, and insist on examples rather than principles. “There’s always a human in the loop” is an answer about intent; “the confirmation email sends automatically once the claim clears the threshold” is an answer about the system. If the person presenting cannot give you the second kind, that is itself the finding — and it is worth saying out loud in the room rather than in the follow-up email.

More agents is not more capability

There is a strong instinct in organisations to read the three shapes as a maturity ladder: the assistant is where you start, the lane is where serious companies end up. The evidence does not support that. Single-purpose production lanes exist across industries; evidence that suites and orchestrated arrangements pay for themselves barely exists at all outside software engineering — as the opening briefing set out. It is worth being able to say so with something behind it.

Researchers at UC Berkeley built the first taxonomy of multi-agent system failures by annotating traces across seven widely used frameworks. They found fourteen distinct failure modes in three categories: system design, inter-agent misalignment, and task verification (Why Do Multi-Agent LLM Systems Fail?). Two of those three categories do not exist until you have more than one agent. The message a leader should carry into the room: in their analysis, the failures traced to design — specification, coordination, verification — not to weak models; added structure has to earn its keep.

Anthropic’s own guidance for the engineers building these systems makes the same argument from the other direction: find the simplest solution possible, and increase complexity only when it demonstrably improves outcomes, because agentic systems trade latency and cost for task performance (Building Effective AI Agents).

And from inside an enterprise running agents at volume, Dropbox reports the same economics in operation: with roughly one pull request in twelve now agent-produced, the bottleneck did not disappear — it moved downstream into review, validation, testing, release coordination and operations (Dropbox Tech, May 2026). Capacity added by agents is capacity somebody must absorb.

Our own operation shows the same economics at the smallest possible scale. PathPatron runs on several agents, and still rarely ships more than two credible briefings in a day — because every output waits for my quality check, and the agents often sit idle for hours until I get to it. More output is easy; validated output moves at the speed of the person validating — and unlike code, a briefing has no test suite. The check is a person. Adding agents to that arrangement would not add speed. It would add queue.

Read those together and the leadership position becomes straightforward. Complexity is not a sign of ambition. It is a cost that has to be justified against a benefit somebody can name, and the burden of proof sits with the person proposing the larger shape.

Shape is not the same as authority

The two get collapsed constantly, and separating them removes most of the fear from the conversation.

A workflow lane is not autonomous by definition. It is a lane, and you decide what happens inside it. The useful design is rarely “agent or automation” but an order:

Automation prepares, an agent interprets, a person decides, automation executes what the person approved.

That is a lane — it has hand-offs, it runs as a process, it is shape three — and a person sits at the only step that carries consequence. The shape tells you what you have to build and operate. The authority question — a later briefing in this Path takes it up properly — tells you where the human sits inside it.

European regulation is clearer on this than most internal policies are. The AI Act’s human-oversight duty for high-risk systems is that a person must be able to understand the system, intervene in it, and stop it — Article 14 — and it does not require that a human approve every individual decision before it takes effect. Effective oversight is a property of how the system is designed, not a quantity of sign-off. Teams that respond to agent risk by routing everything through an approval queue usually get the worst of both: the throughput of manual work and the attention of nobody. Whether any given system is high-risk under the Act is a question for your own counsel and your own use case; the design principle is worth borrowing regardless.

Zalando’s engineers built that principle and published the numbers. Their approval bot rates every code change low, medium or high risk against rules derived from the company’s own incident history; a third of changes are auto-approved, and lead time to merge fell by 20–40% (Zalando Engineering, August 2026). Their own caveat is the useful part: AI amplifies good and bad practices alike — teams that let changes grow large found them stalling in review until working habits adjusted. Oversight designed as routing rather than as a queue, and the routing taught the behaviour it rewarded.

What each shape obliges you to

The same four obligations exist in all three shapes. What changes is how much they cost, and that difference is the argument for choosing the smallest shape that does the work.

  • An owner. Shape one: the person using it. Shape two: a named coordinator for the set, not just for each part. Shape three: a funded operating owner, distinct from the champion, with a deputy for August.
  • Evaluation. Shape one: does the person using it still find the output good. Shape two: the same, per agent, plus the seams. Shape three: a defined set of cases re-run whenever anything changes — the model, a policy, a source, a threshold.
  • Monitoring. Shape one: none needed beyond ordinary use. Shape two: enough to see which agent produced a wrong answer. Shape three: a record of what actually happened, read on a schedule by somebody, because nobody was present when it happened.
  • A way to stop. Shape one: close the tab. Shape two: turn off one agent without breaking the others. Shape three: a stop that someone at the working level can use immediately, without first building a case for it.

That last one deserves emphasis. A stop right that requires escalation is not a safety control. It is a request form.

Four questions for the person proposing it

Whether the proposal comes from a supplier, an internal team or an enthusiastic colleague, these four move a presentation into something you can govern.

  1. Which of the three shapes is this, in one sentence? Hesitation here is informative. So is an answer that changes when you ask question three.
  2. What can it reach, and under whose identity? An agent inherits whatever its identity can do, including things nobody intended. Security practitioners have a name for an agent granted more than its task needs — excessive agency — and it sits in OWASP’s top risks for LLM applications (OWASP GenAI Security Project). “It uses a service account” is the beginning of the answer, not the end of it.
  3. Name three cases this handles without a person present, and one it must never handle that way. The second half matters more than the first. A proposal with no answer to it has not been scoped; it has been imagined.
  4. Who runs this in six months, and how would we switch it off? If the answer is the champion’s name, you have a pilot. Pilots are fine. They should be called pilots.

Choose the smallest shape that does the work

The instinct to reach for the largest shape is understandable — it looks like commitment, and it demos beautifully. It is also the reliable route to a system nobody can explain, evaluate or retire.

Start from the work, which you mapped before any of this began (Map the Work Before You Automate It). Take the smallest shape that handles it. Move up only when you can say what the larger shape buys and who will carry what it costs. A team running one well-understood assistant that people trust is in a materially stronger position than a team running an orchestrated lane that three people understand and nobody owns.

That is the PathPatron stance on architecture. You are not choosing a technology. You are choosing how much organisation you are willing to build around it — and that choice belongs to you, not to the person holding the slides.

The next six briefings take the Transformer roles one at a time — Transformers being the Compass’s six delivery roles: people, not the neural-network architecture — and work this through where it actually lands: what shifts for the Owner, the Organizer, the Creator, the Implementer, the Tester and the Maintainer, and which of these three shapes each of them should be asking for.