Multi-agent setups pay off when each agent brings a discipline’s method. They turn into theatre when each brings only its tone of voice.
In the thirteenth year of their exile, the Pandavas had to live in disguise. If anyone recognised them, they would have to begin twelve more years in the forest. They went to the court of King Virāṭa, and each took on a new identity.
Yudhiṣṭhira became Kanka, a brahmin companion skilled at dice. Bhīma became Ballava, a cook. Arjuna became Bṛhannalā, who taught dance and music to the princess. Nakula looked after the horses, Sahadeva the cattle. Draupadī became Sairandhrī, a maid to the queen.
What strikes me about this story is not the disguise. It is why the disguise worked for a whole year in a watchful court.
Each of them could actually do the job.
Yudhiṣṭhira really did know dice; it was dice that sent them into exile. Bhīma really could cook, and wrestle, when the court’s wrestlers were challenged. Arjuna had learned music and dance in Indra’s realm. The twins really did know horses and cattle. Their personas held because a real craft stood behind each one.
And when the Kauravas raided Virāṭa’s cattle at the end of that year, the dance teacher took the chariot reins and then the bow. The method had been there the whole time.
Persona without method
This is the lesson I wish more multi-agent setups had absorbed.
The common pattern is to assemble a “team” of agents by name. A security expert, an architect, a QA lead, a product manager. Each gets a system prompt beginning “You are a world-class…”. They talk to each other. The transcript looks impressive. The output is often no better than one good prompt, because each agent changed its voice and kept the same method: read the code, form an opinion, write a paragraph.
The trap is role play that makes the transcript weirder without improving the result. The better rule is simple: don’t ask the model to write like a short seller, ask it to do what a short seller does.
Compare two prompts.
Review this service as a security expert.
USER STORYAs the service owner, I want the realistic security threats to thisservice identified and demonstrated, so that we fix what is exploitable,not what merely sounds alarming.DEFINITION OF READY- The service's data-flow diagram is in docs/dataflow.md.DEFINITION OF DONE- A STRIDE threat model built from the data-flow diagram.- For each threat rated high, a failing test that demonstrates it.- A proposed fix for each, which makes its test pass.DEFINITION OF SUCCESS- Each high threat's test fails on main and passes with its fix.
The first produces a security-flavoured essay. The second, built on STRIDE (a standard checklist of six threat types: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege), produces artefacts a security team would recognise and can check. That is the difference between Bṛhannalā in costume and Arjuna with the bow.
Nouns into verbs
There is a good trick in Tom Kelley and Jonathan Littman’s The Art of Innovation: replace the nouns with verbs. A noun hides the work. A verb reveals which disciplines it needs.
“A payments service” is a noun. As verbs, it is moving money correctly under partial failure, provably, and explaining every movement to an auditor years later. Now the disciplines are visible: distributed systems, reliability engineering, accounting, security and audit.
“A knowledge-graph pipeline” becomes turning messy documents into facts a technician can trust at a customer site. Now you can see information extraction, ontology design, data quality and field-service practice.
Assembling the crew
Once you have the verbs, pick the disciplines and, crucially, the specific method each one brings:
| Discipline | Method, not voice | Artefact it produces |
|---|---|---|
| Site reliability | Failure injection, game days | Fault-injection tests and a runbook |
| Security | STRIDE threat modelling | Threat list with a failing test per high threat |
| Reliability engineering | FMEA, FDIR | Failure-mode table with detection and recovery for each |
| Data engineering | Lineage and data contracts | Contract tests at each boundary |
| Accounting and audit | Double entry, reconciliation | Reconciliation checks that run on every change |
| Technical writing | Task-based documentation | A runbook a stranger can follow at 3 a.m. |
In plain terms: failure injection deliberately breaks a dependency to see whether the system copes; a game day is a planned, rehearsed outage; FMEA (failure mode and effects analysis) lists how each part can fail, the effect and how you would detect it; FDIR is fault detection, isolation and recovery; lineage traces where each piece of data came from; a data contract fixes the shape and meaning of data passed between teams; reconciliation proves that two independent records agree.
The red team deserves its own mention. For a business review, you might bring in a short seller and a forensic accountant. For code, the equivalents are the chaos engineer, who assumes everything will fail and proves which failures you survive, and the forensic auditor of your logs, who asks whether you could reconstruct what happened from the evidence you keep.
The method brief
When I set up sub-agents now (helper agents a main agent launches, each with its own fresh context), each gets a brief with five lines instead of a persona:
- Discipline: where the method comes from.
- Technique: the named method to apply.
- Input: the raw artefact it starts from.
- Output: the artefact it must produce.
- Check: how that output will be verified, by something other than itself.
These five lines fit inside the story template from Part 1: the input is the Definition of Ready, the output is the Definition of Done, and the check is the Definition of Success.
Each sub-agent works in its own context, so it is not anchored by the others. A merge step brings the outputs together, and that step is owned by a test or a human, not by another agent’s opinion.
For Monday
Take one feature in flight. Write it as verbs. List the three disciplines the verbs point to. For each, name the method and the artefact.
Example. Suppose the feature is “let customers schedule a recurring payment”.
Step 1: nouns into verbs. As verbs, the feature is: moving money on a future date with no human present, surviving bank downtime on that date, and letting the customer cancel right up to the cut-off. Three verbs, three disciplines: distributed systems, reliability engineering and consumer protection.
Step 2: one method brief per sub-agent. Here is the reliability brief exactly as it is given to the agent:
USER STORYAs the payments team lead, I want the scheduler's failure modes analysedthe way a reliability engineer would, so that every high-severityfailure has a proven recovery before launch.METHODDiscipline: reliability engineering.Technique: FMEA (failure mode and effects analysis).DEFINITION OF READY- docs/architecture/scheduler.md and src/scheduler/ are current.- The last 90 days of scheduler incident tickets are in incidents/scheduler/.- The RECOVERY_ENABLED flag exists and can be set to false in tests.DEFINITION OF DONE- fmea/scheduler.csv with columns: component, failure_mode, effect, severity (1-10), likelihood (1-10), detection, recovery.- For every row with severity >= 7, one fault-injection test under tests/faults/, named test_<component>_<failure_mode>.- You MUST NOT modify src/. Report gaps; do not fix them.DEFINITION OF SUCCESS- Each fault test FAILS with RECOVERY_ENABLED=false and PASSES on main. CI runs both. A test that passes either way is rejected.
The Definition of Success is what makes this a method rather than a persona. A test that cannot fail when recovery is switched off proves nothing, and the brief says so mechanically.
The distributed-systems brief targets idempotency: running an operation twice must have the same effect as running it once. Its main artefact is a test like this:
def test_scheduled_debit_is_idempotent(scheduler, ledger, clock): plan = scheduler.create(customer="c-17", amount_paise=250_000, day_of_month=5) clock.set("2026-11-05T02:00:00+05:30") scheduler.run_due() scheduler.run_due() # simulates a worker restart mid-run assert ledger.debits(customer="c-17", plan_id=plan.id) == [250_000]
The consumer-protection brief targets the race between cancelling and executing:
def test_cancel_one_second_before_cutoff_wins(scheduler, ledger, clock): plan = scheduler.create(customer="c-17", amount_paise=250_000, day_of_month=5, cutoff="01:59:59") clock.set("2026-11-05T01:59:58+05:30") scheduler.cancel(plan.id) clock.set("2026-11-05T02:00:00+05:30") scheduler.run_due() assert ledger.debits(customer="c-17", plan_id=plan.id) == []
Step 3: merge on evidence. The three sub-agents run in separate contexts. Their outputs come back as artefacts (a CSV, tests and a list of gaps), not opinions. The merge step is a CI run, not a fourth agent’s view. In this scenario the FMEA turns up a severity-9 row nobody had considered: the bank’s API confirms a debit, but the confirmation is lost in transit, so the scheduler retries and charges twice. The idempotency test catches it, and the fix gets a key, the plan_id plus the date, that the bank also receives.
Then run those three as sub-agents with method briefs, and compare the result with what one “expert reviewer” persona gave you. I expect you will not go back.
