Orchestrate without burning out: multi-agent for RFPs and the token economy

Strategy · May 2026 · Jacint Gauxachs Marin

A conductor routing tokens to specialist subagents while a banknote burns in the background

"We've migrated all our solutions to agent-orchestration systems… but the bill has gone through the roof. Why?"

That was the question a customer asked me in a small private meeting, after migrating every internal initiative to multi-agent setups, clearly improving outcomes and, at the same time, blowing past their cost expectations. It is the same crossroads any multi-agent system reaches when it moves from the "wow, this is cool" phase into the "what budget do we assign to it?" phase. Multi-agent works; the problem is that it works expensively.

Over the last few months I've built (and rebuilt) three different versions of a multi-agent system for answering RFPs: a step-by-step web app, a second iteration based on n8n flows, and the current one — an orchestrator with specialist subagents that produce .docx, .pptx and a real economic Excel. Each one taught me something different about when multi-agent pays off, when it doesn't, and, above all, what levers exist to mitigate its cost without giving up its value. There is one almost nobody talks about, and it has become the difference between an operable system and an expensive experiment: agents that don't consume the RAG, but rather build it.

Why multi-agent for an RFP

A halfway-serious RFP — administrative spec, technical spec, annexes, mandatory templates, compliance requirements, award criteria, target prices — is exactly the kind of task multi-agent is built for: high complexity, heterogeneous subtasks, high deliverable value. The presales person who answers it by hand spends two to five person-days per proposal, and most of that time isn't writing — it's reading, classifying, looking up internal references, computing prices and reviewing for consistency.

The four subtasks that always show up are:

Requirement extraction and classification — read the spec, separate technical, legal, commercial and timeline; identify exclusion criteria, map the mandatory vs. the desirable.
Background and solution lookup — find similar past proposals, relevant case studies, product datasheets, customer references.
Generation of response blocks — write the technical part, the services part, the team part and the annexes.
Cost and pricing computation — assemble the pricing model, adjust margins and produce the cost Excel and the financial offer.

Each subtask needs different tools, different context, and can run in parallel with the others most of the time. That is exactly what a well-designed multi-agent system does better than a single model: parallelize exploration and specialize execution. Anthropic published striking numbers: on the BrowseComp evaluation, a multi-agent system with Opus as lead and Sonnet as subagents beat Opus alone by 90.2%. The catch: that same system burns roughly 15× more tokens than a normal chat session, and 80% of the performance variance is explained by token usage.

Multi-agent is not magic — it is buying more compute in exchange for quality. The whole point of this article is how to spend that compute surgically.

The three iterations

Iteration 1 · The "step-by-step" web app

The first version I built as a Next.js web app with Prisma and MySQL — internally we call it generadorOfertas — that walks the user through a linear flow: create project → upload the spec PDF/DOCX/XLSX → AI context analysis → manage reusable sections → AI chat per section → final DOCX generation. Behind it, a single model (azure/gpt-4.1) served by LiteLLM with Redis as sidecars on Azure Container Apps, and Langfuse for observability.

The generation plumbing is interesting in its own right: five Python scripts (merge_docs.py, structure_content_with_ai.py, apply_corporate_styles.py, convert_pdf_to_docx.py, extract_excel.py) do the heavy lifting. merge_docs.py takes an array of sections — some as TipTap-editable HTML, others as pre-existing DOCX — and assembles the final document while applying corporate styles from a base template.

It worked for the first round of trials and ran into two limits quickly. First, prompts grew: each step needed context from the previous one, and eventually the model was getting tens of thousands of tokens per call to do relatively simple things. Second, it didn't scale upwards: doing real parallelism on top of a synchronous Next.js architecture is ugly, the 120s HTTP timeouts hang over you like a sword of Damocles, and the step flow stays hard-coded. Everything also went to a single model: no routing between easy and hard tasks, no embeddings actually used for retrieval (they were configured but unused).

That didn't write the tool off — it framed it. generadorOfertas is still in use and still evolving for predictable, standard RFPs, where a rigid flow is actually an asset: the salesperson knows exactly which steps to walk through, response times fit inside their workday, and cost per proposal is low. For that band, the app is the right answer. The problem appears when the spec leaves the standard track — and that is where I needed something different.

Iteration 2 · n8n flows

The second version moved the logic into n8n. The appeal here is that the graph is visual: a coordinator dispatches four branches in parallel — extractor, internal RAG lookup, block-by-block writer, and pricing calculator — and the hand-offs are visible on screen. Cost per proposal dropped roughly in half thanks to parallelism, and latency went from long minutes to a couple of minutes.

