Back to blog

Thought Leadership

Thought Leadership·March 25, 2026·13 min read

The throughput trap: why more AI does not mean more contracts won

The market is flooded with tools promising to 'respond to tenders faster with AI.' No one asks the real question: responding faster to more tenders with mediocre responses -- is that progress, or an accelerator of failure?

By Aléaume Muller

récenceheuristiqueconfirmationancrage

The throughput trap: why more AI does not mean more contracts won

This article extends and synthesizes the series: Market transformation, IT services case study, Bid manager biases, Executive summary. It asks the question no one asks: what if the race to automate produced the opposite of what it promises?

The promise no one verifies

The pitch is everywhere: "Thanks to AI, respond to 3x more tenders. Reduce your production time by 60%. Automate your responses."

It is appealing. It is measurable. And it is the wrong metric.

A bid manager who responds to 50 tenders per year with a 25% conversion rate wins 12-13 contracts. Give them a tool that triples their production capacity. They now respond to 150 tenders. But if the quality of each response drops -- because the tool produces generic output, because strategic thinking time is compressed, because Go/No-Go is sacrificed in the name of volume -- their conversion rate falls to 10%. Result: 15 contracts won. Three more. But 100 more losing responses. 100 team mobilizations without return. 100 times the opportunity cost of a poorly targeted proposal.

Throughput increased. Did performance? Far less clear.

50 tenders x 25% = 12 contracts won. 150 tenders x 10% = 15 contracts won -- but 100 more losing responses. We are optimizing the wrong metric.

And no one measures. Because no one calculates the real cost of a lost response. Because the displayed KPI is "number of responses produced," not "value generated per response." We are optimizing the wrong metric.

The real bottleneck is not drafting

Here is the implicit hypothesis of 90% of AI tools for tenders: the problem is the time spent drafting.

This hypothesis is false.

Drafting time is a symptom. The real bottleneck is the decision. Which angle to take? Which positioning to adopt? What are the 3 win themes that will run through the entire response? Where to focus -- on price, methodology, team, or references? Does the client want to be reassured or impressed? Is their real problem the one they wrote in the specifications, or the one they did not dare articulate?

These decisions are what win or lose a contract. Not the speed at which the resulting paragraphs are produced.

A senior bid manager may spend 60% of their time drafting. But the remaining 40% -- analysis, strategy, positioning -- determine whether the 60% of drafting produces a winning response or a filler. Accelerating the drafting without touching the decision-making means producing mediocrity faster.

This is exactly what we described in the IT services case study: a tool that produces the statistical average of all past responses, faster. Throughput increases. Relevance does not.

The three levels of AI in tenders

Not all tools are equal. But the market presents them as a continuum when they are in fact three fundamentally different paradigms.

Level 1: the chatbot -- the passive assistant

This is the entry point. ChatGPT, Claude, Gemini, used conversationally. The bid manager pastes a specification excerpt, asks for a reformulation, and receives a paragraph.

It is useful. For the same reason a spell checker is useful: it polishes the surface. But the chatbot takes no initiative. It does not know what it does not know. It does not ask questions. It does not challenge your assumptions. It produces what you ask it to produce -- including when you ask for the wrong thing.

The chatbot inherits all your biases. If you are anchored to your last proposal, it recycles your anchoring with eloquence. If you overestimate the quality of your approach, it defends it with conviction. It is a mirror with perfect grammar.

And above all: the chatbot has no memory. Every conversation starts from zero. It capitalizes on nothing. The brilliant proposal from three months ago does not exist for it. The mistake that cost you a contract last week does not exist either.

Level 2: the autonomous agent -- the sophisticated executor

One level up. The autonomous agent does not merely respond to a prompt -- it decomposes a task into steps, uses tools, navigates documents, and maintains context. Advanced RAG, specialized agents, multi-step orchestration.

This is a genuine step forward. The agent can analyze an entire specification without you having to copy-paste the right passages. It can cross-reference requirements against your past references. It can structure a response outline.

But it remains an executor. A fast, methodical, tireless executor -- but an executor.

