Why a multi-agent system breaks on real tasks
Disparate internal services — customer records, invoicing, inventory, support — are almost never connected directly. A request is transferred by copying, status is synchronized manually, and an operator makes the decision on each inquiry.
A multi-agent system placed on top of such a landscape without a common bus inherits all the gaps and adds its own: agents do not have a consistent view of what step the customer is at.
In calm mode this is unnoticeable. At peak load, the queue of requests grows faster than it is processed: an agent loses context between steps, a retry creates a duplicate inquiry, and some tasks go to manual review.
The bottleneck in request processing turns out not to be the model, but the absence of a single state between calls and clear retry rules.
Automation failures accumulate quietly: the same customer is processed twice, an operator's comment does not reach the next step, a task hangs in an intermediate status, and no one understands who owns it.
Manual operations in the business process are not removed but simply move from the interface into chat. Instead of developing the product, the team holds the process together by hand — the load grows with the number of inquiries, not with the number of customers.
The cause is almost always at the schema level, not the quality of an individual model: there is no state owner, no idempotent processing, no single routing point between agents, and no transparent log of steps.
Below we break down how this is closed — from the contract between agents to degradation rules under overload.
What changes after implementation: measurable effect
The effect of a multi-agent system is measured not in demos but in process metrics taken before work starts and again a month after launch. Below are the specific indicators that change and what drives this.
Processing time
A pipeline of specialized agents parallelizes steps: extracting data from a document, reconciling with reference data, checking rules, writing to the accounting system.
Where an operator sequentially opened several interfaces, the processing time for one inquiry is reduced severalfold, and the bottleneck shifts to final human confirmation.
Share of manual operations
Steps with formalizable rules move to automation, while people retain exceptions and decisions with accountability.
The share of manual operations decreases from most typical requests to single-digit percentages — the freed time goes to non-standard cases, not to transferring data between windows.
Eliminated failure classes
Some failures disappear as a class: lost requests, duplicates during reprocessing, manual entry errors, missed deadlines. Each step follows one route in a single automation loop, and tracing based on OpenTelemetry shows at which transition it broke.
Predictability during peaks
Limiting concurrency, queues, and timeouts on each agent keeps a steady pace: load growth lengthens the queue but does not crash the process.
Behavior at peak is predictable because degradation is built into the configuration and verified by load runs, rather than discovered after the fact.
Orchestration options: comparison of approaches and limitations
Orchestration turns a set of separate models into a system with predictable behavior. The mode is chosen by the cost of error: the more irreversible the action, the more control points we embed in the chain. Below are three working options and their limitations.
| Option for organizing work | When it fits | Limitations |
|---|---|---|
| Autonomous mode | Repeatable chains with a verifiable result: processing incoming documents, classifying inquiries, data enrichment | An error at an early step multiplies across the entire chain; branching increases the number of model calls; iteration limits, timeouts, and a log of every step are mandatory |
| Human in the loop | Irreversible actions: payments, changing customer data, sending legally significant documents | Throughput is limited by the operator; a review interface and clear escalation rules are needed |
| Hybrid mode | Medium-criticality flows where typical cases close on their own | Requires reliable exception selection: with a weak confidence threshold, the entire flow goes to the operator |
The limitations of autonomous scenarios come down to the same thing: the system does not always stop in time and does not separate "I don't know" from "I'm confident." Therefore we set boundaries in configuration — a step limit per task, a list of allowed actions, result validation before writing. Changing the mode does not require rewriting the logic: thresholds and approval points change.
Implementation stages: from process assessment to handover
Implementation of a multi-agent system begins not with code but with analyzing how the process works today: who makes decisions, where data comes from, which exceptions break the regulation.
If this step is skipped, agents get an incorrect picture of the process and confidently produce a result no one uses. Each stage below is closed with a verifiable artifact.
- Process assessment. Interviews with performers, a map of steps, a list of decisions currently made by humans, and the volume of routine at each step.
- Schema and agent roles. Which roles are needed, what data and tools are available to each, where control points are placed, and who approves the result.
- Setup on real data. We connect sources, describe rules and limitations, and prepare reference examples — the system learns from them to distinguish a correct answer from a plausible one.
- Pilot launch on a narrow area. One process or one team, some operations in shadow mode: the system works in parallel with a human, and results are compared line by line.
- Test acceptance. Verification scenarios together with failures: unavailable source, contradictory data, a request outside the area of responsibility. We record the share of correct answers and behavior under uncertainty.
- Scaling. We expand to adjacent areas, fine-tune rules based on accumulated discrepancies, and connect quality control.
- Handover to operation. Regulations, documentation, training for the customer's team, appointment of the system owner, and the change procedure.
Going back one step at the schema stage costs hours; at the operation stage, it costs weeks of incident analysis.
What remains with you: configurations, schemas, regulations
A multi-agent system without documentation quickly turns into a black box: agent roles blur, changes go to production bypassing checks, and during a failure no one understands which step to roll back.
Therefore, along with a working loop, you receive a full set of artifacts — to operate and develop the solution with your own team, without mandatory dependence on us.
- Working configuration: launch parameters, environment variables, connection settings to your services and data — deployed on your stand according to instructions, without manual edits "from memory."
- Agent interaction schema: who passes a task to whom, where approval points are, how a failure of one participant is handled, and where the request goes next — with a diagram and textual description of scenarios.
- Role and permission description: what each agent and human operator is allowed to do, what data they can access, what requires confirmation — the access model is fixed, not reconstructed from code.
- Update regulation: the procedure for rolling out new versions and agent behavior rules, checks before publication, and the condition for rolling back to the previous build in one step.
- Logs and quality control: which events are written, where they are stored, by which metrics response degradation is visible, and how to analyze an incident from logs.
- Team instructions: short scenarios for the on-call engineer and developer — how to check operability, how to add a new agent, how to change a rule without rewriting the system.
- Recovery plan: what to do when an external service or model fails, what data is restored from backups, and within what time.
We hand over all artifacts in your environment — in a version storage and knowledge base, with owners responsible for keeping them up to date. Documentation is updated together with the code, not in a separate pass "sometime later."
Case study: reduced manual request processing threefold
The customer is a service company with a flow of inquiries from email, a website form, and WhatsApp. Requests were processed manually: an operator read the email, determined the topic and assignee, wrote a response, and had it double-checked by a manager.
When the flow grew by about a third, the shift stopped keeping up, and the queue began to grow faster than it was processed.
Metrics before: where time was lost
About 40% of inquiries were processed manually from start to finish, the average first response took 9 hours, and roughly every eighth inquiry was lost in correspondence between departments.
Typical questions — request status, terms, deadlines — took operators' time on par with complex ones.
What was changed
The flow was broken into stages and a multi-agent system was assembled.
A classifier agent determines the type, urgency, and topic of the inquiry; an executor agent prepares a response based on the knowledge base, contract, and customer history; a controller agent verifies the draft against the regulation, checks completeness, and references to documents.
Only disputed and non-standard cases go to the operator — according to explicitly defined escalation rules.
Metrics after: what became
The share of manual operations decreased threefold, the first response to the customer fits into minutes instead of hours, and there were no lost inquiries during the observation quarter.
Response quality control became measurable: the share of drafts that passed the controller's check without operator edits is about 87%.
Every agent decision is written to the log together with the rule version, so a disputed response can be analyzed and rolled back to the previous revision. The risks of overdue items, complaints, and customer churn due to lost emails are removed.
How is a multi-agent system different from a single assistant?
A single assistant is one model, one context, and one set of tools: it decides what to call and evaluates its own result.
A multi-agent system separates work by roles — data collection, execution, verification — and gives control to an orchestrator that holds the task state and step order.
A single scenario breaks where there are more than three steps and different access permissions are needed.
The context overflows, early clarifications are displaced by later ones, and one incorrect reasoning branch stretches to the finale — self-checking by the same model almost never catches such errors.
| Criterion | Single assistant | Multi-agent system |
|---|---|---|
| Number of steps | 1-3, linear | dozens, with branches and returns |
| Roles | one for everything | collection, execution, and verification separated |
| Access | a single set of permissions | each role has its own minimum |
| Failures | an error breaks the entire chain | one step is lost, the loop continues |
| Verification | self-check | independent controller agent according to rules |
Orchestration is not "several bots in one chat" but explicit transition rules. A router selects the executor, the result of each step goes into shared state, and limits on the number of steps and response time prevent the loop from cycling.
A typical framework is assembled on a graph layer such as LangGraph, where nodes are agents and edges are transition conditions; every decision is visible in the execution log.
A single assistant is enough when a task fits into one or two steps, there is one data source, and a human makes the decision.
If the cost of error is high and independent checks are needed — roles are separated; if a quick answer based on one document is needed, a second agent will add latency and an extra point of failure but will not add quality.
Technical doubts: answering before work starts
Before starting, we analyze not presentation but engineering questions: how agents will get data, who will allow them to do what, what to do with already working scenarios, and how to measure that the system is not degrading. Below are the questions technical teams ask most often.
How will the system integrate into our internal services?
Through the interfaces the services already have: queues, a message bus, or described methods. The agent does not go directly to the database — it calls an agreed method, and reading and writing are separated.
How are access permissions delimited?
Each agent has a separate service account with minimally sufficient permissions and a call limit. Dangerous operations — writing, sending, payment — remain behind human confirmation.
We already have automation deployed — will it have to be redone?
No: existing scenarios remain working, and we connect to them as a data source or call them as an agent tool. We only rewrite areas without idempotency.
How do you assess the quality of agent work?
We assemble a labeled set of typical inquiries and run each release against it: share of correct answers, false positives, share of handovers to humans. The metrics in the report mean degradation is visible before complaints, and rollback takes minutes.
What is needed to hand the system over to an internal team?
An agent interaction schema, interface specification, configurations, and update regulation. We hand over on your stand: your engineers run the scenario themselves and edit settings.
Let's discuss the task and come back with an estimate and plan
So that the estimate and work plan are based on facts rather than guesses, in the first conversation we need access to the real contour of the task: what already works, what data exists, where time is currently lost.
Then we describe the multi-agent system architecture, assemble the pilot composition, and fix acceptance criteria — then the scope of work stops being a subject of dispute at the handover stage.
What we need from the customer to discuss the task substantively:
- A description of the process as it goes now: who participates, how many steps, where manual operations are, and where it most often stumbles.
- Data: sources, formats, volumes, whether labeling exists, and who is responsible for keeping it up to date.
- Systems for integration: accounting, knowledge bases, request queues, as well as access to them and permission delimitation rules.
- What we consider success: share of inquiries closed without a human, answer accuracy, response time, reduction in the number of retries.
- Limitations: where autonomous action is unacceptable and operator confirmation is required, what requirements exist for storage and access.
- Who on the customer side accepts the work and by which scenarios will verify the result.
Based on the conversation, we return with an estimate and work plan: a map of agents and distribution of roles between them, a data exchange schema, pilot composition, and a set of checks for acceptance.
The first step is a narrow scenario where the effect and risks are visible, not the entire system at once. Describe the task in free form — we will name the stage timelines and what will be needed from your side.
