AI Bid Proposal Writing: Six Pitfalls We Learned the Hard Way

Reprint notice: This English translation is republished from Yige’s original Chinese article, “AI写标书踩过的那些坑” (“What We Learned the Hard Way About Writing Bid Proposals with AI”).

Over the past few months, we have been working with bidding teams to map out how AI can fit into their tendering workflows. Industries differ, proposal formats differ, and internal responsibilities differ, but the problems people describe are remarkably similar.

The documents are too long, deadlines are too tight, and supporting materials are scattered across different people. The worst outcome is spending days on a proposal only to lose the opportunity because of one seemingly minor omission.

A bid manager in the power industry told us that the tender documents they handle routinely run to hundreds of pages. In the past, it took several days just to organize the requirements. Before the technical solution or pricing had even begun, the team was already overwhelmed by qualification requirements, evaluation criteria, and required commitments.

They later asked agents to enumerate every item that required a response before writing and pricing began. The number of responses to qualification requirements that used to be missed dropped significantly. This case is also documented on the DesireCore website.

That approach sounds obvious, but implementing it was not as easy as expected. When people first discuss AI-assisted proposal writing, they tend to focus on questions such as “How many pages can it generate?”, “How quickly can it finish?”, and “Can it export directly to Word?” These capabilities are easy to demonstrate, and customers can immediately see the result.

After working through several real processes, however, we found that generating text was not the hardest part.

AI-generated prose is usually fluent. The table of contents, outline, and technical terminology all look convincing. That is exactly the problem: the more the output resembles a finished proposal, the easier it is to overlook whether it has actually answered every requirement in the tender documents.

The following are several pitfalls we encountered in practice and how we later addressed them in DesireCore.

Pitfall 1: Treating “Generation Complete” as “Proposal Complete”

In a demo, uploading a tender document and receiving dozens or even hundreds of pages within minutes looks impressive. I do not dispute the ability of large language models to produce long-form content, but bidding is not an essay contest. Length is not the same as completeness.

Suppose a tender document asks for evidence of comparable projects completed within the past three years. An AI can easily write, “The company has extensive experience delivering similar projects.” The sentence is perfectly readable and fits naturally into a technical proposal.

What matters during evaluation, however, is the specific project, contract date, value, acceptance records, and whether that evidence actually meets the definitions of “within the past three years” and “comparable project.” Without those materials, even excellent prose earns no points.

We therefore began requiring agents to provide more than a conclusion when handling critical eligibility requirements and evaluation criteria. At minimum, they must also provide:

• The exact requirement from the tender document and its location;
• A determination of compliant, non-compliant, or pending confirmation;
• The company materials used to support that determination;
• The validity period of certificates, project references, personnel records, and other evidence;
• What is still missing and who is responsible for providing it.

When evidence is unavailable, the agent should mark the item as “pending confirmation” rather than infer a plausible answer from context. This rule may seem conservative, but many proposal failures do not come from an inability to write. They come from writing something that cannot be fulfilled or proved.

Pitfall 2: Reducing Opportunity Monitoring to Keyword Alerts

Many companies already subscribe to tender-alert services that send notices based on industry, region, buyer, and keywords. These services answer “Where can we find opportunities?” but not “Is this opportunity worth pursuing?”

Our early discussions about opportunity-monitoring agents also tended to fall back on keyword matching and a composite score. A system might report an “87% match,” which looks precise, yet the bid manager still does not know why it is 87% or whether the remaining 13% contains a condition that would cause outright disqualification.

We stopped treating a single score as the primary output and instead asked the agent to produce a bid/no-bid analysis. It extracts the budget, deadline, eligibility requirements, experience requirements, bid security, delivery schedule, and other conditions, then compares each of them against the company’s qualifications, personnel, references, and risk thresholds.

Compliant items include evidence. Non-compliant items explain the gap. Ambiguous clauses are listed separately as clarification questions.

An agent can recommend whether to bid, but a person still makes the decision. The same applies to pricing, material commitments, and final submission. In DesireCore, these points can be configured as human gates, where execution pauses until someone confirms the next step.

I do not recommend delegating these decisions entirely to AI. Given current model capabilities and lines of accountability, that would be inappropriate.

