You've already answered their RFP. You just can't find it.

A request for proposal lands at 4pm on a Thursday. Forty questions, a hard deadline, a portal that won’t take attachments after Friday noon. You read question seventeen, “describe your data residency controls”, and feel the specific dread of someone who knows the answer exists. You wrote it. Six months ago, for a different buyer, in a document you’d have to be a detective to find. So you open a blank box and write it again, slightly worse, at 4pm on a Thursday.

That is the whole job, and almost none of it is writing.

You’ve already answered their RFP. You just can’t find it. Strip away the formatting and the portal and the panic, and an RFP response is three mechanical jobs wearing a trench coat: find what you’ve said before, assemble it into their shape, and don’t miss the deadline. This post takes the three apart, and shows why the agent that does them well is not a better writer, but a better librarian.

The naive way: a blank box and your worst memory

Here’s how it actually goes, in almost every company that bids for work.

The RFP arrives. Someone, often the person you least want spending a day on it, opens a document and starts answering from scratch. Not because the answers are new. The buyer is asking the same things every buyer asks: your security posture, your uptime story, your implementation timeline, your references, your pricing logic. You have answered every one of these before, in good prose, after careful thought, probably more than once. The information is not missing. It is scattered, in last quarter’s response, in a sales deck, in a long email a senior engineer wrote at midnight, in a contract clause, in the security questionnaire you filled out for a buyer who went quiet.

So the work isn’t writing. The work is remembering where you put the answer, and most of us are bad at that.

What you get instead is reinvention under time pressure. The person answering doesn’t know that the data-residency paragraph already exists in a polished form, so they write a new one, thinner, hedged, missing the one detail that won the last deal. Multiply that by forty questions and the response that goes out the door is a worse version of things you’ve already said well, stitched together by your most depleted self the night before the portal closes.

The cost isn’t the hours, though the hours are brutal. The cost is that your best answer is sitting in a file nobody opened, and the buyer gets your second-best one. You don’t lose RFPs because you lack the answer. You lose them because the answer lived nowhere you could reach in time.

The reframe: an RFP response is retrieval, not authorship

Let’s state the idea plainly, because everything else follows from it.

You’ve already answered their RFP. You just can’t find it. Which means the bottleneck was never your ability to write a good answer, you’ve proven that, repeatedly. The bottleneck is recall. The thing standing between you and a strong response is not a blank page; it’s a search problem dressed up as a writing problem.

This matters because the two problems have completely different solutions. If the job were authorship, the fix would be a better writer, a smarter model, a sharper prompt, more eloquence. That’s the obvious move, and it’s the wrong one. A more eloquent model writing from scratch still doesn’t know what your senior engineer said about failover in that midnight email. It will write a fluent answer that’s missing the detail that wins. Fluency isn’t the gap. Grounding is.

The right move is to treat the response as assembly. Somewhere in your company is a corpus of everything you’ve ever said about yourself, proposals, questionnaires, contracts, decks, the threads where someone explained the thing properly. The job of answering question seventeen is to retrieve the strongest existing answer, adapt it to this buyer’s wording, and present it for a human to approve. Not generate. Retrieve, then assemble.

The naive system invents. The right system remembers.

How the agent actually drafts it: a brain, not a blank page

So picture the version that works, and notice what it’s grounded in.

The agent doesn’t start at the blank box. It starts at a company brain, the accumulated, searchable memory of every answer your company has ever given. The last RFP you won. The security questionnaire you filled out three times. The contract clauses that define what you actually promise. The deck where someone finally explained the implementation timeline in plain language. None of this is new content. All of it is content you already produced and then lost track of.

When question seventeen arrives, “describe your data residency controls”, the agent does what the tired human can’t do at 4pm: it searches everything you’ve said, finds the three places you’ve answered this before, and drafts from those, not from the model’s imagination. The draft it produces is grounded in your own prior words, with the source attached, so a human can see exactly where each claim came from and trust it, or correct it.

