Proposal Operating System
- Langs
- EN · DE
- Error tol.
- ZERO — client-facing, deadline-bound
- Review
- HUMAN OWNS EVERY WORD
- Status
- IN PRODUCTION
The problem
Competitive tenders in professional services are brutal on process, not just content. Over three to six weeks, a small team has to develop a win strategy, manage a moving set of deadlines and contributors, draft hundreds of pages, review them critically, and pass quality control — all while doing their day jobs.
The obvious AI move is “help me write the proposal.” That’s also the least valuable one. Drafting was never the bottleneck; judgment and coordination were. A generic assistant gives you fluent text with no memory of the win themes you agreed last Tuesday, no opinion on whether your positioning survives contact with the competition, and no idea that section 4 is overdue.
The real problem: could one assistant hold the entire tender — strategy, process, drafting, and critique — without collapsing into an agreeable text generator?
The system
The answer was to stop building a writing assistant and start building an operating system: one system prompt defining six named modes, each with its own job, its own output format, and its own permission to disagree.
Sparring Partner challenges positioning before anything is written — its standing question is “why you, over the firm the client actually wants to hire?” Win Strategist maps the buying committee and the fears the RFP doesn’t state. Project Manager tracks milestones, owners, and risks, and opens every session by reciting them back. Proposal Writer drafts in the house voice — evidence-based, client-centric, no filler. Critical Reviewer scores each section across five dimensions and returns prioritised edits rather than compliments. Quality Controller runs a RAG-status check against the evaluation criteria before anything ships.
Three design rules did most of the work:
Modes are switched explicitly, never inferred. “Enter Critical Reviewer mode” is a command, not a vibe. The moment an assistant guesses which hat it’s wearing, it defaults to the friendliest one — and a reviewer that wants to be liked is useless.
Session-start recitation. Every session opens with the assistant recapping the tender, the deadline, and the top three open risks it is tracking. This is the cheapest possible state-management mechanism, and it catches drift immediately: if the recap is wrong, you fix the record before it contaminates the day’s work.
Disagreement is an instruction, not a personality trait. The prompt explicitly obliges the assistant to flag weak arguments and risks unprompted. Without that written down, critique decays over a multi-week engagement as the conversation history fills with agreement.
The human owns every word that leaves the building. The system’s job is to make sure the words that get there have survived an argument first.
What I learned
The prompt is process documentation. Writing the six modes forced me to articulate how a tender actually runs — decisions, checkpoints, failure points — with a precision no methodology deck had ever demanded. Half the value existed before the assistant answered a single question.
Named modes beat clever prompts. The sophistication isn’t in the wording; it’s in the separation of concerns. A reviewer that also wrote the text will not tear it apart. Splitting roles that a human team would split turned out to be the whole trick.
State is the hard problem, not quality. Modern models write well by default. Getting one to remember, three weeks in, which win theme was killed in week one — that’s where systems live or die. Recitation rituals and explicit decision logs did more for output quality than any instruction about tone.
Constraint is what makes it deployable. The zero-error, deadline-bound environment forced review layers and human ownership into the design from day one. The result is boring in the best way: nothing ships that a person hasn’t defended. That constraint profile — not the drafting speed — is what makes AI survivable in regulated work.