Pitfall 3: Asking One Agent to Read, Write, and Review the Entire Proposal

The simplest setup is to create a single “bidding expert,” give it the tender documents, company materials, and past proposals, and ask it to analyze, write, review, and format everything. This can work for a simple opportunity, but complex bids quickly run into overly long context and conflicting roles.

Requirements analysis must be conservative and avoid missing constraints. Technical writing needs to elaborate within those constraints. Commercial and qualification sections depend heavily on evidence. Reviewers, meanwhile, must be willing to doubt every conclusion made earlier.

When all of these responsibilities sit with one agent, it writes the answer and then checks its own work. It will often fail to notice that its original interpretation was wrong.

We separated the roles, but not by mechanically creating more agents:

• A coordinating agent maintains overall progress, the compliance matrix, and task dependencies;
• A tender-analysis agent extracts eligibility requirements, evaluation criteria, disqualification clauses, and formatting rules;
• Technical, commercial, and qualification agents work only with the materials relevant to their own sections;
• A review agent does not participate in the earlier writing and performs a fresh review from the buyer’s and evaluator’s perspectives.

A real bid-writing workflow in DesireCore: the coordinating agent maintains the overall picture, while tender analysis, outlining, technical writing, and document review are assigned to different agents.

Each agent has independent context. During handoffs, agents pass the task, evidence, constraints, and completed results rather than copying the entire conversation history. This reduces irrelevant information and allows work that can run in parallel to proceed without waiting. More importantly, writing and reviewing are finally performed by different roles.

DesireCore’s cross-agent collaboration is designed primarily for workflows like this.

That does not mean more agents are always better. For a small proposal with straightforward requirements, one agent may be more efficient. A multi-agent design becomes worthwhile only when the work spans several disciplines, offers meaningful opportunities for parallel execution, or requires independent review.

Pitfall 4: Creating an Outline but No Compliance Matrix

AI is very good at generating outlines, and its first draft is often more complete than what a person would write from a blank page. But an outline only says what the team intends to write. It does not prove that every tender requirement has an owner and a response.

We later made the compliance matrix the primary intermediate artifact in proposal writing. Its structure is simple: map each tender requirement to the corresponding content in the bid.

I think of this table as a ledger of outstanding obligations. Every blank cell represents an unanswered question, and every “pending confirmation” must be resolved before submission. The outline may change and sections may be rewritten, but the compliance matrix cannot be discarded.

With this matrix, the coordinating agent knows which tasks can proceed in parallel and which must wait for supporting materials. The technical proposal can begin with a framework, for example, while sections containing specific product parameters must wait for vendor documentation. If the staffing plan changes, project résumés, the implementation plan, and related commitments must all be updated together.

These dependencies are continuously tracked by intelligent task orchestration, rather than discovered only when the final proposal is assembled.

Pitfall 5: Turning Proposal Review into General Copyediting

“Please review this proposal” is far too broad a task. An agent will usually check spelling, grammar, phrasing, and formatting, then offer a few generic risk warnings. That output is not useless, but it tends to focus on minor issues while missing the important ones.

We later divided proposal review into several independent workstreams:

1. Completeness review: Does every eligibility requirement, evaluation criterion, commitment, and attachment requirement in the tender documents have an explicit response in the bid?
2. Consistency review: Are the project name, values, dates, schedule, personnel, certificate numbers, quantities, and parameters consistent throughout?
3. Disqualification-risk review: Have any disqualification clauses, signature and seal requirements, authorizations, bid security, sealing, or upload instructions been missed?
4. Technical and scoring review: Does the solution actually answer the requirement, and is the supporting evidence sufficient for the corresponding score?
5. Document review: Are the table of contents, page numbers, heading hierarchy, image quality, attachment index, and final exported file correct?

Different agents can perform these reviews in parallel before the results are merged and deduplicated. Issues must be classified by severity, at least distinguishing between “affects submission or eligibility,” “requires human confirmation,” and “optimize if time permits.”

If hundreds of comments are sent to the proposal team without prioritization, the result is little better than no review at all. The genuinely dangerous findings become harder to see.

