neesh Inc.
Scenarios

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 5 specialist agents in parallel, scores the output at a quality gate, and delivers a complete, client-specific document ready for review, in the time it takes to finish a coffee.

COMPOSITE_DEPLOYMENTS Composite scenarios: fictional companies, built on our platform, with outcomes stated as design targets.

BUILT_ON DocBase · in build

Python FastAPI PostgreSQL + pgvector Claude Haiku Claude Sonnet Claude Opus Next.js AWS ECS Fargate
~3 min from context to complete draft design target, against 8–12 hours by hand
5 specialist agents running in parallel sections written simultaneously, not sequentially
≥ 7.0 quality gate score to pass every document scored 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, checks 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 section the document needs that no specialist covers, proposing a new specialist for it. Fast, cheap, structured output. The routing decision costs less than half a cent.

2

Confirm

If the decomposition proposes a new specialist, the system pauses for the consultant to approve or skip it before any section is written, with a 30-minute timeout. A run nobody is watching does not pause. The pause is intentional: adding a specialist before drafting is cheaper than a revision.

3

Specialists

Each selected specialist agent runs simultaneously. Problem framing, approach and methodology, scope and deliverables, timeline, pricing: 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 writes the executive summary from the full proposal. The assembler's job is coherence: it adds no new claims, it integrates what was written.

6

Judge

Claude Opus scores the assembled document out of 10, and its instructions set the pass mark at 7.0. When it does not pass the draft, the specialists whose sections it flagged write them again with its critique, and the assembler joins the new draft. Maximum two revision cycles; after the second, the document is delivered as it stands and marked as not passed. The score is revealed to the consultant at the moment the judge completes.

7

Deliver

The scored 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, timeline, pricing. 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

A planner assigns each section to a specialist, the specialists write in parallel, and an assembler joins their sections into one draft. The judge scores that draft out of 10 against the 7.0 pass mark its instructions set. When it does not pass the draft, the sections it flagged go back to their specialists with its critique, at most twice, and then the document is delivered as it stands.

A judge scores every draft and sends weak sections back, twice at most A planner assigns sections to specialists that write in parallel, and an assembler joins them into one draft. Claude Opus scores the draft out of 10 against the 7.0 pass mark its instructions set; a draft it does not pass goes back to the specialists whose sections were weak, at most twice, and then the document is delivered as PDF and DOCX. Planner Claude Haiku Specialists Claude Sonnet,in parallel Assembler Claude Sonnet Judge Claude Opus,pass mark 7.0 Document PDF and DOCX assignssectionshand insectionssubmits thedraftdeliversreturns weak sections
A judge scores every draft and sends weak sections back, twice at most A planner assigns sections to specialists that write in parallel, and an assembler joins them into one draft. Claude Opus scores the draft out of 10 against the 7.0 pass mark its instructions set; a draft it does not pass goes back to the specialists whose sections were weak, at most twice, and then the document is delivered as PDF and DOCX. Planner Claude Haiku Specialists Claude Sonnet, in parallel Assembler Claude Sonnet Judge Claude Opus, pass mark 7.0 Document PDF and DOCX assigns sectionshand in sectionssubmits the draftdeliversreturns weak sections

The quality gate is the last stage before delivery. A draft the judge does not pass is revised automatically, at most twice, before it reaches the consultant.

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, a design target of 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 design targets: a document that passes on the first cycle scores 7.8–9.2, and one that needs revision climbs from 5.4–6.8 to 7.5–8.6 after its first cycle. A consultant who can see the score has a reason to edit less: the gate creates confidence in the output that a version number or timestamp does not.

A missing specialist is confirmed before drafting

Before any specialist writes, the planner checks whether the document needs a section no specialist in the registry covers. If it does, the system proposes a new specialist, with what it would write and why, and pauses for the consultant to approve or skip it. The 30-minute timeout exists because the consultant may be in a meeting; a scheduled run skips the pause. Adding a specialist before drafting is cheaper than rewriting a weak section after the judge. It is a check on the team of writers, not on the facts: a budget the consultant never gave is still the pricing specialist’s to assume, which is why the consultant reads the draft before it goes out.

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 Is the Output Layer

DocBase is the output layer of the four engines: it writes the documents a firm sends out. Every finished document is indexed into the firm's own knowledge base, and the specialists read past documents before they write, so each new proposal starts from the firm's own past work rather than a blank page.

Every document you finish becomes context for the next one Specialists write each document from your wizard answers and from the past documents in your knowledge base. Every finished document is indexed back into that knowledge base, and downloads as PDF or DOCX. Wizard your context Knowledgebase past documents Specialists Document Files PDF and DOCX givescontextexportssupplieswriteis indexed into
Every document you finish becomes context for the next one Specialists write each document from your wizard answers and from the past documents in your knowledge base. Every finished document is indexed back into that knowledge base, and downloads as PDF or DOCX. Wizard your context Knowledgebase past documents Specialists Document Files PDF and DOCX gives contextexportssupplieswriteis indexed into

DocBase is the output layer, and its own knowledge base grows with every document it finishes.

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

Book Your Free Assessment