But the classic problem of low-code orchestration architectures appeared: the coordinator is dumb on purpose. n8n doesn't decide in real time that it needs a fifth subagent because it just discovered the spec has an unexpected SLA annex. You have to design every possible branch in advance. For "typical" specs it worked well; for the unusual ones — and the unusual ones leave the most margin — it fell short. We discarded this iteration: it overlapped with the territory the web app already covered without giving us what we needed for non-standard cases.

Iteration 3 · Orchestrator with specialist subagents

The current version — internally we call it presales_agent — is right now under active development as the definitive answer for any RFP or offer, especially the ones that don't fit the pattern. It's a Python system on top of a homegrown framework over LiteLLM, capable of talking indistinctly to the Anthropic API, AWS Bedrock or an internal proxy (CLIProxyAPI). The orchestrator runs a state machine with four phases (discovery → sizing → deliverables → iteration) and a tool-use loop with fourteen tools it decides between on every turn. The architecture, simplified:

Orchestrator (claude-opus-4-7)
   ├─ DocParser ────────→ extracts VMs, tables, SLAs from the spec
   ├─ DocAnalyzer ──────→ summary, keypoints, entities, priority
   ├─ CloudSizer ───────→ sizes Econocom private cloud
   ├─ CloudPublicoSizer → sizes managed Azure/AWS
   ├─ MSPSizer ─────────→ managed-services profiles
   ├─ CatalogAgent ─────→ fuzzy + semantic lookup over SQLite
   ├─ OfferReviewer ────→ catches duplicates, gaps, inconsistencies
   ├─ DocGenerator ─────→ narrative Word on Econocom template
   ├─ PPTGenerator ─────→ PowerPoint on the branded template
   └─ PricingEngine ────→ pure Python, no LLM

The qualitative leap over n8n is that the orchestrator decides at runtime. If the spec is cloud_privado-shaped, it invokes CloudSizer; if it's cloud_publico, it invokes CloudPublicoSizer; if it's mixed, both. If the reviewer flags an inconsistency, the orchestrator re-queues with specific feedback. It also produces the final deliverables in client-ready format — .xlsm with VBA macros preserved, .docx on the corporate template, and .pptx with the corporate branding — with no manual steps in between. For Excel, a headless LibreOffice pass forces a formula recalc before delivery, so when the client opens the file they see numbers, not empty cells.

And then, of course, the problem hit.

The bill

After the first two weeks of testing with real RFPs, the tokens consumed per proposal had multiplied by seven versus the n8n version. I won't publish the absolute number — it depends heavily on the type of spec and the customer — but the order of magnitude was enough for the conversation to stop being "this works great" and start being "how much will this cost us to run once it goes into production".

What was striking is that output quality was clearly higher — colleagues who reviewed the early proposals noticed without us pointing it out. The multi-agent was doing its job. The problem was structural: three orchestrator behaviours were inflating cost without adding value.

First, rework loops with no discipline. Recent literature suggests that review-and-rewrite loops consume around 59% of tokens in agentic systems. The reviewer would catch something, send it back to a writer, the writer would rewrite, the reviewer would look again — and sometimes it stayed in a loop until a hard limit kicked in.

Second, unnecessary expansion. Anthropic states it word-for-word in their engineering post: early agents would spawn fifty subagents for simple queries. Mine never reached fifty, but it kept inventing subagents for things a deterministic workflow would have handled with zero tokens. The flagship example: cost computation, which has zero ambiguity — it's arithmetic over a catalogue. That no longer goes through an LLM at all.

Third, verbose handoffs. When the search subagent returned its findings to the orchestrator, it sent a long transcript of its reasoning, not just the conclusion. The orchestrator stuffed all of it into the next subagent's context. Each link in the chain dragged the weight of the previous ones.

The question stopped being "does multi-agent pay off?" and became "what levers do I have to keep quality and cut cost by 60–70%?". That is the interesting conversation.

The levers

I'll go through them ordered by impact, with the numbers I observed in my case and the ones circulating in the literature. They aren't alternatives, they layer — and combined they typically cut 70–80% off the untouched baseline.

1. Cascade routing

The single highest-impact change. The rule is brutally simple: classification, extraction and formatting go to cheap models; complex reasoning and consolidation go to top models. Research quantifies it: a routing layer that sends easy tasks to cheap models and hard tasks to expensive ones cuts cost by 40 to 60%; the spread between models can reach 190× on the same task.

In my case, moving the requirement extractor to Haiku 4.5 — with no measurable quality loss — cut that subtask by 85%. The final assignment for Iteration 3, after cleanup, is this:

