Introducing BidAuthor: AI That Writes Proposals the Way Teams Actually Work

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.

What 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:

1. Extracts every requirement. Not a summary. A structured tree of every question and instruction in the document, with the section hierarchy preserved and the dependencies between questions mapped.
2. Answers each requirement from your knowledge base. Every generated answer is grounded in documents you uploaded — your SOPs, past proposals, product docs, team bios — and carries inline citations pointing to the exact source passage.
3. Assembles and exports the response. A working document you refine question by question, then export as polished PDF or DOCX.

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.

Decision 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.

Decision 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.

Per-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.

What 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.

Built 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.

Where 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.