AI Agent vs Chatbot: What Does Your Business Actually Need?

There is a question that separates these two technologies more cleanly than any feature comparison, and almost nobody asks it during the sales call.

When the software is wrong, what happens next?

If a chatbot is wrong, a customer reads an incorrect sentence. They get annoyed, they ask again, or they call someone. The damage is real but it is bounded, recoverable, and visible.

If an agent is wrong, a refund is issued. An appointment is booked into a slot that was already taken. A CRM record is overwritten. An email goes out under your company’s name to a customer who is already angry. A purchase order is created against the wrong supplier. The damage is not a sentence. It is a transaction, and transactions have consequences that outlive the conversation that produced them.

A chatbot produces answers. An agent produces actions. Everything else in this debate — the talk about reasoning and memory and orchestration — is downstream of that single distinction.

It matters because the two things fail differently, cost differently, and need completely different amounts of engineering discipline around them. A business that understands this difference will make a good decision with a small budget. A business that does not will spend a large budget discovering it.

Notice what is absent from that list. Gartner did not say the models were not smart enough. The failures they anticipated were failures of scoping and governance, which are business decisions, not technical ones.

This article is about making that business decision correctly.

The Question Everyone Asks, and the Question That Matters

Most business owners arrive at this topic asking “what is the difference between a chatbot and an AI agent?” It is a reasonable question and it has a reasonable answer, which we will get to. But it is not the question that will save you money.

The useful question is narrower and more uncomfortable:

which parts of my business process am I willing to let software complete without a human looking at it first?

Answer that honestly and the technology choice mostly makes itself. Refuse to answer it, and you will end up buying a system whose autonomy does not match your actual risk tolerance. That mismatch is the single most common reason these projects get quietly switched off eighteen months later.

So we will build up to that question properly, starting with what these things actually are.

What a Chatbot Actually Is

The word “chatbot” now covers at least three genuinely different technologies, and conflating them causes real confusion in buying decisions.

The rule-based chatbot

This is the oldest form and it is still everywhere. It works on decision trees and pattern matching. The customer types something, the system matches keywords or presents buttons, and a pre-written response comes back. There is no language model involved and no understanding of any kind.

These get mocked, but they deserve more respect than they receive. A rule-based bot is completely predictable. It will never invent a return policy. It will never hallucinate a price. If you write the tree correctly, it produces the correct answer one hundred percent of the time, forever, at essentially zero marginal cost. For a business whose top twenty questions account for most of its inbound volume, this is often the correct and complete solution.

Its weakness is equally clear. It cannot handle phrasing you did not anticipate, and maintaining a large decision tree becomes miserable as the business changes.

The AI chatbot

This is what most people mean today. A language model sits behind the conversation, so the customer can phrase things however they like and still be understood. Usually it is connected to a knowledge base through retrieval, so that when someone asks about your refund window, the system searches your actual policy documents, retrieves the relevant passage, and generates an answer grounded in it. That retrieval step is what keeps the answers tied to your business rather than to the model’s general knowledge.

This is a large improvement in coverage and a real reduction in maintenance. It is also where a new category of risk enters, because a language model can produce a fluent, confident, well-written answer that is simply wrong. Retrieval reduces this substantially. It does not eliminate it.

Crucially, an AI chatbot is still read-only with respect to your business. It looks things up. It explains. It does not change anything.

The AI assistant

Somewhere past the chatbot sits the assistant, and the boundary here is genuinely fuzzy. An assistant typically has some memory of the conversation or the user, can handle a multi-turn task, and may be able to look up live information rather than static documents. It might check an order status through an API rather than reading a document about order statuses.

The defining characteristic is that it still works with a human in the loop, turn by turn. It responds to you. It drafts for you. It waits for you.

The human remains the one who decides and the one who acts.

That distinction, more than memory or reasoning or tool access, is what separates an assistant from an agent.

What an AI Agent Actually Is

An agent is a system that pursues a goal across multiple steps, decides for itself which steps to take, and executes actions in real systems without needing a human to approve each one.

“Agents can take actions” is where most explanations stop, and stopping there hides everything that matters. The interesting question is what has to exist underneath before an action is possible at all.

The loop

At the core of every agent is a cycle that repeats:

Goal received → model reasons about the current state → selects a tool or action → the action executes against a real system → the result comes back → the model evaluates whether the goal is met → if not, it reasons again and repeats That loop is the whole idea. A chatbot runs this once and stops. An agent runs it until it decides it is finished, which introduces a problem chatbots never have: knowing when to stop. Agents can loop indefinitely, repeat a failed action, or wander into a state nobody anticipated.

