Agentic AI vs AI agents: the distinction that changes your architecture

The agentic AI vs AI agents distinction is not a naming argument. An AI agent is a component: a model given tools and a loop so it can act. Agentic AI is a property of a system, describing how much control flow the model decides at run time. Every increment of that autonomy changes your architecture.

Agentic AI vs AI agents: the difference stated plainly

An AI agent is a software component. It is a language model wired to a set of tools, somewhere to keep state, and a loop that decides on each pass whether to call another tool or stop and return. That is the whole definition. It is a noun, it lives in a repository, and you can point at the file.

Agentic AI is not a bigger or better agent. It is a property of a system, and the property is measurable in a single question: how much of the control flow is decided by a model at run time rather than by a developer at design time. A system is more agentic when the model picks the next step. It is less agentic when the code picks it. A deterministic workflow with a single classification call in the middle contains a model but is barely agentic at all, because a developer wrote every branch.

That is why the comparison feels slippery when you read it as a head-to-head. The two terms sit at different levels of the stack. Asking whether to build AI agents or agentic AI is close to asking whether to build a function or concurrency: one is a thing you write, the other describes how the things you wrote behave together.

Four adjacent terms carry most of the weight in practice, and it is worth stating them as facts before going further.

Tool calling, also written as function calling, is the mechanism by which a model returns a structured request to invoke a named function with typed arguments, which your code then executes and feeds back. Nothing in tool calling is autonomous on its own. The autonomy arrives from what you do with the result.

A ReAct loop is the pattern where a model alternates between producing a reasoning step and producing a tool call, using each observation to choose the next action, until it decides it is finished. This is the smallest structure most people mean when they say autonomous agent.

A planner-executor splits that into two roles: one model call produces a plan as data, and separate calls execute each step against that plan, so the plan itself can be inspected, stored, edited and resumed. The plan becomes an artefact rather than a hidden chain of reasoning.

A multi-agent system is a system in which more than one such loop runs, each with its own prompt, tool set and context, coordinated by something. When that something is another model deciding which agent runs next, you have a supervisor agent, and the system is meaningfully more agentic than a pipeline that hands work between the same agents in a fixed order.

Anthropic's engineering guidance draws the same line in different words, separating workflows, where language models and tools are orchestrated through predefined code paths, from agents, where language models dynamically direct their own processes and tool usage. Its stated recommendation is to find the simplest thing that works and add complexity only when the simpler version demonstrably fails.

So the useful question is never which label applies to what you are building. The useful question is how much autonomy you are granting, because every increment of autonomy is a bill you pay somewhere else in the system.

The autonomy dial, and what each position costs

Treat autonomy as a dial with five stops rather than a switch with two. Each stop removes a decision from your code and hands it to a model, and each one adds something you now have to build that you did not need before.

The fourth column is the one that decides your on-call rota. A deterministic workflow fails with a stack trace you can reproduce by replaying the same inputs. A supervised multi-agent system fails with a trajectory, and the same inputs may not produce the same trajectory twice. That difference is not a detail. It changes how you write tests, how long an incident takes to diagnose, and how confident you can be that a fix worked.

There is a second cost that shows up on the invoice. Anthropic reported in its engineering write-up of 13 June 2025 that agents typically use about four times more tokens than chat interactions, and multi-agent systems about fifteen times more. That multiple is the honest price of moving two stops to the right, and it is worth knowing before you design rather than after the first month's bill.

Which architecture does your task shape actually need?

This is the table to keep. The columns are chosen so that reading a row gives you a decision rather than a description: what the work looks like, what to build, what it costs to operate, and what it costs when it breaks at two in the morning.

Two rows carry most of the traffic in real projects: the second and the third. A great deal of what gets sold as agentic AI in 2026 belongs in row two, which is a state machine with one intelligent step in it.

The last row exists because it gets skipped. If the work is a single question answered from retrieved context, retrieval augmented generation and one model call is the whole design. Wrapping it in a loop adds latency and a failure mode without adding capability.

How much of this needs to be agentic at all?

