neesh Inc.
Case Studies

Your best proposals take 12 hours to write. This one took 3 minutes.

Tom Reeves, a senior consultant at Greystone Advisory, spent 8–12 hours on every proposal. Every engagement started from a blank document. Every pitch varied by who wrote it and how much deadline pressure they were under — not by what the firm actually knew. We built a generation system that takes context in through a guided wizard, runs 7 specialist agents in parallel, validates the output through a quality gate, and delivers a complete, client-specific document ready for review — in the time it takes to finish a coffee.

Composite scenarios: fictional companies, written to illustrate what our platform is designed to do. The figures are design targets, not measured client results.

Python FastAPI PostgreSQL + pgvector Claude Haiku Claude Sonnet Claude Opus Next.js AWS ECS Fargate
Book Free Assessment

Screen recording coming soon

~3 min from context to complete draft Design target — vs. 8–12 hours manually
7 specialist agents running in parallel sections written simultaneously, not sequentially
≥ 7.0 quality gate score to pass every document validated before delivery
< $0.40 LLM cost per document Design target — routing is cheap, writing is mid, judgment is expensive

When Expertise Has No Institutional Memory

Greystone Advisory had grown to a five-person boutique — deep expertise, a strong win rate, and no institutional memory. The knowledge that won pitches lived in the heads of whoever wrote the last successful proposal. It did not accumulate. It did not compound. Every new engagement started from scratch.

Tom Reeves, Senior Consultant

  • Eight years of proposals. Hundreds of client engagements. None of it is in a form that helps write the next one. Every RFP lands in the inbox and the clock starts over.
  • The good proposals — the ones that won — took a full day. The mediocre ones took just as long. Quality was not a function of effort. It was a function of deadline pressure and which version of the problem framing came to mind first.
  • Three hours into drafting, still on the executive summary. The context doc is open in another tab. The scope section from a similar engagement is open in a third tab. The blank document is still mostly blank.

The Managing Partner

  • Five people on the team. Three of them write proposals. All three write differently. Winning a pitch depends on who wrote it, not on what the firm actually knows how to do.
  • The best proposal writer left in March. The win rate dropped. Nobody had written down what she knew.
  • Reviewing a draft at 9pm. The scope section is vague, the pricing section assumes a different team size, the executive summary does not match the approach. The client receives it at 11pm with a note: "let us know if you have questions."

Seven Stages From Context to Document

The system does not write generic proposals. It decomposes the context the consultant provides, assigns specialist agents to each section, runs them simultaneously, validates the output for internal consistency, and assembles a complete document — all before the conversation with the client is over.

The Generation Pipeline

1

Decompose

Claude Haiku analyses the wizard inputs and the available specialist registry. It selects the appropriate agents for this document type and flags any gaps in the provided context — sections that require information not yet supplied. Fast, cheap, structured output. The routing decision costs less than half a cent.

2

Confirm

If the decomposition identifies gaps, the system pauses and surfaces them to the consultant for confirmation before running. A 30-minute timeout. This is the mechanism that prevents hallucinated details from entering a client-facing document. The pause is intentional — it is cheaper than a revision.

3

Specialists

Each selected specialist agent runs simultaneously. Executive summary, problem statement, approach and scope, pricing and timeline, risk and assumptions — all written in parallel by Claude Sonnet agents configured for their specific section. The time cost is fixed regardless of how many specialists run.

4

Review

Before assembly, a review pass reads all specialist outputs together and checks for cross-section conflicts: scope promises that the pricing cannot support, timelines too aggressive for the committed deliverables, assumptions in one section that contradict another. Conflicts trigger targeted re-runs before the document is assembled.

5

Assemble

Claude Sonnet weaves all specialist outputs into a cohesive document with a unified voice and an executive summary that accurately reflects the full proposal. The assembler's job is coherence — it does not add content, it integrates what was written.

6

Judge

Claude Opus scores the assembled document on a 0–10 scale. Documents that score below 7.0 trigger an automatic revision cycle — the assembler runs again with the judge's critique as additional context. Maximum two cycles. The score is revealed to the consultant at the moment the judge completes.

7

Deliver

The validated document is saved to the library and made available as PDF and DOCX. Every section is editable. The consultant reviews, refines, and sends — or sends as-is. The choice is theirs. The starting point is no longer a blank document.

Thursday Morning at the Agency

Before The Blank Document
MO
Maya Osei #proposals-review 9:04 AM

Tom, Hartwell want a proposal for the Q3 engagement by EOD. Usual scope, new pricing.

TR
Tom Reeves #proposals-review 9:11 AM

On it. Should have a draft by 4.

5 hours pass.
TR
Tom Reeves #proposals-review 2:47 PM

Still working on it — anyone have the Hartwell context doc from Q2? Can't find it.

TR
Tom Reeves #proposals-review 4:52 PM

Draft in the folder. Can someone review before I send? Pricing section might need a check.

TR
Tom Reeves #proposals-review 6:18 PM

Sent. Sorry for the delay.

After The Generation System
MO
Maya Osei #proposals-review 9:04 AM

Tom, Hartwell want a proposal for the Q3 engagement by EOD. Usual scope, new pricing.

TR
Tom Reeves #proposals-review 9:11 AM

Already done. Filled in the context, system generated a complete draft — exec summary, scope, pricing, risk register. Reviewed it, adjusted the pricing tier. Looks solid.

TR
Tom Reeves #proposals-review 9:14 AM

Sent.

Why the Assembly Stage Is the Hardest Part