Loop control is an engineering concern that does not exist in the chatbot world at all.

What makes the loop possible

• Tools and APIs An agent acts by calling functions. Checking inventory means calling your inventory system’s API. Booking an appointment means calling your scheduling system. Every capability an agent has corresponds to a specific integration that someone built and now maintains. An agent with no tools is a chatbot with extra steps.

The industry has converged on standards here. The Model Context Protocol, an open standard now supported across major AI vendors, exists specifically to solve the integration explosion: rather than building a custom connector for every combination of AI system and business tool, you build one server per tool and any compliant client can use it. This has made integration meaningfully cheaper than it was two years ago.

It has not made it free, and it has introduced its own operational concerns around versioning, observability, and access control.

• Permissions and authentication This is where most of the real work lives, and where most of the real risk does too. What is this agent allowed to read? What is it allowed to change? Under whose credentials does it act? Can it issue a refund of any size, or only under a threshold? Can it see one customer’s data or all of them? An agent is only as safe as its narrowest permission, and permissions are almost always granted too broadly during the excitement of a pilot.
• State and memory To complete a multi-step task, the system has to remember what it already did. There is a meaningful difference between session memory (what happened in this conversation), persistent memory (what this customer told you in March), and retrieved context (what your policy documents say). These are three separate engineering problems with three separate failure modes, and vendors frequently collapse them into the single word “memory.”
• Retrieval The agent needs your actual data: policies, pricing, product details, customer history. Retrieval quality sets a hard ceiling on agent quality. This is why data problems dominate agent failures. McKinsey’s research on scaling agentic AI found that roughly eight in ten companies cite data limitations as a roadblock. No amount of model capability compensates for a product catalogue where half the stock levels are wrong.
• Guardrails and human escalation Rules about what the agent must not do, and a defined path to a human when it hits one. This is the difference between a system that fails safely and one that fails expensively.
• Logging and evaluation Every action recorded, so you can answer “why did it do that?” three weeks later when a customer disputes something. Agents without audit trails are unmanageable in any regulated context and unpleasant in every other one. Read that list again and notice something. Perhaps two items are about artificial intelligence. The rest is software engineering, data quality, and access governance. That ratio is the honest picture of what an agent project actually involves, and it is the reason budgets get exceeded.

Watching One Request Move Through Both Systems

Abstractions are easy to nod along to. Here is the same customer message, handled two ways. The scenarios below are constructed to illustrate the mechanics rather than drawn from any specific company.

A customer messages a mid-sized furniture retailer:

“Do you have the grey three-seater in stock?”

Through a chatbot

The system understands the question, searches the product catalogue content it has been given, finds the relevant page, and replies that the grey three-seater is listed as available, with a link.

The customer now knows something. That is the entire output. If they want to buy it, they go and do that themselves. If the catalogue content was updated last Tuesday and three units sold on Wednesday, the answer is confidently wrong, and nobody finds out until the customer is disappointed.

Cost to build: low. Time to deploy: days or weeks. Failure mode: a wrong sentence.

Through an agent

Message received → intent classified as a stock enquiry with purchase intent → customer identified from the messaging channel → CRM record retrieved, showing two previous purchases from the same product line → live inventory API called, returning one unit in the regional warehouse → delivery lead time calculated for the customer’s postcode → loyalty tier checked, discount eligibility confirmed → response drafted with the answer, the lead time, and the applicable price → soft reservation placed on the unit for 24 hours → CRM updated with the interaction and the reservation → follow-up task scheduled if no purchase within 24 hours → sales team notified because the order value exceeds the alert threshold The customer receives an answer that is live rather than cached, priced correctly for them specifically, and backed by a held unit. That is a materially better experience and it plausibly increases conversion.

Now count what had to be true for that to work.

The messaging channel had to reliably map to a customer identity. The CRM had to be accurate. The inventory API had to exist, be exposed, and be trustworthy in real time. The delivery calculator had to be callable. The loyalty rules had to be encoded somewhere the agent could reach. The reservation system had to accept programmatic holds and release them correctly on expiry. Someone had to define the notification threshold, and someone had to own what happens when the notification is ignored.

Eleven steps in the workflow. Perhaps eight distinct systems. Every one of them a potential point of failure, and several of them able to fail silently.

This is the honest comparison. Not “chatbot answers, agent does more.” It is: the agent delivers a genuinely superior outcome, and it costs perhaps ten to thirty times more to build and maintain, and it fails in ways that create work rather than just disappointment.