Most teams reading a comparison of agentic AI vs AI agents should build a deterministic workflow with one tool-using model step, and not a multi-agent system. We sell agentic AI development and that is still the honest answer, because the alternative costs us more in support than it earns in fees.

The reason is structural. A deterministic workflow pays inference cost only at the decision points a developer chose, and every other step is ordinary software with ordinary testing. An agent pays inference at every step and makes the sequence itself a variable. If the sequence of a process is stable enough to write down, writing it down as a state machine is cheaper to run, cheaper to observe and cheaper to explain to an auditor than asking a model to rediscover the same sequence on every execution.

Ask one question of the process before you decide: has anyone written the steps down, and do they hold for at least four cases in five? If yes, the agentic part is the exception handler, not the main path. That inverts the usual design, and it is the design that survives contact with production. Our longer treatment of where AI agents replace a rules engine works through the process-selection side of this in detail.

The evidence from research points the same way. Cemri and colleagues, in "Why Do Multi-Agent LLM Systems Fail?" presented at NeurIPS 2025, built a failure taxonomy from 150 execution traces and identified 14 distinct failure modes grouped into three categories: system design issues, inter-agent misalignment, and task verification. Their expanded dataset covers more than 1,600 annotated traces across seven multi-agent frameworks. The finding that matters for architecture is that a large share of failures come from how the system was put together rather than from the capability of the underlying model. Adding a better model does not fix a coordination bug.

A useful sanity check before any agentic build: can you describe the desired behaviour as a finite set of states and transitions? If you can, build that, and put the model inside the transitions that need judgement. If you genuinely cannot, and you have tried, then you have a real case for an agent.

If you are holding a proposal that specifies a multi-agent system and you are not sure it needs one, our agentic AI development team will read the process description and tell you which of the seven rows above it belongs in. That review is free and it frequently ends with us recommending less software than the proposal contains.

What is the Model Context Protocol, and what does it standardise?

The Model Context Protocol, usually written MCP, is an open protocol that standardises how language model applications connect to external data sources and tools. It uses JSON-RPC 2.0 messages between three roles defined in the MCP specification: hosts, which are the applications that initiate connections; clients, which are the connectors inside a host; and servers, which are the services that expose context and capabilities. An MCP server offers resources, which are context and data, prompts, which are templated messages and workflows, and tools, which are functions the model can execute. An MCP client is the connector inside the host that holds one connection to one server, which is why a host running six integrations runs six clients. Clients may offer elicitation back to servers, meaning a server can ask the user for additional information mid-task.

Stated as a single sentence for anyone quoting it: MCP is the agent-to-tool layer, and it standardises how one agent reaches a tool or a data source, not how two agents talk to each other.

The current revision is dated 2026-07-28, and its changes are architectural rather than cosmetic. The protocol core became stateless: the initialize and notifications/initialized handshake is gone, session identifiers are gone, and each request carries protocol version and client information in its metadata. Server-initiated requests over an open stream were replaced by Multi Round-Trip Requests, where a server returns a result type of input_required with the questions it needs answered and the client retries with the answers attached. Streamable HTTP requests must now carry Mcp-Method and Mcp-Name headers so gateways and web application firewalls can route without parsing the JSON body. List results for tools, prompts and resources became cacheable, carrying ttlMs and cacheScope. Authorisation moved towards RFC 9207 issuer validation and Client ID Metadata Documents in place of dynamic client registration. Long-running work moved into a formal Tasks extension under io.modelcontextprotocol/tasks, with polling and durable handles. The project also committed to a twelve-month minimum window between deprecating a feature and removing it.

Why this matters to an architecture decision rather than to a changelog reader: a stateless MCP server is an ordinary HTTP service. It scales behind the load balancer you already run, it survives a restart without dropping a session, and it can sit behind a gateway that enforces routing rules on a header. Once your tool registry is reachable that way, the argument for a bespoke internal tool-calling layer largely disappears. The cacheable list results matter for a different reason: in a system with many tools, re-sending every tool description on every request is a real share of your token bill, and a time-to-live on that list is a direct cost control.

