The first multi-agent design Matroosberg Digital Consulting drew for its proposal system had eleven agents, one for every major section of the RFP response. Executive summary, understanding of the requirement, solution architecture, security, data migration, delivery plan, team, support model, risk, pricing narrative and compliance. It was neat, it mirrored the table of contents, and it would have produced a bid that contradicted itself in at least four places.
Matroosberg, a fictional South African digital consultancy, was answering RFP BDPI 07/2026 from the fictional Bontebok Department of Permits and Inspections: about 100 pages of specification, special conditions and annexures for a cloud-hosted permit and inspections platform with a three-year managed service. Part 1 described the governed system that sits around the drafting. This part is about the drafting itself, and about the moment a response is large enough that one agent, or one person, cannot hold it.
The question is not whether to use several agents. CloudNala has already argued that a multi-agent design is an organisational choice and that every hand-off must carry an owner, a bounded authority and a record. Those rules apply here unchanged. What a proposal adds is a particular failure: many parallel writers producing sections that must all describe one solution, one team, one timeline and one price.
Sections are not responsibilities
The eleven-agent design split the work by the shape of the document. That is the wrong cut. Two sections that draw on the same evidence, under the same permissions, judged by the same people, gain nothing from separate agents. They only gain a hand-off.
The useful cut is by what differs: the data a role may read, the judgement it applies and the way its output is checked. Applied to the Bontebok bid, that test produced six roles, not eleven.
- Coordinator. Builds a typed brief for each section from the requirement model, sends it out, and merges what comes back. Its control flow is code; a model helps it write briefs and spot gaps. It drafts nothing itself.
- Solution architect. Drafts the solution, integration, security and data sections. It may read the evidence library and the architecture patterns, and nothing commercial.
- Delivery planner. Drafts the plan, the team and the support model. It is the only role that may read the resourcing plan, because who is available in which month is internal and changes weekly.
- Commercial analyst. Builds the price schedule and its narrative from the work breakdown. It is the only role that may read rate cards and the history of past prices, which are among the most confidential data the firm holds.
- Compliance reviewer. Checks every requirement identifier against an answer and every returnable against the package. It is a checker, with read-only access and its own test set.
- Red-team release gate. Reads each build as a sceptical evaluator and a future delivery team would. It is the subject of the second half of this article.
The three drafting specialists are separate because their data boundaries are different. The two checkers are separate because a checker that shares the drafter's context tends to agree with it. Everything else (executive summary, understanding, risk) is drafted by the solution architect role under a different brief, or by people.
The shared fact problem
Parallel drafting fails in a specific, predictable way. Each specialist makes a reasonable local assumption about something the whole response depends on, and the assumptions disagree.
In Matroosberg's first trial run, using an old bid with the names removed, the solution section described 24-hour support for priority-one incidents, the support model described business-hours cover with an on-call engineer, and the price had been built for business hours only. The delivery plan showed go-live in month five; the executive summary, drafted earlier, said month four. The team section listed eight people and the price assumed seven. None of these errors was visible in any single section. Each section was internally sound.
This is coordination debt in its proposal form. The remedy is not a cleverer merge. It is to stop letting facts live inside sections at all.
Matroosberg's shared facts register holds every fact that more than one section relies on: go-live and milestone dates, hosting region and recovery region, availability and support hours, team size and named key people, the price basis and its validity period, and the main assumptions and exclusions. Each fact has one owner. Specialists may read the register and must refer to it, but they cannot change it. When a drafter needs a fact to be different, it raises a change request against the register, and the owner decides. Part 4 returns to who may approve which changes.
Three rules make the register work:
- Briefs cite facts by identifier. A section brief says "support hours: F-07", not "support hours: business hours". When F-07 changes, every section that cites it is marked for redrafting.
- Returns declare what they used. Each specialist returns its draft with a list of the facts it relied on, the evidence items behind each claim, any new assumption it had to make and any question it could not answer. A new assumption is not allowed to enter the response silently.
- Merge is a check, not a paste. The coordinator compares every return against the register before it builds the document. A draft that states a fact differently from the register is rejected back to its owner, with the difference highlighted.
The register is small. On the Bontebok bid it held 41 facts (an illustrative count). It removed the most common class of contradiction before any reviewer saw a page.
What the hand-offs carry
The hand-off between coordinator and specialist is where proposal context is most easily lost. A good section brief, in Matroosberg's design, contains:
- the requirement identifiers the section must answer, with their clause references;
- the evaluation criterion and its weight, so effort goes where points are;
- page or word limits from the RFP;
- the evidence items the section may draw on, and an instruction to use nothing else;
- the shared facts it must cite;
- the win themes it should support, from the qualification record.
The return carries the draft, the claim list with evidence identifiers, the facts used, new assumptions and open questions. Both are typed, both are validated on arrival, and both are written to the pursuit record against the same pursuit and build identifiers. A reviewer can open any paragraph in the final document and see which brief produced it, which evidence it relied on and which build it entered.
What it costs
Several agents are not free. In How we built our multi-agent research system (June 2025), Anthropic reported that, in its data, "multi-agent systems use about 15× more tokens than chats". The same post says that "some domains that require all agents to share the same context or involve many dependencies between agents" are not a good fit for multi-agent systems today. A proposal has exactly that kind of dependency. That is one more reason to keep the drafting roles few and to put shared facts in a register rather than in every agent's context.
The other costs are the ones every split adds: a contract per hand-off, a trace per agent, an evaluation per agent plus an end-to-end one, and a named owner. Matroosberg's rule is the one from Subagents are a cost-control pattern: a split must isolate something, such as data, cost or judgement, or it is removed.
The red team is a release gate
Bid teams already run independent reviews. Red-team, submit and learn from evidence describes pink, red and gold reviews by people who have not been living in the bid. That review stays. People are better than any model at judging whether a response would persuade a sceptical evaluation committee.
What changes with a system is when the checking happens. A human red team reads one or two near-final drafts. A red-team agent can read every build, and in a pursuit system the response is rebuilt many times a day. Matroosberg made the red-team agent a release gate: no build moves to the human review until it has passed five checks.
- Compliance completeness. Every mandatory requirement has an answer, every returnable on the RFP's list is in the package, and every scored criterion has content. This overlaps with the compliance reviewer deliberately; the gate checks the assembled build, the reviewer checks the requirement model.
- Unsupported claims. Every factual claim (a certification, a reference, a number of similar projects, a named person) points to a current evidence item. A claim with no evidence, or with expired evidence, is a finding.
- Scope and price contradictions. Everything in the solution and plan is priced, everything priced is in scope, and every section agrees with the shared facts register.
- Delivery feasibility. The plan fits the resourcing plan, dependencies on the department are stated as client responsibilities, and no milestone depends on an unconfirmed assumption without saying so.
- Security, legal and reputational risk. No commitment exceeds the firm's standard liability and service positions without an approval, no clause from another client's bid has leaked into this one, and no personal information is included that the RFP did not ask for.
The gate has exactly three outcomes. Pass. Pass with accepted risk, which needs a named person and a written reason, recorded in the pursuit record. Block, which returns the finding to the owner of the section that caused it. The gate can block a build. It cannot approve a submission, rewrite a section or accept its own risk.
Testing the tester
A gate is only as good as the evidence that it finds what it should. Matroosberg built a seeded test set: past bids, with names removed, into which the team planted known defects of each type. These included a missing returnable, a lapsed certificate presented as current, a priced component missing from the architecture, a milestone that the resourcing plan could not meet and a paragraph copied from another client's response.
The red-team agent is evaluated against that set whenever its prompt, model or rules change. The measure that matters is which seeded defects it misses, by type, rather than an overall score. When it missed the copied paragraph in an early version, the team added a deterministic similarity check against the library of past submissions, because that particular defect is better found by code than by judgement. That is the same move recommended in Evals that gate real work: measure the step against labelled cases, and convert what can be converted into rules.
The gate's checker runs under a different prompt from the drafters, does not see their reasoning, and is owned by the bid quality lead rather than by the team that owns the drafting agents. That keeps the separation of duties real.
A decision table
| Proposal role | Separate agent? | The boundary that justifies it |
|---|---|---|
| One agent per document section | No | None; sections share data, permissions and reviewers |
| Coordinator | Yes, mostly code | Owns briefs, merge and the build |
| Solution architect | Yes | Reads technical evidence only |
| Delivery planner | Yes | Only role with access to the resourcing plan |
| Commercial analyst | Yes | Only role with access to rates and price history |
| Compliance reviewer | Yes | Independent checker with its own test set |
| Red-team release gate | Yes | Independent of drafters; blocks builds, never approves |
| Executive summary writer | Usually no | Same evidence as the solution role; written last, by a person |
If a proposed agent's only distinction is a different prompt, fold it into an existing role.
Key points
- Split proposal work by data, judgement and checking, not by the table of contents.
- Parallel drafting fails on shared facts. Hold them once in a register with owners, make briefs cite them and make merge a check against them.
- Hand-offs carry typed briefs out and typed returns back: requirements, criteria, limits, permitted evidence, facts, claims, new assumptions and open questions.
- Make the red-team agent a release gate on every build, with five checks and three outcomes. It blocks; it never approves.
- Test the gate with seeded defects, measure what it misses by type, and move what you can into deterministic checks.
This is part 2 of Engineering Proposal Intelligence. Previous: The AI proposal builder is not the product. Next: Proposal memory is not a folder of old documents.
Background reading: How we built our multi-agent research system (Anthropic, 13 June 2025); Building effective agents (Anthropic, December 2024).
How CloudNala can help
CloudNala reviews multi-agent proposal designs before they are built. We test each proposed agent against the boundary it claims to create, design the shared facts register and the brief and return contracts, and specify the red-team gate's five checks, its outcomes and a seeded defect set, so that adding agents removes contradictions from your bids instead of multiplying them.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Proposal Intelligence Review or write to us at consult@cloudnala.co.za