Introducing BidAuthor: AI That Writes Proposals the Way Teams Actually Work
BidAuthor extracts every requirement from an RFP, answers each one from your own knowledge base with citations, and prices the work per question — not per seat. Here's the vision and how the engine works.
Every proposal team knows the ritual. An RFP lands on a Friday. Someone converts it to a spreadsheet by hand, row by row, hunting for every "describe," "provide," and "confirm" buried in 80 pages of solicitation prose. The spreadsheet gets carved up across the team. Everyone pastes half-remembered answers from the last proposal, the compliance lead cross-checks the matrix at midnight, and the final document ships minutes before the deadline — with at least one requirement nobody noticed until it was too late.
We built BidAuthor because that ritual is not a writing problem. It is a structure problem, and structure is exactly what software is good at.
01What BidAuthor does
BidAuthor is an AI proposal platform that takes an inbound solicitation — an RFP, RFI, RFQ, DDQ, or any of the other formats procurement teams use — and does three things:
The whole flow is covered step by step on the how it works page. What I want to do here is explain the two design decisions underneath it, because they are what make BidAuthor different from a template library with a chat box bolted on.
02Decision one: requirements are a graph, not a list
Real solicitations are not flat questionnaires. Question 3.2 asks you to describe your staffing plan. Question 3.4 asks how that staffing plan handles surge capacity. Question 5.1 asks you to price what you described in section 3. Answer them in isolation and you get a proposal that contradicts itself — the thing evaluators are trained to catch.
BidAuthor's extraction step builds a dependency graph: which requirements stand alone, which ones build on earlier answers, which ones are conditional on an answer going a particular way. When the answering engine runs, it walks that graph in order. A question that depends on your staffing-plan answer is generated after the staffing plan exists, with the upstream answer in context. If an upstream answer comes out partial — say, your knowledge base only half-covers it — a gate decides whether the downstream questions can proceed honestly or should be flagged for a human instead of hallucinated around.
The engine treats "answer one question," "answer these five," and "answer all 400" as the same operation — a plan over the graph, followed by an execution pass. Cardinality is just a parameter.
That uniformity matters more than it sounds. It means you can accept the machine's first pass on the easy 70 percent, hand-write the strategic 10 percent, and re-run the remaining 20 percent with different steering — without the tool caring which mode it is in.
03Decision two: answers must show their sources
Generic AI writing tools produce confident prose with no provenance. For proposal work that is worse than useless — a wrong claim about your own certifications or staffing is a bid-killer, and an evaluator who catches one unsupported claim discounts the whole document.
Every answer BidAuthor generates carries inline citations that resolve to a specific document, page, and passage in your knowledge base. Citations are validated at generation time: if the model references a source it was not actually shown, the citation is dropped and logged, not rendered. If retrieval fails for a question, the answer is marked as degraded rather than silently invented. You can open any answer and audit exactly which passages produced it.
This is also why the platform pushes so hard on the knowledge base itself. The quality ceiling of any grounded answer is the quality of the corpus behind it — we wrote a practical guide to building a proposal knowledge base that covers what to upload and how to structure guidelines.
04Per-question pricing, because that is the honest unit
Most tools in this category are priced per seat, per year, with a sales call in between you and the number. We think the honest unit of work in proposal automation is the answered question, so that is what BidAuthor meters. Before any generation run, you see the count: how many questions you selected, how many dependencies the graph pulls in, and what the pass will cost in credits. Small RFI? Small cost. 400-question DDQ? You'll know before you click.
There is a free tier that lets you run one real solicitation end to end — extraction, generation, export — before paying anything. Plans and credit math are public on the pricing page. No demo gauntlet required, although we're happy to give one.
05What Arthur is
Threaded through the platform is Arthur, the built-in agent. Arthur can navigate the workspace, upload and classify documents, kick off answering runs, re-route questions, and explain what the pipeline did and why. Arthur sees what you see — the same workspace state, the same question statuses — so instructions like "re-run the three failed questions with a more formal tone" resolve against reality instead of a chat transcript's guess at it.
Under the hood Arthur uses the same public machinery we expose to customers: the extraction pipeline, the answering engine, the export service. Which leads to the last thing worth saying.
06Built API-first, on purpose
Everything the dashboard does runs through a public, documented API. Extraction, proposal creation, answering runs, exports — all of it is callable with an API key, and the OpenAPI spec is published. If your team wants to wire proposal generation into an internal workflow — or point your own AI agents at it — the surface is there. We think the next few years of procurement work will be done increasingly by software agents on both sides of the table, and we are building for that world from day one.
07Where this goes
We are at the beginning. The engine handles the formats proposal teams face today — RFPs, RFIs, RFQs, DDQs, security questionnaires — and the roadmap runs toward richer final outputs, deeper integrations with the document stores teams already use, and better analytics on what actually wins.
If you spend your weeks inside solicitation documents, try it on a real one. Upload the RFP you're staring at right now, watch the requirement tree come out, and judge the answers against what your team would have written by hand. That comparison is the entire pitch.
If you are evaluating the category, we also keep an honest comparison against Loopio and the other established platforms — including the places they are stronger. Proposal teams are professionally allergic to unsupported claims. So are we.
Upload a real solicitation and judge the answers yourself.
Watch every requirement get extracted, then read each generated answer against your own knowledge base, with its sources beside it. Free to start.
What Does a Bid Author Do? (And What Changes When AI Writes the First Draft)
The bid author is the person who turns a solicitation's requirements into compliant, persuasive answers. Here's what the role actually involves day to day, the skills that separate good from great — and which parts AI is absorbing.
How AI Is Actually Changing RFP Response (and What Should Stay Human)
A clear-eyed walkthrough of the modern AI proposal pipeline — extraction, retrieval, grounded generation — what each stage really does, where the failure modes hide, and which parts of proposal work should never be automated.
How to Build a Proposal Knowledge Base That Actually Wins Bids
A practical, structure-first guide to the corpus behind AI-generated proposals — what to upload, what to keep out, how guidelines differ from knowledge, and the maintenance ritual that keeps answers current.