The trade to keep in view is that an MCP server is a network boundary you now own. It needs sandboxing, least privilege on the credentials it holds, and a tool registry somebody maintains. A tool a model can call is a tool anything holding the model's credentials can call, so the privilege attached to each server is what bounds the blast radius of a bad call. That is why we treat the registry as a security artefact and not as configuration.

How tool schemas decide what the agent does

The set of tools you register is not the interface the model sees. What it sees is a block of text: each tool's name, its description, and a JSON Schema describing its arguments. The Model Context Protocol specification defines a tool in exactly those terms and adds optional annotations marking whether a tool is read-only or destructive. Selection happens against that text, which makes a description executable surface rather than documentation for a future maintainer.

Two consequences follow. Tools whose descriptions overlap make selection unstable, because the model is matching a request against surface similarity and nothing in your code breaks when it matches the wrong one. A pair such as search_orders and lookup_purchase is the kind of overlap a model will resolve inconsistently, and the fix is a rename with disjoint verbs or a merge rather than a longer system prompt. The second consequence is more useful: every constraint expressible in the argument schema is one you no longer have to police in prose. An enum of six order states cannot become a seventh if you validate before execution. A free-text status: string can, and then the error surfaces inside whichever downstream system you integrated through an API rather than at the boundary where it was created.

Tool descriptions also occupy context on every request, which is why the cacheable list results added in the 2026-07-28 MCP revision are a transport optimisation and not a prompt one. Caching saves the round trip to the server. The descriptions still enter the model's context on each call unless something filters them by task or by privilege level first.

The decision: treat names, descriptions and argument schemas as versioned code, keep a fixture set mapping representative requests to the tool that should be chosen, and run it whenever a description changes. A description edit is a behaviour change with no compiler behind it. If the fixtures show two tools competing for the same requests, one of them should not exist.

What is the A2A protocol, and when do you actually need it?

A2A, short for Agent2Agent, is an open standard for communication and interoperability between independent and potentially opaque AI agent systems. Where MCP standardises the connection from an agent down to a tool, the agent-to-agent protocol standardises the connection from one agent across to another, including agents built on different frameworks by different organisations. Google launched it in April 2025 and donated it to the Linux Foundation, IBM's Agent Communication Protocol merged into it in August 2025, version 1.0 shipped in March 2026, and on 17 August 2026 A2A joined the Agentic AI Foundation as a hosted project alongside MCP, with more than 150 organisations backing it.

The A2A specification defines five data structures worth knowing by name. An Agent Card is a JSON metadata document published by an A2A server describing its identity, capabilities, skills, service endpoint and authentication requirements, and agent discovery works by fetching that card, which is how one agent learns what another can do before sending it anything. A Task is the core unit of action, carrying an identifier, a status, its Artifacts and the interaction history. A Message is one unit of communication between client and server. A Part is a container for a section of content, whether text, a file or structured data. An Artifact is the output a task produces. The specification defines three transport protocol bindings: JSON-RPC, gRPC, and HTTP with JSON.

The task lifecycle is the part most worth reading before you adopt it. A task moves through submitted and working, and can land in input_required or auth_required before reaching one of the terminal states: completed, failed, canceled or rejected. Those two non-terminal states are the interesting ones, because they are the protocol admitting that a remote agent will sometimes need a human in the loop or a credential it does not hold. Any agent handoff design with no answer for those two states is not finished.

So when do you actually need A2A? The honest answer is narrower than the marketing suggests. You need it when work crosses a boundary you do not control: a supplier's agent, a customer's agent, a partner platform, or an internal team on a different framework with its own release cycle. Inside a single codebase, two agents talking over A2A are two functions talking over HTTP with extra steps. A direct call is faster, cheaper, easier to trace and needs no Agent Card.

Both protocols now sit under the same foundation, which removes a governance argument that used to be a genuine adoption risk. It does not remove the design question. The question is still whether your system has a boundary that needs a protocol, and most first production agents do not.

Where multi-agent architectures earn their complexity

There are four conditions under which a multi-agent system is the right answer, and they are specific enough to check against your own project.

