How we draft RFP responses

An RFP or proposal questionnaire lands as a long document attached to an email — pricing, implementation timeline, support model, integrations, company background, references — and a submission deadline that doesn't move. Most of it we've answered before, in a past proposal or a product doc, but it's scattered across old submissions and no one remembers exactly where. A rep spends a day combing through past deals and pinging product and support for lines that already exist, before writing a single new sentence.

We run an RFP-responder agent on Kortix that drafts the response from our vetted answer library the moment the RFP arrives. This is how we answer our own RFPs and proposal questionnaires, including the connections and guardrails involved.

The problem

Most of an RFP is questions we've answered dozens of times — pricing tiers, implementation timeline, integrations, support SLAs, company background, references — but each one arrives in its own document, a Word file, a PDF, a vendor's own spreadsheet, with its own structure and its own deadline. Someone has to read the whole thing, recall or dig up the answer we gave last time, and write it back into that document's layout, all before the submission window closes.

The shortcuts don't hold up. Copying the last similar proposal wholesale risks carrying over stale pricing or a client-specific detail that doesn't apply here. Searching a shared drive of past submissions by hand is slow and depends on remembering which deal had the closest answer. A generic AI drafter with no grounding writes something that reads well and is often wrong — on a document that can become a contract exhibit, a confident wrong answer is worse than a blank one.

What we built

On Kortix, a cron checks the inbox every 15 minutes for a new RFP or proposal questionnaire. Each check spawns a fresh session (a cloud sandbox) with access to our vetted past-answers library, our product docs, and the incoming RFP document. It parses the RFP into individual questions, matches each against the library and the docs, drafts the full response in a new Google Doc, and flags any question it can't answer confidently for a person. It never submits anything — the draft is the only output, and a human reviews and submits it through whatever channel the RFP requires.

How it works

Guardrails

The agent drafts a document that can end up in front of a customer, so its access is scoped and the output is contained:

• Isolation. Every check runs in its own microVM sandbox. The session reads only the RFP source and the answer library it's scoped to, and only the draft Google Doc is the output.
• Scoped secrets. The Gmail, Drive, and Docs credentials are encrypted in the Secrets Manager and injected into the sandbox at runtime, never exposed to the model or the logs.
• Draft only, never submitted. The agent has no path to submit an RFP portal, send an email, or upload a file to the buyer. A human reviews the draft and submits it themselves.
• Everything is code. The agent's answer library, skills, and per-system permissions are files in the repo, versioned and changed through a reviewed change request rather than a dashboard setting.

The outcome

RFPs that used to cost a rep a day of digging through old proposals now come back as a completed draft within 15 minutes, with the vetted answer already in place and the uncertain questions called out by name. The team spends its time on the questions that actually need judgment, and nothing goes to a buyer without a person reviewing and submitting it.