Using AI to write RFP proposals: inside Mojar's drafting engine

On most RFP responses, the writing happens last. The days disappear into everything that comes first: someone hunts through old proposals, finds the current compliance language, confirms which case study is approved, and checks whether the pricing in last quarter's deck still holds. Industry research puts RFP and proposal work at 20 to 30 percent of seller time, and the bulk of that is assembly and search, not original thinking (Salesforce State of Sales, Loopio). We broke the dollar cost of that down in our analysis of RFP time, and the figure lands between $320K and $500K a year in direct labor for a 20-rep team.

I'm Adi Ghiuro, co-founder at Mojar, and over the past months our team built an RFP drafting engine that attacks the whole workflow, not just the search step. This post is a practitioner's walkthrough of how it works inside the platform: how it reads your knowledge base before it writes anything, how it scores evidence, how it drafts a real proposal section by section, and the part I care about most, how it flags the gaps between what an RFP asks for and what your company can actually prove.

The real bottleneck in RFP responses

When we deployed retrieval with sales teams, the pattern repeated everywhere, and we've seen it hold across every organization we work with. The work that swallowed reps' time was coordination, not writing: locating the right SOC 2 statement, confirming the latest insurance limits, tracking down who signs the cover letter, reconciling pricing across three documents that disagreed. The Association of Proposal Management Professionals (APMP) has long documented that proposal teams lose disproportionate time to content management rather than strategy.

A retrieval system fixes the search. That was the focus of our earlier piece on RFP response automation, where the core point was that AI eliminates the hunt while the human still writes. The drafting engine is the next step in that evolution. It still retrieves and cites, but now it also assembles the first draft, so the human moves from author to editor.

What the Mojar RFP drafting engine actually does

At a high level, the engine runs a two-phase workflow over your indexed content. It plans first, then it writes. Both phases are evidence-first: the system will not produce a plan or a section until it has actually searched your knowledge base for supporting material.

Every box is a versioned artifact, and every arrow is a skill the agent loads on demand. An RFP agent ships with the default skill set below, taken straight from the configuration screen.

General skills
  general.ask-user          ask a focused question when input would improve the work
  general.search-knowledge  find and inspect evidence from indexed documents
  general.navigate-knowledge browse the knowledge base as a folder tree
  general.memory-recall     recall facts and decisions from past sessions
  general.memory-store      save a long-lived preference or decision
  general.artifact-create   produce a deliverable the user can keep and version
  general.artifact-update   add a new version to an existing artifact
  general.read-artifact     fetch the current content of an artifact

RFP skills
  rfp.build-response-plan   turn an RFP into structured requirements and a cited plan
  rfp.execute-response-plan draft the proposal one section at a time via sub-agents
  rfp.scratchpad            capture corrections, decisions, and gaps for this draft

Step 1: turning an RFP into structured requirements

You start by attaching the RFP, a tender PDF, a scope-of-work document, or a question list. The agent recognizes the document type and loads the build-response-plan skill. Before it writes a single requirement, it does the research.

How the engine reads your knowledge base before it writes

The screenshot below is the engine's own thought process while building a plan for a real investment-consulting RFP. You can see it load three skills, recall prior context with memory-recall, run a batch-similarity-search across the knowledge base, and jot working notes with scratchpad-note before it commits to anything.

That batch search is the part most tools skip. Rather than one vague query, the engine fans out multiple targeted queries, one per capability area the RFP touches, and ranks the hits against your actual files. In the expanded view you can see queries like "firm overview history ownership fiduciary SEC registered investment adviser" and "asset allocation capital market expectations portfolio optimization" returning ranked matches against documents such as 07-compliance-ethics.md and 05-research-capabilities.md, each with a similarity score.

This is how the engine grounds itself in your content rather than its training data. Every requirement it writes traces back to a passage it actually retrieved.

Evidence status: found, partial, gap

The output of this phase is a Requirements artifact. Each requirement carries an evidence status, and this is where the engine starts earning trust:

• Found: the knowledge base contains strong, directly relevant evidence.
• Partial: there is related material, but it is incomplete or needs confirmation.
• Gap: the RFP asks for something your indexed content does not cover.

That three-way split is deliberate. A tool that only says "done" hides risk. Marking a requirement as a gap up front, before drafting, tells the proposal lead exactly where a human needs to supply a number, a certification date, or an authorization letter.

Step 2: the cited response plan

Once requirements are scored, the engine builds a Response Plan: the section-by-section blueprint a writer would normally assemble by hand. Each planned section references the evidence it will draw on, so the plan maps to your content instead of to a generic template.

In the demo we recorded, that plan came back with 13 sections to draft for a single RFP, from the cover letter through required statements and appendices. The plan is its own artifact, which means you can read it, edit it, and approve it before any drafting starts. We recommend treating the plan as a checkpoint: it is far cheaper to fix structure here than after 13 sections exist.

Gap flagging: the feature that protects your win rate

