What to put in a multi-agent system development RFP

A multi-agent system development RFP should specify four things: the workflow in decision-level detail, every system the agents must read or write, numeric acceptance thresholds, and who owns the code, prompts and infrastructure afterwards. It should not specify the orchestration framework. Those four sections are what make competing quotes comparable rather than merely different.

What follows is the section structure we would use if we were buying, with the sentence to write in each and the vague version it replaces. It is written from the receiving end: these are the gaps that force a bidder to pad a number or, worse, to quote low and re-scope in month three.

Why most AI RFPs produce incomparable bids

A multi-agent system is a set of specialised agents coordinated by a planner, calling scoped tools against your systems, with a reviewer checking output before anything is committed. The cost of building one is driven almost entirely by integration surface, autonomy level and evidence requirements, and almost not at all by the model or the framework.

Most RFPs invert this. They name a framework, ask for a chatbot-style feature list, and leave the integration list and the acceptance thresholds to a discovery phase after signature. Three vendors then return three prices for three different projects, and the cheapest one is cheapest because it assumed the least. You cannot fix that in evaluation; you fix it in the document.

The corrective is to write the RFP around the work rather than around the technology. If you have not yet mapped the workflow to that level, a ten-day AI Discovery Sprint at $3,250 or ₹2,00,000, credited to a subsequent build, produces exactly the artefacts an RFP needs, and you can then take them to any bidder.

Section by section: what to write, and what it replaces

Two sections deserve more space than an RFP template usually gives them. The integration list is the single largest cost driver, so name each system, say whether it exposes a documented API or only a screen, and state whether a sandbox exists today. A bidder who learns in month two that your core system has no write API will re-scope, and they will be right to. The autonomy table is the second: for every action the agents might take, write draft only, act with approval above or below a stated threshold, or act alone. That one table moves a quote by tens of thousands more reliably than any other page in the document.

The acceptance criteria that make a quote hold

Acceptance is where most agent contracts go soft. Ask for numbers against a named artefact, and supply the artefact yourself so every bidder is scored on the same cases.

• A frozen scenario set. Two hundred real cases with known correct outcomes, supplied by you, used for acceptance by everyone. Without it, each bidder grades their own homework.
• Task completion rate. The share of scenarios the system finishes correctly without human intervention, stated as a threshold per intent rather than an average across all of them.
• Escalation appropriateness. Escalating a genuinely ambiguous case is a success, not a failure. Score it separately or you will incentivise reckless autonomy.
• Groundedness. Every factual claim traceable to a retrieved source or a tool result. This is the metric that catches confident invention.
• Action correctness and blast radius. For write actions, the share executed correctly, plus the maximum value a single wrong action can move.
• Cost per completed task. Not cost per call. This is the number that decides whether the system is affordable at volume, and it belongs in the contract.
• Latency at the 95th percentile. Average latency hides the tail, and the tail is what users experience as broken.

The metric definitions are expanded in how to measure an AI agent, and our general position on evidence over demonstrations is in evals over demos.

What to ask about governance and risk

For anything touching customer money, health records or personal data, ask bidders to state how their controls map to a recognised framework rather than to describe their approach in prose. The NIST AI Risk Management Framework gives a vendor-neutral structure of govern, map, measure and manage functions that a bidder can answer against, and a bidder who cannot answer against it is telling you something useful.

Alongside that, ask three specific questions: where does data physically sit and does any of it leave your tenancy; what is retained and for how long, including prompts and traces; and how are actions audited so a regulator or an internal auditor can reconstruct a decision. For Indian operations, ask explicitly about the DPDP Act posture and, in financial services, about alignment with RBI outsourcing expectations.

Commercials: what to ask for, and what to expect

Ask for a fixed price against a fixed scope, with the change mechanism written down, rather than a day rate. Day rates transfer every estimation risk to you. Ask for the price to be broken into discovery, build, shadow mode and hypercare, so you can see what each bidder believes the evidence phase is worth; a bid with no shadow-mode line has not planned one.

For calibration, multi-agent systems and workflow orchestration start at $24,500 or ₹16 lakh and run to $84,000 or ₹56 lakh depending on agent count, integration depth and autonomy. A three-week ProofRun at $6,250 or ₹4,00,000 proves the hardest step first. Care Plans run from $1,000 or ₹68,000 a month to $5,250 or ₹3,40,000 with a named engineer, plus $750 or ₹40,000 for the AI add-on covering evaluation runs, cost monitoring and prompt regression. All of it is on the pricing page, and the drivers behind the range are broken down in multi-agent system development cost in 2026.

Ask each bidder to name the assumptions their price depends on, and to say what happens to the number if each one turns out to be false. A serious bid will list three or four: that the CRM write API exists, that historical cases are available in a machine-readable form, that one approval owner can settle thresholds, that peak volume is within a stated multiple of the average. A bid with no assumptions section has either not read the workflow or has priced the risk into a margin you cannot see.

State in the RFP that you will pay for your own model API usage through your own accounts, with the vendor responsible for routing, budgets and dashboards. It keeps inference costs visible and stops a margin being hidden inside a per-transaction price.

When an RFP is the wrong instrument

If you cannot yet name the workflow, the systems or the volumes, an RFP will produce padded bids and a long evaluation for a decision you are not ready to make. Run a discovery engagement instead and issue the RFP afterwards with real artefacts.

An RFP is also the wrong instrument when the honest answer may be that you do not need a multi-agent system. If the workflow is a fixed linear sequence, a workflow engine is cheaper and more predictable. If one agent with four good tools finishes the job, buy that. And if a commercial product already covers eighty per cent of the requirement, the build versus buy decision should be settled before procurement starts, not inside it.

A final pass before you issue it

• Every integration named, with API status and sandbox availability stated
• One real case traced end to end and attached as an appendix
• Two hundred scenarios prepared, or a date by which they will be
• Autonomy level stated per action, with the approval owner named
• Acceptance thresholds numeric and per intent, not averaged
• Ownership of code, prompts, infrastructure and documentation stated as yours
• Support term, response times and evaluation cadence specified
• No framework named anywhere in the document

Related reading

Questions to ask a multi-agent system development vendor before you sign covers the conversation after the bids arrive, how long does multi-agent system development take gives you a schedule to sanity-check proposals against, and AI agent orchestration explains why the framework choice belongs to the builder rather than to your RFP.

Write the workflow, the integrations, the thresholds and the ownership; leave the architecture to the bidders, and you will get three quotes you can actually compare. If you want a scope reviewed before you issue it, send it to us.