Proposal Copilot

• Try the live agent
• Read the code on GitHub

---

1. The problem: a confident sentence with nothing behind it

I built Proposal Copilot for the consulting round of the Bottoms Up 5.0 case competition with my team, WD Advisors. The case: VCG, a 2,000-consultant firm, has six possible uses for generative AI, ₹8 crore of ideas and ₹3 crore to spend. We had to pick three, and build a working AI agent for one of them.

Proposals are where consultants feel the pressure most. In the case, 1,200 consultants spend about 180 hours a year each on them, roughly 216,000 hours in all. Most of that time goes on the same loop: read a long RFP, hunt through old case studies and CVs for proof, write it up, then have a partner check it.

The obvious product is "AI writes the proposal". The problem with it is just as obvious once you try it. A language model writes "VCG has previously redesigned lending for a large Indian bank" with exactly the same confidence whether or not that happened. In a proposal, every sentence is a promise, and a partner who can't tell which sentences are true has to re-check all of them. That isn't saving time.

So the real question wasn't "can AI write a proposal?" It was:

2. Why proposals, out of six options

We scored all six of VCG's options on value, ease of building, adoption, risk and strategic fit. Proposal Development made our funded three, and it was the clear choice for the agent for three reasons:

• It has a real workflow. Intake, a bid decision, drafting, checking, sign-off. An agent needs steps; a chat window doesn't.
• It already has human gates. A practice lead decides whether to bid, and a partner approves the price. The agent could fit around decisions the firm already makes instead of inventing new ones.
• Its time turns into revenue. An hour saved on a proposal can go into the next bid. In the case's numbers, it costs ₹1.1 crore to build, returns ₹0.5 crore in year one and ₹0.9 crore a year by year three.

3. The bet: the model writes, rules check, people decide

Every design choice comes from one rule: the model only writes. It never decides whether a sentence is true, whether to bid, or whether the proposal can go out.

1. 01

   Read and search

   Pull out each requirement with its exact quote, then find proof in past work

   ↓→

2. 02

   Bid or no bid?

   A practice lead decides, with a name and a reason

   ↓→

3. 03

   Draft

   The model writes from the selected evidence only, and cites it

   ↓→

4. 04

   Check every claim

   Rules test numbers, names and context against the source

   ↓→

5. 05

   Sign off

   Sections, the price and every gap, each by a named person

4. A run, screen by screen

Here is the agent on a sample RFP from "ABC Bank", a retail bank in India that wants to redesign its lending process. The RFP asks for proof of more than a 30% improvement in turnaround time. The firm's best real result is 18%. That gap is the point of the demo.

The bid decision. Before any writing, the agent checks how much of what the client asks for the firm can actually prove. Of about 20 requirements, four need proof from past work, and the documents prove two. It says so, recommends a review rather than a bid, and waits for a practice lead to decide and give a reason.

The state of the draft. After drafting, the overview says plainly that the proposal is not cleared for release, and lists exactly why.

A claim that passes. For any sentence, the reviewer sees five steps: the client's requirement, the exact quote from the RFP, the source passage, what the model wrote, and the verdict. The name, the role and the 18 years all match the partner's CV.

A claim that doesn't. This sentence reads like a credential: a past lending redesign for a large Indian bank. It cites nothing, so it can't go out. This is the sentence that gets a firm into trouble, and the agent catches it before a partner reads it.

Release. Three things have to be true before export: every section approved, the price signed by a partner, and every blocked claim either fixed or overridden with a written reason. If anyone edits the price after the partner signs, the sign-off is cancelled.

5. The decisions, and what each one cost

Decision	What I chose	What I gave up
Who checks the claims	Fixed rules: numbers, names and context must match the cited source	An AI judge, which could catch subtler errors but marks its own homework
Where the model is used	Writing the sections, and nothing else	Model-led reading of the RFP: I tested it, and a small model made it worse
What counts as a requirement	Only one that quotes the RFP word for word	Requirements the model “infers” the client wants
When evidence is missing	A visible [EVIDENCE GAP] in the draft	Smooth filler text that reads better and hides the hole
How the bid score works	Share of requirements the evidence actually proves	Share where search found something, which scored an 18% case 100/100 against a 45% ask
Who can release	Three named sign-offs; a changed price voids the partner’s	One-click export
Where the model runs	A hosted model for the demo; a local model when tenders can’t leave the firm	One setup for both: hosted is faster and better written, local keeps data in