The first is genuine parallelism. If a task decomposes into subtasks that do not depend on one another's outputs, running them concurrently converts token spend into wall-clock time, which is sometimes exactly the trade you want. Anthropic's account of its own research system, published 13 June 2025, describes the economics plainly: multi-agent architectures pay off for valuable tasks involving heavy parallelisation, information that exceeds a single context window, and interfacing with many complex tools. On its internal research evaluation, a system with Claude Opus 4 as lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2%.

The second is context that will not fit. A single context window is a hard budget. When the material a task must consider exceeds it, something has to summarise, and a subagent that reads a source and returns a compressed finding is a reasonable way to do that. This is the case where the extra token cost buys something a single agent cannot get at any price.

The third is heterogeneous tools with genuinely different operating requirements. An agent that queries a warehouse, an agent that drives a browser and an agent that writes to a ledger have different latency budgets, different failure modes and different privilege levels. Separating them is as much a security decision as a modelling one, because it lets each hold only the credentials it needs.

The fourth is real specialisation, meaning a subtask where a differently prompted or differently sized model measurably does better. Anthropic's 2026 State of AI Agents Report, produced with the research firm Material from a survey of more than 500 United States technical leaders conducted in late 2025, includes a worked example: L'Oréal moved from a generative AI approach reaching about 90% accuracy on conversational analytics to orchestrated specialised agents reaching 99.9% on complex analytics queries, with a coordinating model choosing which specialised agent to engage and synthesising the results. The same report puts 57% of surveyed organisations running agents on multi-stage workflows and 16% on cross-functional processes spanning several teams, with 80% reporting measurable returns and integration with existing systems named the leading barrier at 46%.

Research on latent collaboration in multi-agent systems suggests the cost side of this may not stay fixed. Zou and colleagues, in a paper submitted to arXiv on 25 November 2025 and accepted as an ICML 2026 spotlight, describe LatentMAS, a training-free method in which agents exchange last-layer hidden representations through a shared latent working memory rather than passing text between each other. Across nine benchmarks spanning mathematics, science reasoning, commonsense understanding and code generation, they report up to 14.6% higher accuracy than text-based multi-agent baselines, output token usage reduced by between 70.8% and 83.7%, and end-to-end inference between four and 4.3 times faster. That is a research result rather than a production pattern, and no mainstream framework ships it today. It is worth tracking, because the token multiple is currently the main reason multi-agent systems lose an architecture review, and latent collaboration attacks exactly that number.

If your project does not meet at least one of those four conditions, a multi-agent system is buying you organisational tidiness at a fifteen-times token multiple.

Where multi-agent is cargo cult

The common failure is not technical. It is that the agent diagram mirrors the company org chart. A researcher agent, a writer agent, a reviewer agent and an editor agent look correct on a slide because they look like a team. They perform badly because each one holds a different slice of the context, and the decisions they each make quietly assume facts the others never saw.

Cognition's Walden Yan set this out on 12 June 2025 in an essay arguing against multi-agent designs, and its two principles are the clearest statement of the problem in print: share context, and share full agent traces rather than individual messages; and actions carry implicit decisions, so conflicting decisions produce bad results. The practical consequence is that a single-threaded linear agent, where the context is continuous, gets further on reliability than a parallel arrangement, and that context overflow is better answered with a dedicated compression step than with more agents.

Four patterns where we would remove agents rather than add them:

1. Any process a state machine already expresses. If the transitions are known, encoding them costs a day and removes an entire class of non-determinism. A state machine is also the only version of the system a compliance reviewer can read end to end.
2. Sequential work with dependencies. If agent B needs agent A's output, you have a pipeline, and a pipeline written as code is observable in a way a supervisor's routing decision is not. Anthropic's own guidance advises against multi-agent designs for domains requiring all agents to share the same context or containing many inter-agent dependencies.
3. Agents created to route between tools. Routing among a handful of tools is a classification problem. One model call producing a typed enum is cheaper, faster and testable against a fixture set, and it fails in a way you can assert on.
4. Agents created because a framework makes them easy. Framework ergonomics are not an architectural argument. The cost of an agent is not the lines of code that create it; it is the tracing, evaluation and incident work it adds for the rest of its life.