Whether that trade is worth it depends entirely on numbers we have not discussed yet.

Three More Scenarios, Because the Trade Changes by Context

A dental clinic booking appointments

The agent version handles enquiry, checks the practitioner’s live calendar, offers slots, books one, sends confirmation, and adds a reminder sequence.

Here the risk profile shifts in an important way. A double-booked slot is not a bad sentence. It is a patient who took time off work, arrived, and cannot be seen. The cost of a single error is high relative to the value of a single successful booking, and the errors are visible to the person you least want to annoy.

The correct design is almost certainly not full autonomy. It is an agent that proposes and holds, with the booking confirmed against a system that enforces slot uniqueness at the database level rather than trusting the model to reason about availability. Let deterministic software guarantee what deterministic software is good at guaranteeing.

A B2B services firm producing proposals

Enquiry arrives → agent researches the prospect company from public sources and CRM history → identifies likely service fit from previous similar clients → retrieves relevant case studies → drafts a proposal against the firm’s template with scoped pricing → routes to the account lead for review → sends after approval → logs and schedules follow-up This is where agents look genuinely excellent, because the expensive part is a senior person spending two hours assembling context.

Reducing that to twenty minutes of review is a large, measurable saving on a task that happens weekly.

Note the human checkpoint before anything leaves the building. Nothing about that checkpoint makes the system less valuable. The saving was in the assembly, not the sending.

An accounts team processing supplier invoices

Invoice arrives by email → agent extracts supplier, line items, totals, tax, PO reference → matches against the purchase order → flags discrepancies → codes to the correct ledger account → posts to the accounting system if matched within tolerance → routes to a human if not This is close to the ideal agent use case, and it is worth understanding why. The task is high-frequency, structurally repetitive, currently done by expensive people, tolerant of a defined error rate because a matching step catches most errors, and it has a clean escalation path. It is also unglamorous, which is generally a good sign.

The pattern across all three: agents earn their cost where the work is frequent, structured, currently manual, and where a well-designed checkpoint catches the failures before they reach a customer.

The Blurry Middle, and the Marketing Problem Inside It

Autonomy is a spectrum, not a switch, and the industry has strong commercial incentives to describe products as being further along that spectrum than they are.

That estimate is a point-in-time judgement from one research firm and the number itself should be held loosely. The underlying pattern is not in dispute. If you are buying, you should assume the word “agent” in marketing material means very little until you interrogate it.

A useful ladder for cutting through it, which is also the right way to think about your own deployment:

Four questions will place any vendor’s product on this ladder, and they are worth asking in exactly these words:

1. What can it change in my systems without a human approving it?
2. What is the hard limit on the size or scope of an action it can take?
3. Show me the log of every action it took last week.
4. What happens, specifically, when it does not know the answer?

A vendor who answers all four crisply is selling something real. A vendor who redirects to model capabilities is selling something else.

Most businesses that think they need Level 4 need Level 2 or 3. That is not a compromise. Levels 2 and 3 capture most of the value at a fraction of the risk, and they are where the durable deployments live.

The Arithmetic Nobody Puts in the Sales Deck

Here is the part that most changes how people think about this.

An agent completes a task by chaining steps. Errors chain too.

If each step in a workflow is 95% reliable, and the workflow has ten steps where each depends on the last, then end-to-end reliability is 0.95 raised to the power of ten. That is roughly 60%. Not 95%. Four in ten runs contain at least one error somewhere.

At 99% per step, ten steps gives about 90%. Still one in ten.

This is not a theoretical concern, and there is good research measuring it. The τ -bench benchmark from Yao and colleagues was built specifically to test agents on realistic multi-turn customer service tasks with tool access and written policies to follow. The authors introduced a metric called pass^k , which measures whether an agent solves the same task successfully on all k attempts, rather than at least one. It is a measure of consistency rather than peak capability.

The finding was stark. Agents with reasonable average success rates showed sharply lower consistency as attempts increased. In the original paper, a leading function-calling agent scoring above 60% on single attempts dropped below 25% at pass^8 in the retail domain.

Subsequent work on similar benchmarks has continued to show the same shape of curve.

Read that again in business terms. An agent that handles a task correctly most of the time may nonetheless fail to handle it correctly every time for the same customer scenario. Averages hide this completely.

Why “we automated 80%” is a misleading sentence

This is the single most important idea in this article.

Suppose a support agent resolves 80% of tickets without human involvement. That sounds like a clear win and it will be presented as one.