The model earns its place only where I measured it. My first version used the model for every step. On a small local model, reading the RFP through the model scored bid fit at 0% and left 70 citations pointing at nothing, because the requirements it extracted matched no evidence. Splitting the draft into individual claims hung for 14 minutes. Plain parsing did both jobs instantly and better. So the model writes, and the structure around it is ordinary code.

"Supported" means consistent, not true. I was careful with the words in the product. The agent checks a claim against the firm's own documents. If a document is wrong, a claim built on it will pass. The interface and the README both call it evidence checking, not fact-checking.

6. How I built it

I wrote the spec and the acceptance tests first, then built the agent with Claude Code as my pair programmer. It's Python, with a Streamlit interface, keyword search over the firm's documents, and every run saved to a database so it can be reopened and audited. A few things I'd point a reviewer to:

• The demo was a test before it was a feature. The firm's documents include an office sustainability report where electricity use fell 35%. When the model claims a 35% lending improvement, the number exists in the corpus, just in the wrong place. The rule only accepts a figure if the words around it match the claim's topic. "18% passes, 35% is caught" was written down before any code, and the test suite checks it on every change.
• I tried to break my own checks. An independent audit and a round of adversarial testing found eleven ways to sneak a claim past the verifier. Each one became a fix and a test. The fixes include catching a claim that cites one real source and one invented one, checking a figure whatever verb introduces it, and refusing "other Indian banks" when one of the cited cases is from Southeast Asia.
• Expectations were written before results. For five new sample RFPs, I wrote down what the agent should do, from the documents alone, before running it once. Then I compared.
• It reports its own cost. Each run records tokens, time and cost: about 14,500 tokens and ₹0.16 at paid rates for a full proposal. The cost of this product is integration and reviewers' time, not the model.

7. How we’d know it works

The model's cost rounds to zero, so the measures that matter are about the people around it. One of them is a rule, not a target:

Metric	Why it matters	Target
Unsupported claims that reach a client	The whole promise of the product	Zero, every time
Reviewer minutes per section	Is checking a sourced draft faster than writing it?	Below the time to write it, measured against a baseline
Share of claims backed by evidence	How much useful text the model produces	Rising as search and the model improve
Overrides, and their reasons	Each reason is a fix list for the rules or the documents	Falling over time
Win rate on proposals that used it	The business result, slow to show	Tracked quarterly against similar bids

The pilot I’d run: one practice, real proposals on documents the firm is allowed to use, and a stopwatch on partner review time. If drafting gets faster but review gets slower, we've moved the bottleneck, not removed it.

8. Where it stands, and what's next

The agent works end to end on synthetic data, and the live demo runs a real model. Running it showed me where it falls short, which is more useful than the demo itself:

• It blocks true sentences that forget to cite. In one run, the same fact about the lead partner was supported in one section and blocked in another, depending on how the model attached its citation. Safe, but it creates review work.
• The model writes far more than the evidence supports. On the free model, a handful of claims out of about 80 were fully backed. Some of the rest are fine sentences with no citation; some are section headings the checker treats as claims.
• The bid screen shows a score, not the gaps. The agent knows which requirements failed and why ("the RFP asks for 30%, the best evidence is 18%"), but the screen only shows "2 of 4". A practice lead deciding on a number is the wrong design.
• Search is basic, and the company systems are sample files. The CRM, HR and rate-card inputs are labelled samples, not live connections.

What I'd do next, in order:

1. Cut the noise. Attach the citation automatically when a sentence matches a selected passage word for word, and stop checking headings.
2. Put the gaps on the bid screen, with the reason for each, so the decision is made on evidence rather than a percentage.
3. Run the pilot above with real proposal writers, and measure reviewer time before anything else.

9. What I learned

• Write the failing test before the feature. "18% passes, 35% is caught" told me what done looked like before the model wrote a word.
• Use the model where it earns its place, and measure that. It made the writing better and the structure worse.
• An honest gap beats a confident sentence. The most valuable thing the agent produces is the list of things it can't prove.
• Trust is a design problem. Reviewers don't need a smarter model; they need to see the working: the requirement, the quote, the source, the verdict.