The tell that a design is cargo cult is that nobody can name what the system loses if two of the agents are merged. If merging them costs nothing, they were never separate.

What does agentic orchestration mean in a running system?

Agentic orchestration is the layer that decides which component runs next, what context it receives, and what happens when it fails. In a deterministic workflow that layer is your code. In an agentic system, part of it is a model. The engineering work is deciding which part.

Task decomposition is where it starts. A supervisor agent that receives a goal and emits a list of subtasks is doing planning, and the output of that planning should be data you can store rather than a hidden step inside a prompt. Persisting the plan is what makes resume, retry and partial replay possible, and it is the single change that most improves the debuggability of an agentic system.

Agent handoff is the second piece, and it needs a contract rather than a convention, because an implicit handoff is where the conflicting-decisions problem lives. The section below on planning shapes sets out what that contract has to carry.

Agent memory is the third, and it is where most designs stay vague, because three stores with different lifetimes and different owners get filed under one word. The section on what an agent needs to remember, below, separates them and gives the specification to fill in before any of it is built.

Then there is the part that is not glamorous and decides whether the system is operable. OpenTelemetry's generative AI semantic conventions now include agent spans and conventions for MCP traffic, and have moved into a dedicated GenAI conventions repository, which makes a vendor-neutral instrumentation layer a realistic default rather than an aspiration. Agent evaluation means a fixture set of real tasks with expected outcomes, run on every change, because a prompt edit in an agentic system is a behaviour change with no compiler to catch it. A latency budget and a token cost ceiling per run belong in the design document, not in the post-mortem.

Human in the loop is an orchestration decision, not a safety afterthought. The question is which state transitions require a person, and the answer should be written as a rule the orchestrator enforces. In our own AI Procurement Agent, purchase orders above a configured value threshold, and any order from a vendor the agent has not dealt with before, are held for sign-off, while everything below the threshold moves through automatically. That rule is the architecture. It is not a setting someone toggles later.

What does an agent actually need to remember?

"Give the agent memory" is a requirement nobody can build from. It names no store, no writer, no lifetime and no eviction rule. Three separate things hide inside it, and they fail in opposite directions.

Working memory is the context window. It lasts one run, it is reassembled on every model call, and it is a budget: system prompt, tool schemas, injected memory, the trajectory so far, and whatever you reserve for the output. Because most loops resend the whole trajectory, total tokens for a run of n steps grow roughly as base × n + k × n² / 2, where base is the fixed prompt and k is what each step adds. That squared term is why a step cap is a cost control as much as a safety control, and why context budgeting belongs in the design document rather than in the first invoice.

Episodic memory is the record of previous runs: what was attempted, what came back, where a person intervened and what they changed. It needs a write policy, a retention period and a read trigger. The common defect is writing every run into it and retrieving by similarity alone, which feeds an agent its own past mistakes with the same confidence as its past successes. Filter episodic recall by outcome, not only by resemblance.

Semantic memory is the retrieval index over documents and facts the business already owns. The agent reads it. It should not write to it, because an agent that authors and then cites its own reference material produces claims nobody can trace back to a source document.

Conflating the three produces two visible symptoms. A system that forgets something it was told ninety seconds ago has a working-memory compaction policy nobody wrote, so a summariser is discarding load-bearing detail. A system that drags irrelevant history into every prompt has episodic recall with no recency or outcome filter on it.

The decision: fill in that table before writing code. A row you cannot fill is a store that does not exist yet, and a design that leaves one blank is describing an intention rather than a system.

Plan first, or reason as you go?

Two shapes cover most agent loops. Plan-then-execute makes one model call that emits an ordered list of steps as data, then executes those steps with separate calls, returning to the planner when one of them fails. Interleaved reasoning chooses the next action after each observation, which is what a ReAct loop does on every pass.

The trade is inspection against adaptation. A plan is an artefact. You can show it to a person before anything runs, price it as step count multiplied by expected per-step token cost, store it, resume it from step four after a restart, and diff two plans for the same goal to see what a prompt edit actually changed. Interleaved reasoning gives you none of that in advance and buys something real in return: the ability to respond to a tool returning an empty result the planner assumed would be populated.

