How the AI agents work

You might wonder why the system uses multiple AI agents instead of just feeding everything into one big model. Short answer: it produces better results for less money. Here's the longer version.

The problem with a single model

If you gave one AI model a 500-page RFP and a 300-page proposal and said "compare these", two things would happen:

1. It would cost a fortune (AI pricing is based on how much text you send)
2. Important details would get lost (models lose accuracy on very long inputs)

The platform avoids both problems by giving each agent a focused job, isolating it in its own workspace, and only loading what it actually needs.

Sandboxes — every agent gets its own workspace

When an analysis or composition starts, the system spins up an isolated workspace called a sandbox — essentially a fresh, throwaway computer that exists only for that one run. The relevant documents are uploaded into the sandbox, and the AI agent can:

• Open and read files
• Search for keywords with ripgrep
• Run small shell commands to count lines, extract sections, or check structure
• Edit and write files (for composition workflows)

The agent reads documents the same way you would — opening files, searching, jumping between sections. There's no precomputed index. When the run ends, the sandbox is destroyed.

This isolation matters for two reasons:

• Privacy. Your RFP and proposal documents never leave that sandbox. Different runs (and different organizations) get different sandboxes.
• Reproducibility. If a run pauses to ask you a clarifying question, the sandbox is preserved exactly as the agent left it. When you answer, the agent picks up right where it stopped.

The team

Each feature on the platform — bid analysis, RFP composition, RFP quality review, prep checklist, market research, and so on — is driven by its own orchestrator agent. The orchestrator is the brain of the run: it reads documents, plans what to check, calls tools, evaluates evidence, and decides when the work is done.

Most orchestrators run on Claude Opus, the most capable tier. A few specialized ones run on Sonnet (mid-tier) when the task is structured enough not to need maximum reasoning power.

Beyond the orchestrator, two kinds of helpers exist:

Sub-agents

A sub-agent is a one-shot, single-purpose helper running on a faster, cheaper model (Claude Haiku). The orchestrator calls one when it needs a focused side-task done quickly:

• Semantic searcher — the orchestrator falls back to this when keyword search can't find what it's looking for. The semantic searcher reads the relevant files and ranks passages by meaning. (See Document parsing for when this happens.)
• Web page reader — for market and funding research, a sub-agent pulls structured data out of fetched web pages.

You won't see sub-agents directly. They appear in the activity feed only when invoked.

Specialists

For bid analysis specifically, two short specialist runs go before the main orchestrator: one extracts the procurement's evaluation criteria, and another extracts its lots (sub-positions). Both are short, focused passes that prepare the ground so the main analysis can hit the ground running.

Verification (bid analysis only)

After the main analysis finishes, a separate verification phase reviews each Critical and Major finding. A different model (Sonnet) re-reads the cited evidence and decides whether to confirm, downgrade, or remove the finding. The verifier brings fresh eyes — the same way a colleague reviewing your work might catch errors you missed.

Other workflows (RFP review, RFP integrity, prep checklist, composition, research) don't have a separate verification phase — their orchestrators are designed to be self-checking, and the bid analysis use case is the only one where the stakes justified a second pass.

How a typical bid analysis flows

1. Specialists run first. Criteria and lots get extracted from the RFP in two parallel passes.
2. The orchestrator boots up. It receives the RFP, the proposal, the extracted criteria, and the extracted lots.
3. It reads what it needs. For each requirement on its mental list, the orchestrator opens the relevant file, searches for keywords, or — if needed — falls back to semantic search. It records evidence quotes as it goes.
4. It records findings. Every issue, strength, or matched criterion is written to the database with a severity level and the supporting quote.
5. It can pause. If something is genuinely unclear, the orchestrator pauses and asks you a question. The sandbox is frozen until you answer.
6. Verification runs. Each Critical and Major finding is re-checked by a second model.
7. The report is ready. You get the executive summary, recommendation, findings list, criterion scores, and lot participation status.

Choosing your AI provider

You can choose which AI provider powers the analysis. Open the user menu in the top-right corner and select between:

• Anthropic (Claude models)
• OpenAI (GPT models)
• Google (Gemini models)

When you select a provider, the system automatically assigns the right model tier for each role:

You don't need to configure individual models — just pick a provider and the system handles the rest. You can switch providers at any time. Already-running analyses continue with their original provider.

Beyond bid analysis

The same architecture — sandboxed orchestrator with the same set of file-system tools — powers every other AI feature on the platform:

• RFP quality review — flags clarity, completeness, and consistency issues in your draft RFP.
• RFP integrity check — scans the RFP for fairness and integrity risks (vendor-specific language, overly narrow specs).
• Preparation checklist — generates a structured checklist of what to prepare before submitting a bid.
• Composing an RFP — drafts the RFP document set on the buyer side.
• Composing a bid — drafts vendor bid sections from a planned outline, then runs a validation pass.
• Evaluation protocol — generates the post-evaluation procurement protocol document.
• Market research and Funding research — orchestrators that use web search instead of sandbox file tools.

All of these features share the same real-time activity feed — a panel that shows you what the agent is doing as it works. You can watch it read files, run searches, evaluate criteria, and record findings in real time.

Why this matters for you

You don't need to know any of this to use the platform. But it helps explain:

• Why analysis takes time — multiple agents are doing multiple passes through your documents.
• Why evidence is specific — agents quote exact passages, not summaries.
• Why verification can change findings — it's a separate check, not just rubber-stamping.
• Why costs vary — more documents and more criteria mean more agent work.
• Why your data is safe — each run lives in its own sandbox that gets destroyed when it ends.
• Why you can choose providers — different providers may perform better on different document types.