The problem with the autonomous agent is that it does what it is told without asking whether it is the right thing to do. It produces a requirements analysis -- but it does not ask whether certain requirements are decoys, copy-paste from previous specifications, or weak signals of an unarticulated pain. It generates a technical response -- but it does not make explicit the implicit assumptions on which that response rests.

Autonomy is not intelligence. An autonomous drone can fly on its own. That does not mean it knows where to go.

Level 3: the cognitive and architectural model -- explicit reasoning

This is where the break occurs. And this is where almost no one operates.

A cognitive model does not merely execute tasks. It makes its assumptions explicit, traces its inferences, and renders its reasoning auditable.

Concretely, the difference manifests at every step of the process:

Specification analysis does not merely produce a list of requirements. It produces a hypothesis map: "The client mentions data migration three times in 80 pages --> hypothesis: this is where they were burned in the past. The infrastructure lot spans 15 pages, the application lot 2 --> inference: the client masters the functional side but fears the infrastructure. The schedule mandates go-live before the elections --> non-negotiable political constraint, everything else is secondary."

These hypotheses are not buried in a model's weights. They are written, visible, contestable. The bid manager can read them and say: "No, this inference is wrong -- I know this client, their real problem is internal team turnover." And the system integrates this correction. Not in a prompt that will be forgotten at the next chat. In a persistent structure that informs the entire remainder of the proposal.

Response strategy is not a template. It is a documented reasoning: "Given [validated hypotheses], the optimal positioning is [X] because [Y]. Alternatives considered were [A, B, C]. A was discarded because [reason]. The retained win themes are [1, 2, 3]."

This is the difference between a doctor who prescribes a treatment and a doctor who explains their diagnosis, their differential hypotheses, and why they ruled out the other options. Both prescribe. The second allows you to challenge them -- and correct them when they are wrong.

Drafting is not text generation. Every section of the response is backed by a reasoning: "This paragraph exists to address [requirement X], building on [win theme Y], via [proof Z]." If the bid manager removes a section, the system can tell them: "Warning -- this section covered requirement 4.3.2 of the specifications. If you remove it, this requirement is no longer addressed anywhere."

This is not more autonomy. It is methodology. It is the difference between a process that produces text and a process that produces reasoning -- of which the text is merely the final manifestation.

The real issue: crystallizing the signal, not amplifying the noise

The primary danger of AI applied to tenders is not poor writing. It is amplifying noise and ignoring signals.

Deconstructing a tender package is not parsing 1,000 pages to extract the obvious. It is mobilizing, against the accumulation of words, pattern detection and semantic relationships -- identifying hypotheses and testing them immediately against evidence -- in order to populate a rich ontology where the noise has disappeared and where needs, requirements, facts, and even the implicit become clear.

A cognitive model does not answer a tender for you. It crystallizes meaning in an ocean of noise. It does not invent the solution: it excavates it. It does not create a technical proposal: it reveals the technical proposal your client wants. And it goes further: it drafts the proposal that the client -- and you yourselves -- need to write and to read. It does not tell you what to do blindly: it reveals the key trade-offs that will give genuine meaning, genuine intent to your value proposition and your project plan.

"Other AI tools accelerate production. The cognitive model accelerates understanding."


Why explicitation changes everything

The bid manager who uses a chatbot does not know why the AI wrote what it wrote. They cannot challenge it. They cannot correct it in a targeted way. They can only say "redo" -- without knowing what to improve.

The bid manager who uses an autonomous agent knows what the AI produced, but not why. The agent analyzed the specifications and output a list of requirements. But which ones did it consider critical? On what criteria? Did it flag repetitions as importance signals, or ignore them? Impossible to tell. It is a more performant black box -- but still a black box.

The bid manager who works with a cognitive model knows why every decision was made. They see the hypotheses. They see the inferences. They see the alternatives discarded and the reasons. They can intervene at the right level: not on the final text, but on the reasoning that produced it.

