Gartner put multiagent systems on its list of major technology trends for 2026, and within a week I had three separate conversations that started with "we need agents." In two of those three cases, what the business actually needed was a scheduled job and a webhook.
I am not being cynical. I build agentic systems, I like them, and some of the most useful things I have shipped in the last year would have been impossible without them. But there is a wide gap between what an agent demo looks like on stage and what survives contact with a production queue, a rate limit and a finance team reading the invoice.
This is what I have learned putting agents into real systems — where they earn their keep, where they quietly waste money, and how I structure them so they do not fall over.
First, a Definition That Is Actually Useful
Half the confusion in this space is vocabulary. Here is the line I draw when I explain it to clients:
A workflow is a sequence you wrote down. Step one, then step two, then a branch. The language model might sit inside a step, but you decided the path.
An agent decides the path itself. You give it a goal, a set of tools and a stopping condition, and it loops: think, call a tool, look at the result, decide what to do next. The control flow is chosen at runtime by the model.
A multi-agent system is several of those, each with a narrower job, passing work between them — usually with one coordinating and the others specialising.
That distinction matters commercially, not just technically. Workflows are cheap and predictable. Agents are expensive and variable. If you can express the problem as a workflow, do it as a workflow. Every time.
The Honest Test for Whether You Need an Agent
I ask two questions before I let a project go agentic.
Can you draw the flowchart? If a domain expert can sketch the decision tree on a whiteboard in ten minutes, you do not need a model choosing steps at runtime. Encode the tree. It will be faster, cheaper and testable.
Does the number of steps depend on the input? This is the real signal. "Research this company and write a briefing" might take four tool calls or fourteen, depending on how much you find. "Reconcile these invoices" takes exactly the steps you defined. The first is a genuine agent problem; the second is a loop with an LLM inside it.
The projects where agents have clearly paid for themselves on my desk all share that variable-depth shape: research and enrichment tasks, multi-source data gathering, triage where the next question depends on the previous answer, and anything involving a messy human request that has to be decomposed before it can be executed.
Multi-Agent Is Not Automatically Better Than One Agent
This is the mistake I see most often, and I made it myself. The reasoning goes: one agent is confused by too many tools, so let us split it into a planner, a researcher, a writer and a reviewer. Cleaner separation, better results.
Sometimes. But every hand-off between agents is a lossy compression step. Agent A summarises its findings into a message for agent B, and detail disappears in the summary. Do that four times and the final output is confidently based on a distorted version of the original task. I have debugged systems where the reviewer agent rejected work because it never received the constraint that made the work correct.
The heuristic I use now: split by tool domain, not by verb.
Splitting into "planner / writer / editor" is splitting by verb, and it usually just adds latency and token cost. Splitting into "the agent that can query the database" and "the agent that can send emails" is splitting by tool domain — each one has a tight, safe toolset, and the boundary is a real security boundary rather than a stylistic one.
And keep the shared state explicit. Instead of agents passing prose to each other, have them read and write a structured object.
type TaskState = {
goal: string;
facts: Array<{ claim: string; source: string; confidence: number }>;
openQuestions: string[];
actionsTaken: Array<{ tool: string; args: unknown; result: string }>;
done: boolean;
};
When the state is a typed object rather than a chat transcript, you can inspect it, log it, replay it and write assertions against it. That one change did more for the reliability of my agent systems than any prompt improvement.
The Four Things That Break Agents in Production
Loops that never end. An agent that cannot find what it needs will keep trying variations forever. Every agent I ship has a hard step cap, a wall-clock timeout and a token budget. When it hits any of them it stops and reports what it has, rather than dying silently or spending another 40,000 tokens.
Tools that lie. If a tool returns an empty array on failure instead of an error, the agent concludes there is no data and confidently reports nothing found. Tool error messages are prompts. Write them as if the model will read them, because it will: "Search failed: rate limit exceeded. Retry after 30 seconds." beats [] every time.
No idempotency. Agents retry. If the retry sends the email again, you have just messaged a customer twice. Anything with a side effect needs an idempotency key, and anything irreversible needs a human in the loop. I keep a hard rule: agents can draft, agents can stage, but a human approves anything that touches money, contracts or a customer's inbox.
Cost invisibility. An agent that averages twelve tool calls per run and occasionally takes sixty will produce a bill nobody predicted. Log tokens per run, tag them by agent and task type, and set an alert. I once watched a retry storm turn a quiet Sunday into a four-figure API charge. Once.
What Agents Are Genuinely Good At Right Now
Stripping out the hype, these are the shapes that have worked repeatedly for the businesses I have built for:
Inbound triage. Reading a support email or form submission, pulling the customer's history from the CRM, categorising it, and either drafting a reply or routing it. The agent does the boring lookup work; a human presses send.
Research and enrichment. Given a company name, find the site, the size, the tech stack, the relevant contact, and write it into a record. Variable depth, tolerant of imperfection, easy to verify.
Document-to-structure. Turning contracts, invoices or reports into rows in a table, with the agent deciding which sub-documents to open and which sections matter.
Internal operations glue. The tasks that live between four SaaS tools and are currently done by a person copying fields between tabs.
Notice what is missing: nothing on that list is a customer-facing autonomous decision maker. That is deliberate. The economics of agents right now favour work where a wrong answer costs a few minutes of a reviewer's time, not work where a wrong answer costs a customer.
Start Smaller Than You Think
If you are a business looking at this space in 2026, my advice is boringly practical. Pick one internal process that a person hates doing, that takes between ten and forty minutes, and that involves pulling information from three or four places. Build a single agent with three or four tools for that one process. Keep the human as the approver. Measure the time saved for a month.
That project will teach you more about whether agents fit your business than any pilot programme with a five-agent architecture diagram. And if it works, the second one takes a fraction of the time — because by then you have the tool layer, the logging and the guardrails already built.
The trend is real. The technology works. Just resist the urge to build the org chart of agents before you have built the one agent that pays for itself.