Subagent	Model	Rationale
`Orchestrator`	`claude-opus-4-7`	Decisions, planning, consolidation
`DocParser`	`claude-sonnet-4-6`	Structured extraction with tables and SLAs
`DocAnalyzer`	`claude-sonnet-4-6`	Summaries and entities, vision support
`CloudSizer` · `CloudPublicoSizer` · `MSPSizer`	`claude-sonnet-4-6`	Sizing reasoning
`CatalogAgent`	`claude-haiku-4-5-20251001`	Fuzzy + semantic lookup, high volume
`OfferReviewer`	`claude-haiku-4-5-20251001`	Targeted verification, not creation
`DocGenerator` · `PPTGenerator`	`claude-sonnet-4-6`	Writing quality on a template
`PricingEngine`	No LLM	Deterministic arithmetic — no model needed

That last row deserves its own paragraph: the best token optimization is not spending them. Cost computation — summing catalogue cost, applying margin, recomputing Excel formulas — is plain Python. I had it as an agent at first; moving it to deterministic code lost no capability whatsoever, gained speed and dropped cost to zero. Apply this question to every agent you have: does it actually need to reason?

2. Prompt caching

The second most powerful lever, and the most underused. Anthropic's prompt caching gives a 90% discount on cached input tokens. In multi-agent the effect compounds, because every subagent repeats system prompt, tool descriptions and base context on every call — those tokens are perfect for caching.

Structuring prompts with the static blocks at the top (system prompt, instructions, examples) and the dynamic ones at the end (the actual query) drives a very high cache-hit rate. In my system this alone shaved another ~25% off total cost. The investment: half an afternoon reordering prompts.

3. Structured handoffs

The antidote to verbose handoffs. The rule: subagents return structured JSON to the orchestrator, not transcripts. Reasoning stays in the subagent's isolated context and dies there; only the result reaches the orchestrator. Concretely, every orchestrator tool has a fixed schema and the merge of results is keyed on a stable identifier (hostname, line ID, etc.), with no prose re-injection.

The key technical detail: every subagent has its own context window and returns a fixed schema. The orchestrator never sees the how, only the what. Output tokens, remember, cost 4× to 8× more than input tokens — compressing output is where the leverage is.

4. Orchestrator discipline

Orchestrator prompts must scale effort to complexity. An explicit instruction along the lines of "for simple queries, use a single subagent and at most two tools; reserve parallelism and specialist subagents only for tasks that clearly justify it" changes the inflation behaviour.

In my system this took the form of an orchestrator prompt with an explicit budget per proposal — an indicative cap on subagents and reviewer iterations. The reviewer now does one or two passes max. If issues remain after the second pass, it escalates to a human. That single rule killed the bulk of the 59% rework.

5. Output discipline and Chain of Draft

Beyond structured output and aggressive max_tokens, there is a prompting trick almost nobody uses: Chain of Draft instead of Chain of Thought. The model writes each reasoning step in five words or fewer instead of full paragraphs. It matches accuracy at 7–8% of the reasoning-token cost. For subagents that need to think but don't need to justify themselves, it's a one-line prompt change with disproportionate effect.

6. Local + cloud routing

The lever that makes the biggest difference against a pure-cloud architecture, and the one most aligned with where Econocom AI Fabric is heading. In my tests, requirement extraction and RAG-query reformulation (which now only handle small chunks of text and return JSON) moved to a local Gemma 4 31B in vLLM. Marginal cost per token: zero. Latency: as good as or better than cloud, no network round trip. Privacy: the spec doesn't leave the perimeter until the technical writer, in the cloud, actually needs it for the response blocks.

This is exactly what the literature on hybrid architectures argues: use local open-source models for well-scoped routine work, frontier cloud for hard reasoning and edge cases. The technical piece that matters is having a gateway layer that abstracts the origin — in my case LiteLLM — so the subagent doesn't know whether its model lives at localhost:11434 or api.anthropic.com. Switching the engine is a config line.

7. Semantic cache for the RAG

The questions the technical writer asks the RAG ("past proposals with critical SLA", "banking cloud-migration cases", "OpenShift deployments in public sector") repeat conceptually across proposals. A semantic cache in front of retrieval — embed the question, similarity-search over previous queries, return results without invoking an LLM — eliminated another 15–20% of calls. The similarity threshold needs careful tuning to avoid over-caching, but the gain is substantial.

Mitigation cascade. Each lever acts on the residual cost of the previous one; order matters. The percentages are indicative and reflect the behaviour I observed, not a guarantee. The first two levers (routing and caching) already cut more than half and can be deployed in a week.

Agentic RAG: agents that build the RAG, not just consume it

This is the section that matters most to me, and the one that pushes hardest against the usual narrative.

