Thirty-one pages, and the specification was good. Genuinely good: numbered acceptance criteria, a data dictionary, edge cases pulled out into their own section, the kind of document that lets a delivery lead sleep for the first time in a week. We were forty minutes into the review when a woman who had joined late, and who owned the billing platform rather than the product, asked what happens to an order already in flight when a customer deletes their account. Silence. The document covered deletion thoroughly. It covered retention, export, consent, and the audit trail, and it had simply never met that question, because the person who wrote it had never once had to reconcile a charge against a customer who no longer exists.
One reviewer. That is the entire distance between a specification that ships and a specification that ships a refund path nobody designed. Which is why the current shape of AI for requirements work keeps bothering me, and I say this as someone building in the category: nearly every tool available, including several I admire, points one model at your input and asks it for a specification. That is the meeting above with only the first analyst in the room, running at machine speed.
Adding agents does not automatically fix it, and that caveat goes first because the pitch writes itself and the evidence refuses to cooperate. Yubin Kim and colleagues built a systematic study of agent scaling across 260 configurations, six agentic benchmarks, five multi-agent architectures and three model families, holding tools, prompts and token budgets constant so that structure was the only moving part. On decomposable financial reasoning, multi-agent systems beat the single-agent baseline by 80.8%. On strictly sequential planning they lost to it by 70.0%. The number of agents is not the variable. Whether the work actually splits is the variable.
What does multi-agent AI actually mean for business analysis?
It means several agents with different jobs, different instructions and different definitions of success, working the same source material and permitted to disagree with each other in writing. Not one model called five times. That distinction sounds like hair-splitting right up until you watch it fail, because five calls to the same model with the same framing return five confident variations of one blind spot: they share a prior about what matters, so they skip the same thing five times and hand you a consensus that feels like corroboration.
Specialization is the whole mechanism. An agent told to be exhaustive about unstated scenarios behaves differently from an agent told to attack the assumptions underneath a document, not because one is smarter but because the objective function moved. Give the second one an explicit mandate to be wrong in public and it will surface things the first one politely smoothed over. Most enterprises have not gone anywhere near this yet, which is useful context before anyone panics about falling behind. Anthropic, working with Material, surveyed more than 500 technical leaders in late 2025 for The 2026 State of AI Agents Report: 57% now use agents for multi-stage workflows, while only 16% have reached cross-functional or end-to-end processes that span teams. Most of the market has learned to sequence agents. Almost none of it has learned to make them argue.
Why does a single requirements agent produce plausible but shallow specs?
Because a single agent optimizes for a document that reads as finished, and finished is not the same as complete. Watch what a single pass does with ambiguity. Your source material says the system should "notify the customer when the order status changes," which is four or five requirements pretending to be one, and the model has to do something with it. It picks. It picks the most probable reading, writes a clean requirement, and the fork in the road vanishes into competent prose instead of arriving on your desk as a question about which status changes, through which channel, at what hour, and what happens when the customer opted out of one channel but not the other.
I used to file this under prompt engineering. Ask better, get better, and there is real truth in that; a well-constructed prompt visibly improves a first draft. Then I watched enough first drafts to notice that the improvement plateaus somewhere well short of what a competent human review produces, and the reason is structural rather than lexical. A single pass cannot simultaneously be the author defending a document and the critic attacking it. Those are opposed objectives. Ask one agent to do both and it does the polite version of both.
The academic picture is consistent with that ceiling. Anna Arnaudo and colleagues at Politecnico di Torino evaluated large language model pipelines for goal extraction in requirements engineering in April 2026, testing in-context learning strategies and a generation-critic mechanism using paired models. Their pipeline reached 61% accuracy on low-level goal identification. Their own conclusion is the honest one, and it is quotable: the approach is best suited to accelerating manual extraction rather than replacing it. Sixty-one percent is genuinely useful. It is also nowhere near a number you would bet a regulated release on.
Which Business Analyst disciplines map to which agents?
Map them to what a strong Business Analyst actually does, not to the sections of a document template. This is where most agent designs go sideways: they assign one agent per deliverable, a user-story agent and a process-flow agent and a glossary agent, which produces a faster assembly line for the same single perspective. Four disciplines cover most of the real ground, and each one has a different question it is constitutionally unable to stop asking.
Read those four again and notice they are not four views of the same artifact. They are four different failure modes. A missing scenario, an untested assumption, a buried disagreement and an unjustified rule fail differently, get caught by different people, and cost money at different moments in a project. Which is exactly why running the same reviewer four times catches roughly one of them.
On August 11, 2020, Citibank meant to send Revlon's lenders an interest payment of about $7.8 million. It sent roughly $893 million instead, the entire outstanding principal on a syndicated loan, out of Citibank's own money. The bank spent the next two years in court trying to get it back.
Here is the part every requirements person should sit with. This transaction was not casually approved. It went through Citibank's "six eyes" protocol, which requires three separate people to review and approve before execution: a maker who enters the payment, a checker who verifies it, and a senior approver who signs off last. Three reviewers. To suppress the principal and route it to an internal wash account, the loan platform required three fields to be overridden, FRONT, FUND and PRINCIPAL. All three reviewers believed that checking PRINCIPAL alone would do it. All three were wrong in exactly the same way.
Six eyes, one mental model. The protocol added redundancy and zero diversity, so it multiplied confidence without adding a single new question, and the failure it was designed to prevent walked straight through it. That is the precise failure mode of five calls to the same model with the same prompt. Three humans could not catch it either, because none of them had been given a different job.
Sources: In re Citibank August 11, 2020 Wire Transfers, findings of fact and conclusions of law, U.S. District Court for the Southern District of New York, February 16, 2021 (520 F. Supp. 3d 390), and the Second Circuit opinion in No. 21-487, September 8, 2022, which reversed and allowed recovery. Industry: banking operations software.
The lesson generalizes past finance, and it is the reason I keep coming back to this case rather than a software one. Redundancy is not review. Three people applying one shared understanding of a screen produce one opinion delivered three times, and the organization reads the three signatures as three independent checks when they were always a single point of failure wearing a process. Design your agents to disagree or do not bother building four of them.
How is multi-agent discovery different from automated requirements analysis?
They work at different layers, and the honest answer is that you want both. Automated requirements analysis, the single-pass natural language layer that tools like ScopeMaster occupy well, takes the requirements you have already written and tells you which ones are ambiguous, untestable, duplicated or badly sized. It measures a real artifact against real criteria and it does that faster and more consistently than a human reviewer at 4pm on a Thursday. If your requirements exist and you are not running something like it over them, start there.
Multi-agent discovery sits one step earlier, before the artifact exists at all. Its raw material is the interview transcript, the ticket thread, the policy PDF nobody has opened since the last audit, the argument in a Slack channel that got resolved by whoever typed last. Its output is not a cleaner document. Its output is a list of questions and contradictions, ranked, with a note on who can settle each one.
Put plainly: validation checks the page, discovery questions what never made it onto the page. The order matters too, because the cost of a missing requirement compounds through every downstream artifact, which is the thesis we laid out in what requirements intelligence actually is. Analysis cannot flag an ambiguity in a requirement that was never written. Nothing can.
And this is the part where the Kim study earns its place rather than decorating the article. Requirements discovery decomposes almost perfectly: four disciplines can read the same corpus in parallel, produce independent findings, and be reconciled at the end, which puts it firmly on the +80.8% side of that boundary rather than the -70.0% side where a strictly sequential plan collapses under coordination overhead. It is not free, though. Anthropic reported that its own multi-agent research system outperformed a single-agent configuration by 90.2% on an internal research evaluation while burning roughly fifteen times the tokens of an ordinary chat, and that is the vendor grading its own homework, so read it as an order of magnitude and not a benchmark. Fifteen times. Point that at every two-line ticket in your backlog and you will deserve the invoice.
What does a multi-agent business analysis workflow look like in practice?
Narrower than most people expect, and that is the point. You are not replacing the Business Analyst, a position we argued at length in whether AI will replace your Business Analyst, and nothing here changes that answer. You are giving one analyst four tireless colleagues who each read everything and each refuse to stop asking one particular question. Five steps:
- Pick a capability, not a backlog. One capability where a missed requirement costs real money: payments, entitlements, anything a regulator reads. The economics of a fifteen-times token bill only work when the downside is expensive.
- Feed the agents the mess, not the summary. Transcripts, tickets, the old policy document, the contradictory email chain. A summary has already had its ambiguities resolved by whoever wrote it, which deletes exactly the signal you are hunting.
- Give each agent its own mandate and its own success criterion. The skeptic is rewarded for finding a false assumption, not for agreeing. Shared prompts produce shared blind spots, every time.
- Reconcile, then rank by blast radius. The four agents will produce overlapping and occasionally contradictory findings, and that friction is the product. Sort what survives by what it costs if it stays unanswered.
- Route each open question to a human who can settle it. An unanswered question is not a finding; it is a ticket with a name on it. This step is where the value actually lands, and it is the one teams skip.
Step five is the whole thing, honestly. Everything upstream just gets you a better list. What the agents cannot do is walk to someone's desk and make them decide, and any vendor implying otherwise, including us, should be read carefully.
One agent gives you one perspective. Discovery needs four.
Multi-agent AI for business analysis means agents with different jobs, different instructions and different success criteria, allowed to disagree in writing. Not one model queried repeatedly. Map them to Business Analyst disciplines rather than document sections: an interviewer for unstated scenarios, a domain skeptic for inherited assumptions, a conflict surfacer for silent disagreement, and a traceability checker for rules with no justification behind them.
More agents is not automatically better, and the research says so plainly: 80.8% better than a single agent when the task decomposes, 70.0% worse when it is strictly sequential. Requirements discovery decomposes cleanly by discipline, which is what puts it on the right side of that line. Single-pass automated analysis validates the requirements you wrote, and it is worth having. Multi-agent discovery surfaces the ones you never wrote, which are the ones that reach production.
What are the most common questions about multi-agent AI for business analysis?