We also do not recommend allowing AI-generated edits to overwrite the original content automatically. DesireCore’s Super Document presents changes as a diff so users can accept, reject, or continue editing each one. People remain accountable for the proposal, so they should be able to see what the AI changed and why.

Pitfall 6: Teaching the Same Lessons Again for Every Bid

A general-purpose model understands the basic concepts of tendering, but it does not know how a particular company operates. It does not know which qualifications are about to expire, which project references may be disclosed, how the technical lead prefers to structure a solution, or the price threshold below which the company would rather decline to bid. Switching to a larger model does not make this knowledge appear automatically.

Much of a team’s experience is never formally written into policy. A senior proposal manager may habitually inspect certain pages first. Legal counsel may immediately escalate particular types of commitments. The team may have lost a bid in the past because of a specific class of mistake. This knowledge is scattered across people’s memories, old proposals, and project retrospectives, and it can easily disappear when personnel change.

The value of a trainable agent in this setting is its ability to retain corrections. During the first qualification review, a manager tells the agent, “Every compliant finding must be followed by evidence and an expiry date.” A technical proposal is returned because it did not answer each evaluation criterion individually. A retrospective shows that points were lost because project-reference evidence was incomplete.

These lessons should become rules that execute automatically on the next task, not merely edits to the current proposal.

A single user correction can become a verifiable principle for the agent. That is what it means to avoid repeating the mistake next time, rather than remembering it only within the current conversation.

In DesireCore, an agent’s rules, examples, skills, memory, and workflows are stored in AgentFS. These are inspectable, portable, and version-controlled files. When an agent learns a new rule, it produces a diff; the change takes effect only after user confirmation, and an incorrect lesson can be rolled back.

This is, in my view, the biggest difference between DesireCore and a conventional AI proposal-writing tool. Models provide reasoning and generation, while the experience accumulated by the company remains the company’s own asset. The longer the system is used, the value should extend beyond “saving a few hours on this bid” to avoiding the same mistakes on the next one.

If You Are Starting from Scratch, Begin with Proposal Review

I do not recommend that a company begin by pursuing fully automated bidding. It is difficult to establish trust, and problems can easily be hidden inside a draft that looks complete.

A safer approach is to choose a completed historical bid with a known outcome, then provide the tender documents, final bid submission, and retrospective materials together and ask the agent to conduct a full review.

The most experienced people on the team should then evaluate every finding: which issues were correct, which were false positives, and which dangerous issues the agent failed to identify. After updating the rules, run the same materials again until the agent can reproduce the team’s review standards consistently, then validate it on a second project.

Once proposal review is stable, add tender analysis and bid/no-bid assessment. Once the compliance matrix is reliable, try writing sections in parallel. Finally, feed win/loss results and actual delivery outcomes back into the retrospective. This sequence is less impressive in a demo than “generate a hundred-page proposal with one click,” but it is far more likely to work in practice.

Do not measure results only by generation speed. The number of missed eligibility requirements, coverage of mandatory responses, inconsistencies in critical fields, human review time, rework, and reuse of historical lessons are all more meaningful than word count.

Final Thoughts

Important: AI can assist with analysis and writing, but it cannot assume a company’s bidding responsibilities. The authenticity of qualifications, pricing, legal commitments, signatures and seals, and final submission must be confirmed by an authorized person.

When customer information, pricing, personnel certificates, and other sensitive data are involved, companies must also select models and deployment methods in accordance with their own data-governance policies.

What we want to build is not a proposal generator that ingests tender documents and automatically emits a Word file. We want bidding experts to be able to teach a team of agents how they work: who reads the tender, who writes, who finds evidence, and who looks for mistakes.

The team reports what it has completed, its mistakes can be corrected, and it does not have to start over when a similar opportunity arrives.

A reliable digital bidding team, like a real team, must be trained and refined across many projects. When a new tender arrives, it should first put the requirements, gaps, and risks on the table, and only then begin writing. I believe that matters far more than pursuing the promise of “a complete proposal in minutes.”

---

Further Reading

• DesireCore AI Bidding Solution
• Bidding Assistant: From Tender Analysis to Completeness Review
• How Multiple Agents Decompose, Parallelize, and Cross-Review Work
• Review Documents Like Code with DesireCore Super Document