RAG, as it is taught, is a passive system: you index your documents, generate embeddings, and the agents query them. The quality of the whole system depends on how the ingestion was done — chunking, metadata, extracted text quality. And ingestion is usually batch, manual and mediocre. Poorly OCR'd PDFs, slide decks with text inside images, Excels with pivot tables, old proposals in heterogeneous formats. RAG inherits all that misery, and then we complain that the agent hallucinates.

My proposal is to flip the flow. Turn ingestion into a specialist multi-agent process, where the arrival of a document triggers its own little reasoning pipeline before anything touches the index.

The target architecture has four chained agents:

Document analyzer. Detects the type (past proposal, product datasheet, case study, internal policy, legal template), pulls out structural metadata, decides what processing to apply next. Cheap model; well-scoped task. In the current system this is what the DocAnalyzer agent (Sonnet) already does — it produces summary, keypoints, entities and a priority 1–5 per document, with vision support for images.
Content extractor. Converts the document into clean, type-aware text. For poorly OCR'd PDFs, it calls an agentic OCR that reprocesses with corrections. For decks, it extracts text and describes figures. For Excels, it extracts tables as structured markdown and describes the content. For long documents, it does semantic chunking, not token-count chunking. Today this is covered by DocParser: it detects VMs, tables, textual requirements and SLAs in PDF/DOCX/XLSX specs.
Semantic enricher. Generates section summaries, topic tags, named entities, relevant dates, customer sector, service typology, criticality. This is persisted as chunk metadata in the vector store. It's the natural next step for the current pipeline.
Quality validator. Reviews samples of the output, detects inconsistencies or information loss versus the original, and flags the document for reprocessing if quality drops below a threshold. Closes the loop before garbage enters the index.

The result is a RAG where each chunk isn't a raw text blob — it's a unit rich in metadata, validated, and most importantly describable. When the technical writer asks for "banking cloud-migration cases with 99.99% SLA", retrieval returns the three most relevant chunks filtered by sector and criticality, not fifteen noisy ones. That more than compensates for the extra ingestion cost.

Key point. Agentic ingestion pays for itself in the first month of RAG usage. Every well-ingested document is queried dozens of times across the year; every query against a clean RAG reduces the context fed to the top model, avoids reviewer iterations and reduces hallucinations. It is exactly the kind of asymmetric investment that makes most economic sense in multi-agent: spend tokens once on ingestion so you don't burn many on every single query.

It also fits the broader trend I'm seeing in serious 2026 systems: stop treating RAG as a document-search system and start treating it as a structured knowledge base built by agents. Ingestion stops being a dumb nightly job and becomes a small cognitive pipeline of its own, with its own quality criteria, retries and traceability.

When NOT multi-agent

I've defended multi-agent, but it's worth closing on the other side. There are tasks where a single, well-instructed model beats any orchestrator. The rule of thumb I apply:

Trait	Single-agent wins	Multi-agent pays off
Complexity	Scoped task, single dimension	Heterogeneous sub-domains
Output value	Low or medium	High or very high
Cost tolerance	Sensitive	Investment justified
Useful parallelism	Linear, strong dependencies	Simultaneous exploration
Predictability	Predictable steps	Runtime decisions

A ticket-classification task doesn't deserve an orchestrator. A proposal to a strategic customer does. The conversation isn't ideological — it's a calculator argument.

And inside multi-agent, the principle that never fails: the best token optimization is the one you avoid spending. Every time you add a subagent, you have to justify why the incremental quality it brings beats its marginal cost. If it doesn't, what you have isn't an orchestrator — it's an expensive experiment.

Final thought

Multi-agent is neither the universal answer nor a lab experiment. It is one more architecture, with a very specific cost-benefit equation: pay 15× more tokens in exchange for 90% more capability on heterogeneous, high-value tasks. The interesting question isn't whether to use it, but how to spend those tokens with surgical discipline.

The three iterations of the RFP system I've built have left me with one conviction: the orchestrator isn't the winner on its own; the winner is the hybrid architecture. Small, local models for routine well-scoped tasks; top cloud models for reasoning; a RAG built by agents instead of populated by scripts; aggressive caching at every layer where it fits; an orchestrator with an explicit budget; a deterministic pricing engine that doesn't even touch the LLM; and, above all, the discipline not to add one more agent just because you can.

That is exactly the direction Econocom AI Fabric is going — designed so that orchestrating agents, routing them between cloud and on-prem, caching their outputs and observing their cost is routine operation, not a project. If the next phase of enterprise GenAI is about moving from cool demos to systems that can survive a bill, the difference will come from platforms that treat cost as a first-class citizen, not a metric you only look at at month-end.

Multi-agent is here to stay. You just have to keep it on a tight leash.

Back to articles