That last part is the difference between a tool and a coworker. An agent that writes a fluent, confident, ungrounded paragraph is a liability, it will state your uptime number with total assurance and get it wrong, and you won’t catch it until the buyer does. An agent grounded in your brain can only say what you’ve already said, and shows its work. When it doesn’t have a real prior answer, it says so and flags the question for a human, instead of inventing one. A grounded draft you can verify beats a fluent draft you have to fact-check, every time.

The honest answer to “describe your data residency controls” is the one you already gave the last buyer who asked, found, not fabricated.

This is the same engine, by the way, that lets a company stop re-explaining itself every time someone leaves or a new buyer asks. The RFP is just the sharpest version of a problem every company has: the answer exists, and the person who needs it can’t reach it. An RFP comes with a deadline attached, which is why it’s the case that hurts.

The third job nobody specs: the deadline chases you back

The two jobs above, find it, assemble it, are about quality. The third is about whether you submit at all.

Every RFP is a race against a clock that doesn’t care about your week. There’s a portal that locks. There’s a clarifying-questions window that closes days before the deadline, so the smart move is to ask early, which means someone has to notice there’s a question worth asking while there’s still time. There are forty answers, each of which might need a different person to confirm a number. And there’s the quiet failure mode that kills more bids than bad writing ever did: the response was 90% done, and then a deal got hot, and Thursday became next Thursday, and the window simply closed. Nobody decided to lose that RFP. It lapsed.

The naive system handles this with a calendar reminder and a prayer. Someone sets a flag for “RFP due Friday” and hopes the right human looks at the right moment. But a date that lives in one person’s head competes with everything else in that head, and loses on the busy days, which are exactly the days an RFP arrives.

The agent’s version is to watch the deadline the way it watches everything: continuously, and to speak first. The clarifying window is closing in two days and three questions still have no grounded answer, surface that on Tuesday, not mourn it on Saturday. The pricing answer needs a human’s sign-off and hasn’t got one, flag it while there’s runway. The portal locks at noon and the draft is complete, say so, with the submit step queued behind one human approval. Not a reminder that fires once and is gone. A standing watch that keeps chasing the open threads until they close.

Because here’s the thing the spec usually misses: an RFP you didn’t submit and one you submitted badly look identical on the scoreboard. Both are a loss. The deadline isn’t an administrative detail bolted onto the writing, it’s a third, co-equal job, and it’s the one most likely to sink a response that was otherwise going to win.

The turn: this was never the work you were hired for

Step back from the mechanism and look at who’s doing this today.

In most companies, the RFP lands on a founder, an operator, a head of sales, someone whose actual job is judgment, and who instead spends a day and a night being a search engine for their own past words. They are good at the part that matters: deciding what to bid on, knowing which buyer is worth the effort, finding the one framing that turns a commodity answer into a reason to choose you. And they spend almost none of their RFP time on that, because all of it gets eaten by the mechanical jobs, the finding, the assembling, the not-missing-the-deadline.

That work feels like diligence. It’s a tax. Every hour spent rewriting an answer you already had well is an hour not spent on the only part of the proposal a machine can’t do: the judgment of whether this is the right deal, in the right words, for this particular buyer. You became your company’s RFP librarian because no system would do it for you. That was never a good use of you.

The promise here isn’t a chatbot that writes faster. It’s that the first draft is already assembled from your own best answers when you sit down, grounded, sourced, with the open questions flagged and the deadline watched, so the most capable person in the company stops being the one who reconstructs the past, and gets to be the one who decides what’s worth winning.

---

That’s what we’re building at Apollo Space, not a smarter blank box, but a company brain that remembers what you’ve already said and an agent that assembles it into the shape the buyer asked for, on time. So can Apollo write your RFP response? Most of it was already written. The hard part was never the words. It was finding them before Friday noon, and then deciding which deal was worth the win.