This is the part that matters most. The most damaging RFP error is a confident, fabricated answer: the kind a procurement team catches in review, or worse, the kind you discover only after you win and cannot deliver. Generic AI produces these constantly because it is built to always answer. Mojar's engine is built to do the opposite and refuse to fake it.

How a gap surfaces in the draft

While a section is being written, the writer does not paper over missing evidence. It leaves an explicit inline marker at the exact spot the data is missing, in a format the system can detect:

(b) Illinois State Board of Elections Business Entity Registration

Pinnacle Advisory Group, LLC certifies that:
[Pinnacle is / is not] registered as a business entity with the Illinois State
Board of Elections pursuant to the Procurement Code.
[GAP - needs SBE registration status and certificate number]

You can see this in the live product. In the section-review screenshot earlier, the drafted cover letter contains bracketed placeholders and a flagged note where the firm's exact registration details belong. The engine drafted everything it could prove and stopped precisely where your input is required.

When the engine asks instead of guesses

The orchestrator collects every [GAP] marker from a finished section. If the list is not empty, instead of moving on it pauses and asks you a focused question through the ask-user skill. In the demo, the very first thing it asked was who should be named as the authorized signatory on the cover letter, because no document in the knowledge base named that person.

This is the behavior that makes the output submission-ready rather than a draft you have to fully fact-check. The scratchpad skill backs it up by recording gaps, corrections, and decisions for the whole drafting cycle, so a fix you make in section 2 is remembered when section 9 references the same fact. In practice, this turns review into a short list of named decisions rather than a line-by-line audit.

Step 3: drafting sections with sub-agents

Long documents are where most AI drafting falls apart. Quality drifts, tone wanders, and section 12 forgets what section 1 promised. Our approach is to draft each section in its own isolated sub-agent.

When you trigger execute-response-plan, the engine works through the plan one section at a time. For each section it uses a delegate_to_agent tool to spin up a dedicated section-writer sub-agent. That sub-agent searches the knowledge base in depth for its specific section, drafts the prose with citations, leaves any gap markers, and emits the section as its own artifact. Then control returns to the orchestrator, which checkpoints the result and moves to the next section.

Because every section is a versioned artifact, you can switch between Requirements, Response Plan, and any drafted section from one panel, compare versions, revise a single section without regenerating the rest, and export the result. When you ask for a change, the engine creates a new version (v2) rather than overwriting, and it preserves the citations as it edits. You can copy a section or download it as a Word document when you are ready to assemble the final response.

Configuring the agent: skills, prompt mode, and tone of voice

The engine is configurable rather than a black box. On the configuration screen you control three things.

First, skills. You enable or disable each capability, and the agent only sees what is enabled. The general skills handle asking, searching, remembering, and artifact management; the RFP skills handle planning, execution, and the scratchpad.

Second, system prompt mode. You can run Mojar's managed industry default, which is maintained for compliance, or switch to a fully custom prompt where you take responsibility for the agent's behavior end to end.

Third, tone of voice. You describe how the agent should write, or generate a tone profile from your own knowledge base. That profile applies to chat replies and to every drafted section, so the proposal reads like your firm wrote it. For example, a tone instruction might be "write in a formal, plain-spoken voice, prefer short sentences and active voice." We built this because a proposal in the wrong voice gets rewritten anyway, which defeats the speed gain.

How this compares to manual work and generic AI

The table below is the comparison we use internally when teams ask why this beats both the status quo and a chatbot.

Unlike a generic model that answers everything to look complete, the engine treats a missing answer as information you need. The honest summary: a manual process is accurate but slow, a generic model is fast but unsafe, and the drafting engine is built to be fast and traceable at the same time. However fast it gets, the human still owns the final review.

What the engine does not do

I would rather you trust the boundaries than oversell. The engine drafts from what you have indexed, so the quality of the output tracks the quality of your knowledge base. If your past proposals are thin, the gaps list will be long, which is useful information but not magic. The engine also does not make the final call on strategy, pricing, or which references to feature. It surfaces options and evidence; a human still owns the win themes and the submit button. And it is a drafting partner, not an approval workflow. Legal and compliance review still happen the way they always have, just on a draft that is already cited and gap-checked.

If you want the deeper background on how retrieval and citations work underneath all of this, our complete guide to RAG for revenue teams covers the architecture in detail.

See it in action

The fastest way to understand the engine is to watch it run. In the video, we attach a real RFP, the engine reads the knowledge base, builds a cited plan, flags the gaps, asks who signs the cover letter, and drafts the proposal section by section. By Mojar's own benchmark in that demo, the move from blank page to an advanced first draft happens in minutes rather than the days a manual response usually takes.

If you respond to RFPs and want to see this against your own content, book a demo and we will run your real documents through the engine, or explore the full RFP automation solution first. Curious what the time savings are worth for your team? The RFP ROI calculator will do the math, and you can schedule a demo whenever you are ready to try it on a live bid.