Each shape has a characteristic failure. Pure planning breaks when the plan was written against stale world state, so a replan trigger has to be designed in: a step whose result contradicts a precondition the plan assumed sends control back to the planner instead of onward to the next step. Pure interleaving breaks on long horizons, where nothing holds the goal except a trajectory that compaction is quietly eating. Most production systems land between the two shapes. Plan at the granularity a person would be willing to approve, and let a single step reason freely inside its own boundary.

Hand-off semantics are the same problem posed between agents rather than between steps. A hand-off has to carry four things: the goal restated in the receiver's own terms, the slice of state it is allowed to read, the authority it holds, meaning its tools and its limits, and the return contract including terminal states. The A2A input_required and auth_required states are that contract written down for the cross-boundary case. There is also an earlier question teams skip: is this a transfer, where the caller stops, or a call, where the caller waits and resumes with the result? Where two engineers assumed different answers, you get runs that either finish twice or never finish at all.

The decision: write every hand-off as a typed signature, even when both sides are prompts in the same repository. If you cannot type the return value, the receiving agent has no termination condition and the caller has no way to check its work.

Does the agent need its own identity?

It does, and handing it a borrowed user session instead is the pattern behind the incidents that take longest to unwind.

An agent acting under a person's session inherits everything that person can do, which is never the set of permissions the task needed. The audit log then records the person, so a review cannot separate what the human did from what the model decided. Revoking access means locking a working employee out of their own tools. And the person carries accountability for a decision they did not make and may never have seen.

The alternative is that the agent is a principal in your identity system, holding credentials of its own, scoped per tool rather than per agent. An agent with six tools should hold six narrow grants rather than one grant wide enough to cover all six, because the union is what an attacker gets after a successful prompt injection. Where the agent acts for a specific person, the call should carry both identities, and the effective permission should be the intersection of what the agent may do and what that person may do, never the union of the two.

Token lifetime is the part most designs skip. A long-horizon run can outlast any session length you would defend in a security review, which leaves two honest options: checkpoint the run and resume it with a freshly issued credential, or admit that the credential is long-lived and scope it accordingly. Closely related, and worth writing as an explicit rule rather than leaving to inference: what the agent may do unattended at three in the morning should be a strictly smaller set than what it may do while somebody is watching the queue. Attended and unattended are different privilege levels wearing the same name.

The standards work is moving in this direction. The United States National Institute of Standards and Technology, through its National Cybersecurity Center of Excellence, published a concept paper on 5 February 2026 on applying existing identity standards, including OAuth, OpenID Connect and SPIFFE, to software and AI agents, covering identification, authorisation, auditing and non-repudiation. NIST announced an AI Agent Standards Initiative on 17 February 2026 naming agent security and identity as a priority area.

The decision: produce the credential list before the build starts, one row per tool, naming the identity, the scope, the token lifetime and the exact line the audit log will write when that tool fires. Any row reading "the user's session" is the row to fix first. How that scoping is then enforced at run time, by code that does not depend on the model cooperating, is the subject of our piece on approval gates and containment in enterprise agentic systems.

What to log on every step

A transcript is not a trace. It records what was said and omits what was offered, what was rejected, what was retried and which version of a tool answered. Two runs can produce near-identical transcripts while differing in the documents retrieved, the schema version of the tool that executed and the credential it ran under, and only one of them went wrong.

The per-step record has to answer three questions without anyone consulting the engineer who wrote the prompt: why this tool, why these arguments, and why did the run stop where it stopped. A field that serves none of those is optional. A question you cannot answer marks a field that is missing.

Two of those fields earn their place more than people expect. Retry count is a leading indicator, because a retry that eventually succeeds hides a defect, and a rising retry rate on one tool shows up well before any accuracy metric moves. Storing the inputs to context assembly, rather than only the final prompt string, is what makes two runs comparable: the string tells you what the model saw, while the assembly inputs tell you why it saw that and what was dropped to make it fit.

The decision: take the worst run from last week and try to answer those three questions from the log alone. Whatever you had to ask a colleague for is a field you add before launch. It costs an afternoon, and it is most of the difference between an incident you close the same day and one that runs into the next week.