Now ask which tickets are in the remaining 20%.

They are not a random sample. Easy questions get resolved. What is left is billing disputes, cancellation requests, complaints, edge cases, and customers who are already unhappy. The residual is systematically enriched with the highest-value, highest-emotion, highest-risk conversations you have.

So the headline says you automated 80% of volume. The reality may be that you automated 80% of volume and roughly 20% of the risk, while adding a frustrating extra layer in front of the conversations that most determine whether a customer stays.

Klarna’s experience is the most thoroughly documented public example of this dynamic. In February 2024, Klarna and OpenAI jointly announced that Klarna’s AI assistant was handling around two-thirds of customer service chats, doing work equivalent to roughly 700 agents, with resolution times falling from about eleven minutes to under two. In May 2025, chief executive Sebastian Siemiatkowski told Bloomberg that the company had pushed too far on cost at the expense of quality, and that Klarna would invest in human support again.

The nuance matters and is often stripped out of the retelling. Klarna has publicly disputed the “reversal” framing, stating that it continues to invest heavily in AI, that its assistant’s workload has grown rather than shrunk, and that the human hiring represents a dual-track approach rather than a retreat. Both things appear to be true: the automation delivered real efficiency, and the company concluded that optimising purely for cost degraded something that mattered.

The transferable lesson is not “AI customer service does not work.” It is that average-case metrics described the wins while the damage accumulated in the tail, and the tail was invisible on the dashboard.

Practical consequence:

never evaluate an agent on aggregate resolution rate alone. Segment by ticket type and measure the hard cases separately. If your agent handles 95% of password resets and 30% of billing disputes, you do not have a 90% system. You have two systems with very different risk profiles, and you should manage them as such.

What This Actually Costs

Technology decisions are economic decisions. Here is the cost structure people underestimate.

• Build For an agent, this is mostly integration work, not AI work. Every system it touches needs a connector, credentials, error handling, and testing. Integration cost scales with the number of systems, and it scales worse when those systems are old, poorly documented, or lack decent APIs.
• Data preparation Usually the largest hidden cost. The agent needs accurate, accessible, current data. Most businesses discover during this phase that their product data has gaps, their CRM has duplicates, and the authoritative answer to a common question lives in a spreadsheet on someone’s laptop. This work has genuine value independent of the AI project, which is a reasonable consolation, but it must be budgeted.
• Inference Agents consume far more tokens than chatbots, because the loop runs many times per task and carries growing context. A single agent task might cost ten to fifty times a single chatbot response. At low volume this is negligible. At high volume it becomes a real line item that scales directly with your success.
• Evaluation You cannot manage what you do not measure, and measuring agents is harder than measuring software. You need a test set of real cases with known correct outcomes, run regularly, especially after any model or prompt change. Almost nobody budgets for this and it is the difference between a system that stays reliable and one that silently drifts.
• Monitoring and maintenance Your business changes. Prices change, policies change, APIs deprecate, models get updated by the vendor and behave subtly differently. An agent is a living system with an ongoing operational burden, not a project that finishes.
• Ownership Someone must be accountable for the agent’s behaviour. Not a committee. A named person. Projects without one drift until they are switched off.

The calculation that should drive the decision

Before any technology is chosen:

1. How many times per month does this task occur?
2. How many minutes does it currently take, and at what loaded cost per hour?
3. What is the current error rate of the human process? (This number is usually higher than people assume, and it is the fair baseline. Agents are frequently held to a standard the existing process does not meet.)
4. What does one error cost, including the recovery work and the customer relationship?
5. What proportion is genuinely routine rather than exception?
6. What is the total build and first-year running cost?

If the annual value of the time saved does not exceed the total cost of ownership by a comfortable margin, the answer is not a better agent.

The answer is a chatbot, a deterministic automation, or leaving the process alone.

A worked illustration: a task occurring 400 times a month, taking 15 minutes at £30 per hour loaded cost, represents about £36,000 a year of labour. An agent that reliably handles 70% of it saves perhaps £25,000 gross, before you subtract the review time on the 30% and the running costs. If the build is £60,000, payback is comfortably over two years and the business case is weak. Change the frequency to 4,000 a month and the same build pays back in weeks.

Frequency, not sophistication, is what makes agents worth it.

When a Chatbot Is Genuinely the Better Choice

This section exists because the honest answer for a large share of businesses is “you need the cheaper thing.”

Choose a chatbot when:

Your inbound volume is dominated by a stable set of informational questions. If the top twenty questions cover most of your enquiries, a chatbot handles them at a fraction of the cost.