The first version ran specialists sequentially and fed each output into the next. It was slow and created compounding drift — later sections inherited the assumptions of earlier ones without being able to challenge them. Moving to parallel execution solved the latency problem but created a new one: five independently written sections with different assumptions, different tones, and different framings of the same engagement. The assembly stage is not a merge operation. It is a synthesis. The assembler must recognise when the scope section and the timeline section are describing different projects and resolve the conflict rather than surface it. That is the hardest prompt to get right — and the one that has been revised more than any other part of the system. The review pass before assembly reduces what the assembler has to reconcile. The judge catches what slips through.

The Pipeline

Wizard context flows into the decomposition stage, fans out to specialist agents running in parallel, converges through a review pass and assembly, and exits through a quality gate. The knowledge base feeds context into specialists when past documents are available. The revision loop is bounded — two cycles maximum before the document is delivered regardless.

Proposal generation pipeline: Wizard feeds into Decompose (Claude Haiku), which fans out to 5 parallel Specialist Agents (Claude Sonnet) — Executive Summary, Problem Statement, Approach & Scope, Pricing & Timeline, Risk & Assumptions. A Knowledge Base feeds context into the specialists via a dashed arrow. Specialists converge to Review (conflict detection), then Assemble (Claude Sonnet), then Judge (Claude Opus, score ≥ 7.0/10). A dashed revision arc loops from Judge back to Assemble for auto-revision (max 2 cycles). Passing documents reach Deliver (PDF · DOCX).

The quality gate is the last stage before delivery. Claude Opus scores the assembled document — if it scores below 7.0, the system revises automatically before the consultant ever sees a draft.

Four Decisions That Shaped the System

Document generation at this level of quality requires explicit architectural choices. Here are the four decisions that shaped how the system behaves — and why each was harder than it appears.

Model cost follows purpose

Three different Claude models at three different stages. Decomposition is structured selection — fast and cheap (Haiku). Writing requires quality prose — mid-tier (Sonnet). Judgment requires the highest reasoning available — Opus, used sparingly, only at the final gate. Running Opus on every stage would be eight times the cost for no improvement in the stages that do not require deep evaluation. The model routing is the cost model.

Parallel execution changes the latency equation

Sequential generation would multiply the latency by the number of specialists. With five agents and an average of 30 seconds per section, sequential execution takes two and a half minutes before assembly even starts. Parallel execution makes the total time equal to the slowest specialist — typically under 40 seconds. The orchestrator waits for all outputs, then assembles from complete sections. The constraint is that no specialist can depend on another specialist's output, which is by design: each section is written from the original context, not from what the previous section assumed.

The quality gate is visible — intentionally

The judge score is revealed to the consultant at the moment the evaluation completes — not as a final summary, but as a real-time signal. The one-second pause before the score appears is deliberate. Documents that pass on the first cycle tend to score 7.8–9.2. Documents that require revision tend to score 5.4–6.8 before the first cycle and 7.5–8.6 after. Consultants who see the score consistently edit less — the gate creates confidence in the output that a version number or timestamp does not.

Gap confirmation prevents hallucination at the source

The most expensive fix in document generation is discovering a hallucinated detail after the document has been sent. The gap confirmation stage — where the system pauses and surfaces missing context before running — is the mechanism that prevents this. If the wizard inputs do not supply a budget range, the decomposition agent flags it. If the consultant confirms a placeholder, the system proceeds with it explicitly labelled. If they supply the value, the specialists run with accurate context. The 30-minute timeout exists because some gaps require a quick phone call. The pause is cheaper than the revision.

What We Learned

Lessons Learned

The assembly stage is harder than the generation stage

Writing a proposal section in isolation is a solved problem. Writing an assembled proposal from five independently generated sections — where each section made different assumptions about the client, the scope, and the commercial structure — is not. The assembly prompt has been revised more than any other part of the system. The review pass before assembly reduces what the assembler has to reconcile, but the assembler still needs to recognise and resolve conflicts that the review pass missed. Getting this right took longer than building the entire parallel execution infrastructure.

The quality gate is most valuable when it catches logical inconsistencies

The early expectation was that the judge would catch grammatical errors and generic language. In practice, grammar is rarely the problem — Sonnet writes clean prose. The judge's most valuable catches are logical: a scope section promising four deliverables when the pricing section is structured for two, a timeline that assumes a three-person team when the approach section describes a solo engagement. These are the errors that a rushed human review misses and that a client notices immediately. The judge earns its cost in the second revision cycle.

What I'd Improve

  • Per-client style calibration — learn from accepted proposals over time, feed successful document patterns back into specialist prompts as few-shot examples
  • Section edit feedback loop — edits the consultant makes to generated sections should improve the underlying specialist, not just update the current document
  • Template branching — different proposal types (fixed-scope, T&M, retainer) should decompose differently by default, not require the consultant to specify in the wizard
  • Confidence indicators per section — show which sections the system is confident about and which are working from thin context, so the consultant knows where to focus their review

DocBase Connects to Everything

DocBase does not generate in a vacuum. When a proposal agent needs past engagement context, it queries AskBase — the same permission-aware knowledge layer that answers questions in Slack. When WatchBase detects a competitor move, FlowBase can trigger a competitive response brief through DocBase's generation pipeline. When a property manager's email triggers a vendor scope of work, FlowBase routes the context to DocBase. The document platform is the output layer for the entire suite.

DocBase composition diagram — DocBase at centre connecting to AskBase (institutional knowledge feeds specialist agents), FlowBase (email triggers proposal generation), and WatchBase (competitor intelligence feeds competitive proposals)

DocBase is the output layer. The other platforms supply the context and the trigger.

How many hours did your team spend on proposals last month?

Book Your Free Assessment