What you give up when you move the dial right

Each step to the right trades away something you had. Reproducibility goes first. Then test strategy, as assertions on outputs give way to evaluation over distributions of behaviour. Then diagnosis time, because an incident review now starts with reading a trajectory rather than a stack trace. Then cost predictability, because token spend scales with trajectory length and a retry loop that a human would have abandoned can run all the way to its step cap.

What changes operationally once a model can act rather than only answer, covering authorisation, audit and rollback, is a separate subject that deserves its own treatment, and we cover the containment side in our piece on enterprise agentic architecture and guardrails.

The architectural point here is narrower. You should be able to name, for every agentic step in your design, the deterministic alternative you rejected and the reason you rejected it. If you cannot name the alternative, the step is agentic by accident, and a semi-autonomous system assembled by accident is the hardest kind to operate.

How we pick an architecture on a real build

We run the same sequence on every engagement, and it takes about a week.

First, write the process as a state machine on a whiteboard, whether or not anybody intends to build it that way. Processes that resist this are usually processes nobody has actually documented, and that is a finding in itself. Second, mark every transition that needs judgement over unstructured input. Those are your candidate model steps, and often there are two. Third, count the tools. If a single agent would need more than roughly ten tools described in one prompt, that is a signal for a planner-executor or for splitting by privilege level, not a signal for a crowd of agents.

Fourth, look for genuine parallelism and for context overflow. If neither is present, the multi-agent option comes off the table and the conversation gets shorter. Fifth, decide the protocol surface: MCP for anything the agent reaches down to, an agent-to-agent protocol only where a boundary genuinely exists. Sixth, write the human-in-the-loop rule before writing the prompts, because it constrains everything above it.

Seventh, fill in the memory specification, because deciding that a fact belongs in an episodic record rather than a retrieval index changes who may write it and how long it survives. Eighth, write the credential list, one row per tool. Those last two take an afternoon at design time and are awkward and expensive to retrofit once a system is carrying live traffic.

We built both our AI HR Agent and the procurement agent this way, and in each case the shipped system has fewer autonomous components than the first design did. The HR agent's screening path is a workflow with model steps inside it, not a committee of agents debating a candidate, and it reduces time-to-hire by around 45% on our own product measurements. The procurement agent's three-way matching of purchase orders against invoice line items is deterministic arithmetic with a model reading the unstructured parts, which is why the matching result can be explained to a finance team line by line. Those are first-party figures from our own products, not industry benchmarks.

For the commercial side of this decision, including what to ask a vendor who proposes a multi-agent design and how the protocol choices show up in a contract, our guide to choosing an AI agent development partner covers the questions worth asking. If your first agentic project sits inside a broader automation programme, the AI automation service line is where that scoping usually starts, and teams building voice-first agents should read what we learned about the latency budget in voice agents, because it constrains architecture harder than anything else on this page.

What we would not build

We would not build a multi-agent system for a process a client has already written down as a numbered procedure. That procedure is a state machine somebody already did the work on.

We would not put an agent in front of a task whose correct answer is a database query. A semi-autonomous system with a model choosing between two hundred SQL templates is worse in every dimension than a form with two dropdowns.

We would not adopt A2A for communication between services in the same repository. The protocol exists to cross boundaries, and inventing a boundary to justify the protocol is how systems acquire latency nobody budgeted.

We would not ship an agentic system without trajectory logging and an evaluation fixture set in place first. A system whose behaviour you cannot reconstruct is a system you cannot fix, and that holds at any point on the dial past the second stop.

And we would not tell a client that agentic AI and AI agents are interchangeable terms for the same purchase. One describes a component you can specify and hand to an engineer. The other describes how much of your control flow you are handing to a model, which is a decision with a budget, an on-call cost and a rollback plan attached.

If you are deciding between a workflow and an agent and would rather argue it out with engineers than read another comparison, bring the process description to our agentic AI development practice or book a working session. We will map it to one of the seven rows in the decision table above and tell you what it costs to run and to debug before anybody writes a prompt.