Your systems lack usable APIs. If your booking system has no programmatic interface, an agent cannot book anything, regardless of how capable the model is.

Your data is not yet trustworthy. Acting on bad data is considerably worse than answering from it.

Errors in your domain are expensive or regulated. In healthcare, legal, or financial contexts, the cost of a wrong action is severe enough that human review should stay in the path.

Your volume is low. Under a few hundred interactions a month, integration cost will rarely be recovered.

You do not yet have someone who can own an operational AI system.

You are at the start. A chatbot is a legitimate first phase that teaches you what your customers actually ask, which is the best possible input to designing an agent later.

That last point deserves emphasis. Deploying a chatbot first is not a failure of ambition. It generates the conversation data that tells you which workflows are worth automating, and it does so cheaply. The businesses that succeed with agents very often built a chatbot first and used it as reconnaissance.

When Neither Is the Answer

Sometimes the correct recommendation is not to use a language model at all, and a consultancy that never says this is not being straight with you.

Use deterministic automation instead when the rules are actually deterministic.

If the requirement is “when a form is submitted, create a CRM record, send a templated confirmation, and notify the account owner,” that is a workflow automation task. Tools that do this cost tens of pounds a month, run in an afternoon, and will execute correctly every single time for years. Putting a language model in that path adds cost, latency, and a failure mode that did not previously exist.

The rule of thumb:

if you can write the rule down completely, write the rule down.

Reserve the language model for the parts of the process that genuinely require interpretation of unstructured input or natural language.

Many real systems are best built as a deterministic workflow with a small AI component at the single point where judgement is needed, rather than as an agent with a workflow bolted on. This is less impressive in a demo and considerably more reliable in production.

Fix the process instead when the process is the problem.

If a task is slow because it requires approval from three people who do not need to approve it, an agent will faithfully automate the collection of three unnecessary approvals. Automating a broken process makes it faster to be wrong.

Single-Agent and Multi-Agent Systems, Briefly

Multi-agent architectures, where several specialised agents coordinate, get significant attention and deserve a short and honest treatment.

The appeal is real. A researcher agent, a writer agent, and a reviewer agent, each with focused instructions and tools, can outperform one agent trying to do everything, particularly on open-ended work.

The cost is also real, and it is compounding. Every agent-to-agent handoff is a place where context is lost or corrupted. Debugging becomes considerably harder because failures emerge from interactions rather than from any single component. Token costs multiply. Latency accumulates.

For the overwhelming majority of businesses reading this, the practical guidance is straightforward:

you do not need a multi-agent system.

A single well-scoped agent with good tools and clear boundaries solves nearly every business workflow more reliably. Multi-agent designs make sense when a task genuinely decomposes into distinct specialisms with clean interfaces between them, and when you already have the evaluation infrastructure to debug the result. That is a mature-team problem, not a starting point.

The Decision Framework

Work through these in order.

Step 1: Describe the outcome, not the technology

Write one sentence: “We want to reduce the time spent on X” or “We want to stop losing Y.” If you cannot complete that sentence without naming an AI product, you are not ready to buy one.

Step 2: Classify the work

• Information delivery People need answers that already exist somewhere. → Chatbot.
• Deterministic execution Fixed rules, structured inputs, no judgement. → Traditional automation.
• Judgement plus execution Requires interpreting unstructured input, then doing something in a system. → Agent territory.
• Relationship and negotiation High emotion, high value, ambiguous. → Human, possibly with AI preparing the ground.

Step 3: Run the volume and value test

Frequency × time per instance × cost per hour. If the annual figure is not a multiple of your expected total cost of ownership, stop here.

Step 4: Audit your readiness honestly

Do the systems have APIs that permit the actions you want?

Is the data accurate enough to act on?

Can you write down the rules and exceptions, or does the process live in people’s heads?

Is there a named owner?

Do you have, or can you build, a test set of real cases with known correct answers?

A “no” on data accuracy or API availability is a blocking answer, not a challenge to work around.

Step 5: Choose the lowest autonomy level that captures the value

Return to the ladder. Start at the lowest level that delivers a meaningful share of the benefit. Raise autonomy only when your logs give you evidence that the level below it is performing.

Step 6: Design the failure path before the success path

Specify what the system does when confidence is low, when a tool call fails, when the request is outside scope, and when the customer is upset. A system that escalates well and acts modestly beats a system that acts confidently and escalates badly.

The short version

Choose a chatbot if:

high volume of repeated questions, limited integration capacity, expensive errors, low interaction volume, uncertain data quality, or no operational owner.

Consider an agent if:

a specific high-frequency workflow costs real money in staff time, the systems involved have solid APIs, the data is accurate, the rules and exceptions can be articulated, there is a named owner, and a human checkpoint can sit in front of anything irreversible.

Choose neither if:

the rules are fully deterministic, the underlying process is broken, or the volume does not justify the build.

How to Start Without Wasting Money

If you have concluded that an agent makes sense, the implementation sequence matters as much as the decision.

Pick one workflow, not a department. Choose the boring, frequent, well-understood one rather than the impressive one. Measure the current process before you change it, because without a baseline you cannot demonstrate improvement and you will end up arguing about vibes.

Build it first at Level 2, drafting for human review. Run it in parallel with the existing process rather than replacing it. Collect every case where the human changed the draft, because that collection is your evaluation set and it is the most valuable artefact the pilot produces.

Only when the drafts are consistently accepted without modification should you consider letting it act directly, and even then, within hard limits and with complete logging. Expand scope only after the current scope has evidence behind it.

This is slower than the demo suggests. It is also the difference between the deployments that survive and the 40% that Gartner expects to be cancelled.

The Honest Summary

The gap between experimentation and value here is wide and well documented. McKinsey’s State of AI survey, published in November 2025, found that 88% of organisations report regularly using AI in at least one business function, while only 23% were scaling an agentic system anywhere in the enterprise, and in any given business function no more than 10% reported scaling agents. Most organisations have tried this.

Few have made it routine.

Reasonable people read those numbers differently. One reading is that the technology is immature. Another is that the technology is ahead of most organisations’ operational discipline. The evidence, particularly the pattern of failures being attributed to cost, governance, and data rather than model capability, leans toward the second. That is an informed judgement rather than a settled fact, and you should weigh it accordingly.

What follows from it is practical. The constraint on your business is probably not which model you use. It is whether your data is accurate, whether your systems can be called, whether your process is written down, and whether one person owns the outcome.

A chatbot answers questions. An agent completes work. The second is more valuable and more dangerous, and it is worth building only when the work in question is frequent enough, structured enough, and important enough to justify the discipline it demands.

Most businesses should start with the cheaper thing, learn what their customers actually need, and earn their way up the ladder. That is a less exciting recommendation than the market currently offers. It is also the one that tends to still be running in three years.

Frequently Asked Questions

Can an AI agent replace my customer service team?

It can replace a portion of the volume, not the team. The tickets that remain will be systematically harder and more consequential than the ones automated, which means your remaining human capacity needs to be more skilled rather than simply smaller. Plan for a hybrid model.

How long does an agent take to deploy?

A chatbot can be live in days to a few weeks. A production agent touching multiple systems is realistically a two to six month project, and most of that time is integration, data preparation, and evaluation rather than AI work.

Is an AI agent more expensive to run than a chatbot?

Yes, substantially, because the reasoning loop runs many times per task. The relevant comparison is not agent versus chatbot cost, it is agent cost versus the labour cost it displaces.

What is “agentic AI”?

It describes systems that plan and execute multi-step tasks with some autonomy. It is also heavily used as marketing language for products that do not do this, so treat the term as a prompt to ask questions rather than as information.

Do I need a multi-agent system?

Almost certainly not. A single well-scoped agent handles nearly all business workflows more reliably and is far easier to debug.

Sources and Further Reading

McKinsey & Company, The State of AI in 2025: Agents, Innovation, and Transformation (5 November 2025). Enterprise adoption and agent scaling figures.

McKinsey & Company, Building the Foundations for Agentic AI at Scale . Data limitations as the dominant barrier to scaling agents.

Gartner, Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 (press release, 25 June 2025). Cancellation forecast and the “agent washing” phenomenon.

Yao, S. et al., τ -bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (arXiv:2406.12045). Introduces the pass^k reliability metric and documents the consistency gap in tool-using agents.

Model Context Protocol official specification and documentation (modelcontextprotocol.io). Open standard for connecting AI systems to tools and data.

Klarna and OpenAI joint announcement, February 2024; subsequent Bloomberg interview with Sebastian Siemiatkowski, May 2025; and Klarna’s own published response disputing the “reversal” characterisation.

Most businesses do not need a more capable AI. They need a clear view of which workflow is worth automating and which is not.

The GosAI

If you would like an honest assessment of where an agent would pay for itself in your business, and where a far cheaper solution would do the same job, get in touch with The GosAI.