This is the same principle as in McKinsey consulting: you do not deliver a slide deck. You deliver a structured reasoning of which the slide deck is the presentation. If the client challenges a recommendation, you do not change the slide -- you revise the underlying hypothesis and the entire reasoning realigns.

In bid management, the equivalent is: if the bid manager challenges a win theme, the entire executive summary, the entire argumentative structure, and all associated proofs realign. Not because the AI "rewrites everything." Because the reasoning is explicit, and a change in hypothesis propagates naturally through the entire system.

The observability problem

There is a blind spot the industry ignores: no one knows whether an AI-generated response is better or worse than a human one.

Public tenders rarely provide detailed feedback. When feedback exists, it is an overall score -- 14/20 on the technical section -- with no indication of which paragraphs made the difference. Private tenders are even more opaque: you won or lost, period.

Result: no feedback loop. The AI tool produces responses. Some win, some lose. But no one knows whether it was because of the AI or despite it. No one knows which sections convinced and which lowered the score. We are flying blind.

This is fundamentally different from classical machine learning, where you have a clear metric (accuracy, recall, F1) and continuous feedback. In bid management, feedback is rare, late, partial, and noisy. Building an AI tool without solving this observability problem is building an aircraft without an altimeter.

A cognitive and architectural model attacks this problem differently: since every hypothesis and every inference is explicit, you can retrospectively compare the hypotheses that led to a victory vs. those that led to a defeat. "Across the last 10 contracts won, the hypothesis 'the client prioritizes schedule security over innovation' was validated 8 times." This is the beginning of real capitalization -- not on words (which paragraph to recycle), but on reasoning (which client understanding logic works).

What this implies for decision-makers

If you are evaluating an AI tool for your tender responses, ask these three questions:

1. Does the tool produce text or reasoning? If it gives you paragraphs directly without making the underlying hypotheses explicit, you can neither challenge nor correct it. You are a surface proofreader, not a response director.

2. Does the tool remember? If every proposal starts from zero, you are not capitalizing. You are accelerating production without improving the process. In a year, you will make the same mistakes faster.

3. Does the tool contradict you? If the tool systematically validates your orientations without challenging them, it amplifies your biases instead of correcting them. A good system must be able to say: "Your hypothesis about the client's priorities is contradicted by the following signals in the specifications."

These three criteria separate the three levels. The chatbot fails all three. The autonomous agent fails the first and third. The cognitive model satisfies all of them.

CriterionChatbotAutonomous agentCognitive model
Produces reasoning (not just text)NoNoYes
Remembers and capitalizesNoPartialYes
Challenges your assumptionsNoNoYes

What to remember

The AI market for tenders is in the same position as the e-commerce market in 2005: everyone understands it is the future, no one has yet found the right model, and the majority of investment is going in the wrong direction.

The wrong direction is more text, faster. It is the throughput trap: optimizing volume instead of optimizing understanding.

The right direction is a paradigm shift: from AI that drafts to AI that reasons. From AI that produces paragraphs to AI that makes hypotheses explicit. From AI that obeys you to AI that challenges you.

Not an improved chatbot. Not a faster autonomous agent. A cognitive and architectural model -- a formalized methodology, traceable inferences, contestable hypotheses. Where the final text is merely the visible consequence of an auditable reasoning.

Key takeaway: The right question is not "how to produce more responses" but "how to produce better decisions." Throughput without reasoning is mediocrity at scale.

This is the only way to simultaneously solve the three problems this series has identified: the mediocrity of recycling, the biases of the writer, and the hollow executive summary. Because all three problems share the same root: a process that produces text without making explicit the reasoning that should underpin it.


This is the conviction that underpins TenderGraph. Not a chatbot facing a set of specifications. Not an autonomous agent that executes without questioning. A cognitive model that makes every hypothesis explicit, traces every inference, and renders the reasoning auditable by the bid manager -- so that the human judges at the right level. Our vision details this approach.


Further reading:

Tags

#tenders#AI#LLM#strategy#multi-agents#ontology#bid-management#cognition

Next step

Ready to transform your tender response?

Keep reading

Recommended articles