How we write first drafts of RFP responses
A request for proposal usually shows up as a hefty attachment on an email. Inside: questions on pricing, rollout timeline, support model, integrations, company history and references, plus a due date that will not budge. We have answered nearly all of it before. The trouble is that those answers are buried in old proposals and product docs, and nobody can say which file holds the good one. So a rep loses a whole day rummaging through past deals and nudging product and support for words that already exist, all before the first new line gets written.
We hand that first draft to an RFP agent on Machine. As soon as an RFP lands, it writes the response from our library of approved answers. Below is how we handle our own RFPs and proposal questionnaires, including what it connects to and the limits we put on it.
The problem
The bulk of any RFP repeats questions we have handled many times over: pricing tiers, rollout timeline, integrations, support SLAs, who we are, references. Yet every buyer packages them differently. One sends a Word file, another a PDF, a third their own spreadsheet, each with its own layout and its own deadline. Somebody has to read all of it, track down what we said last time, and fit it into this particular document's shape before the clock runs out.
The quick fixes fall apart. Reusing the last similar proposal in one go can drag along an old price or a detail that belonged to some other client. Hunting through a shared drive of past bids is slow, and it only works if you remember which deal had the nearest match. An AI writer with nothing to anchor it produces smooth prose that is frequently wrong. Since an RFP response can end up attached to a contract, a confident mistake does more harm than leaving the box empty.
What we built
On Machine, a scheduled job looks in the inbox every 15 minutes for a new RFP or proposal questionnaire. Each look opens a fresh session, a clean cloud computer (a sandbox) for that run alone, with access to our vetted library of past answers, our product docs and the incoming RFP. The agent splits the RFP into separate questions, matches each one to the library and the docs, writes the complete response in a new Google Doc, and marks for a person any question it cannot answer with confidence. Nothing is ever submitted by the agent. The draft is all it produces, and a human checks it and sends it in through whatever route the buyer asks for.
How it works
Look in the inbox every 15 minutes
A cron trigger scans Gmail every 15 minutes for a fresh RFP or proposal questionnaire. Each scan opens a new session in its own sandbox. The agent starts clean every time and carries nothing from the last check, so it simply works on whatever is in the inbox at that moment.
Anchor it in answers we trust
Our library of past answers sits in the agent's skills and memory, the playbook it brings to every run. For each question that keeps coming back (pricing tiers, rollout timeline, integrations, support model, security basics, company history, references) it holds the approved wording, checked against the current product docs so an outdated answer never sneaks back in. The agent writes only from this checked set. When a won deal teaches us a better answer, we record it, and the next RFP benefits.
Link up where RFPs arrive and where drafts get written
With connectors, narrow links to your tools whose keys stay on our servers so the model never touches a raw token, the agent can:
- Pick up the RFP in Gmail. It reads the email that brings the RFP or questionnaire, along with its deadline.
- Open the file in Google Drive. Attached or linked, Word doc, PDF or spreadsheet, it handles whatever format the buyer chose.
- Write the draft in Google Docs. It creates a new document holding the full response, following the RFP's own sections and question order.
- Mark the shaky answers. Any question with no confident match in the library is highlighted for a person to answer.
Set the limits
This agent only drafts. It produces the response document and points out where it is unsure. It never submits or returns anything to the buyer: no portal uploads, no emails, no attachments sent in our name. Where the vetted library has no confident answer, the agent leaves a gap for a person instead of guessing. The finished draft waits at a human approval gate, where someone checks it and sends it in. Credentials are stored encrypted in the Secrets Manager and only handed to the agents you grant them to.
Get back a full draft, ready to review
The result: within 15 minutes of an RFP arriving, there is a complete Google Doc waiting, filled from our approved library and product docs, with every uncertain question named. The rep reads it through, answers the marked questions and submits through whatever channel the buyer requires. Research and first draft are handled. Checking and sending remain a person's job.
The pattern
A cron every 15 minutes scans Gmail and opens a clean session with narrow connectors to Drive and Docs. Our library of past answers lives in its skills and memory. The agent answers everything it can, marks the rest, and a person checks and submits.
Guardrails
What this agent writes may land in front of a customer, so we keep its reach narrow and its output fenced in:
- Isolation. Every scan runs in a sandbox of its own. The session can read only the RFP source and the answer library it was given, and its single output is the draft Google Doc.
- Scoped secrets. Keys for Gmail, Drive and Docs are stored encrypted in the Secrets Manager and only handed to the agents you grant them to.
- Draft only, never submitted. There is simply no way for the agent to file through an RFP portal, send an email or upload a file to the buyer. A person reviews the draft and submits it personally.
- Everything is code. The answer library, the skills and the permissions for each system are files in the repo. They keep their history, and any change goes through a reviewed change request instead of a switch on a dashboard.
The outcome
An RFP that once ate a rep's whole day of digging through old bids now turns into a finished draft within 15 minutes. The approved answers are already filled in, and the questions it was unsure about are flagged by name. The team puts its energy into the parts that truly need judgment, and no buyer sees a word until a person has read it and sent it.
More use cases
How we answer GDPR data-subject requests before the deadline
Our Machine agent checks each GDPR access or deletion request, finds the person's data across our product database, builds the report well within the SLA and hands it to legal before anything is sent.
How we keep our docs matching what the code does
Once a day a Machine agent reads every commit merged since its last pass, finds the doc pages those changes made wrong, rewrites them and sends you one pull request to review.
How we test every pull request without lifting a finger
Our Machine QA agent works with GitHub and our test environment. For each pull request it checks out the branch, runs the tests, tries the change for real, and posts what it found.
Put your first agentto work today.
- SSO
- RBAC
- Governed agents
- Full audit trail