Built for agents
When your buyers, your partners, or your own team start delegating procurement work to software agents, BidAngel works the same way — over the same data of record, through the same audited tool surface, under the same approval gates. Engineered for it from day one.
Most BidAngel customers today don’t operate agents. Most don’t need to. The point of this page is not to convince you that you should — it’s to show, with concrete artefacts, that whenever your industry, your buyers, or your own team do, the surface is already here. Agent-operable, not agent-dependent.
Three architectural commitments
A typed tool surface, governed not omnipotent
Agents act through a registry of bounded, audited tools — not screen-scraping, not an open API hose. 98 tools today, classified into three governance classes: safe reads, low-risk writes, and consequential writes that require human approval. The same registry serves the first-party drafting agent, external agents connected over MCP, and the workflow UI. There is no AI side door.
Claim-level provenance, authority, and freshness
Every assertion an agent makes or consumes — a capability claim, a requirement match, a draft answer — carries source, signing party, version, and freshness state. Capability claims supersede; they do not silently rewrite. Drafts cite content assets by reference, not paraphrase. Agents verify, not just consume.
Standards-aligned, not BidAngel-proprietary
Our interfaces are layered on UBL 2.3, Peppol BIS, EU eForms, and OCDS. We author the A2A Procurement Profile in public: a draft that maps our canonical procurement fragments field by field onto those standards, built to compose with other agent-economy protocols rather than lock suppliers into any one of them. No standards body has adopted it yet. The aim is that when the agent economy settles on a wire format, moving to it is a mapping exercise and not a rebuild.
How we govern what an agent decides on its own
Every tool action is classified on a fixed eight-level commitment ladder. Higher numbers mean higher consequence — reads at 0, contract acceptance at 7. The autonomy stance scales with the level, and customers unlock unsupervised action level-by-level, tool-by-tool, persona-by-persona, with quotas and a kill switch.
| Level | Action class | Default autonomy |
|---|---|---|
| 0 | Read, search, summarise | Always autonomous |
| 1 | Draft an internal recommendation | Always autonomous |
| 2 | Answer from pre-approved factual content | Off by default; opt-in per tool + persona |
| 3 | Submit a clarification question | Off by default; opt-in per tool + persona |
| 4 | Submit non-binding vendor information | Off by default; opt-in per tool + persona |
| 5 | Submit bid content | Human approval required |
| 6 | Price, legal, or delivery commitment | Human approval required |
| 7 | Contract acceptance | Human only |
For levels 2–4 the platform is currently observing-not-enforcing — recording what an agent would have done before letting it act unsupervised. The point of that observation window is to build the attestation history that lets customers unlock unsupervised action with confidence. Levels 5 through 7 are not eligible for unsupervised execution today; raising any of them would require deliberate architecture work and customer opt-in. Level 7 — contract acceptance — is the one most likely to stay human-only: the question there is not just agent reliability but the still-evolving legal infrastructure for autonomous corporate acts.
What’s live today
Not roadmap. Shipped infrastructure you can connect to.
MCP transport, live
External agents connect over Streamable HTTP MCP. Tenant-scoped credentials, role-gated tool visibility, full audit-ledger capture on every call.
98 typed tools across three governance classes
62 read-safe (Class A), 30 low-risk writes (Class B), 6 approval-gated (Class C). The registry is the same one the first-party drafting agent uses — not a parallel "external" shim. Some tools arrive with features a tenant switches on. An agent holding an API key can be granted up to 78 of them, including access to the workspace’s own pursuits (reads of pursuits, tasks and requirements; task changes and notes; requirements and stage moves a person then approves), narrowed by the key’s own allowlist.
Skills: eight governed playbooks, discoverable over MCP
BidAngel-authored skills, published as MCP prompts beside the tools. Each is an ordered playbook with the governance order built in: read before proposing, advisory before approved, stop at the human gate. A skill carries no authority. Every step it suggests is an ordinary tool call under the same scope, policy and approval checks, and an agent sees a skill only when it can call every tool the skill names. Enabled per tenant.
Named personas and an observe-only policy engine
Every agent operates under a named persona with declared scope and quotas. The policy engine evaluates each action against the autonomy ladder above and records what it would have decided — currently in observe-only mode while we build the attestation history that lets customers safely unlock unsupervised action on lower-consequence levels.
Capability claims as first-class assertions
Tenants author versioned, evidence-linked, jurisdiction-aware capability claims. Freshness, supersession history, and an approval workflow are model-native. Agents query and cite these directly.
Supplier directory opt-in surface
A non-cryptographic, tenant-controlled discovery surface for the buyer side. Anti-aggregation discipline keeps it distinct from a platform-generated public reputation score.
Session-route rate limiting
Every authenticated user-session route is rate-limited by class, not just at the OAuth edge. Agent traffic is real traffic and treated as such.
The tool surface, at a glance
98 tools, three governance classes (read-safe, low-risk write, approval-gated). Below is the surface by capability theme — a sampling, not the full registry. Approval-gated tools are bounded by tenant role and captured by the audit ledger like every other action.
| Theme | Sample tools |
|---|---|
| Opportunity discovery & qualification | getOpportunity, listOpportunities, getQualification, getOpportunitySourceMetadata |
| Requirements & compliance matrix | listRequirements, getRequirementCoverage, generateComplianceMatrix, listMatrixRows |
| Pursuit operations | getPursuit, listPursuitTasks, createPursuit, createTask, updateTask |
| Drafting, content memory, evidence | searchContentAssets, createAdvisoryDraft, requestDraftApproval, getCoverageGaps |
| Capability claims & supplier directory | listCapabilityClaims, getCapabilityClaim, listDirectoryEntryAuditEvents |
| Governance & policy | listPolicyRules, listAgentPersonas, getAgentPersona |
| Approval-gated (Class C) | proposeGoNoGo, proposeAssetMerge, proposeRequirementEdit |
Tool-design discipline is enforced in code: list tools return lean summaries bounded by row count, paired detail tools fetch full payloads, every list/detail pair is parity-tested.
Skills: the safe order, published
Tools are primitives. The order you call them in is where governance lives: read the coverage gaps before proposing coverage, keep advisory drafts apart from approved ones, stop for a person before any approval-gated call. Rather than leave every integrator to work that out, BidAngel publishes the order as skills. An agent finds them over MCP, the same way it finds the tools. Skills add convenience, never authority.
| Skill | What it does | Highest step |
|---|---|---|
| triage-opportunity | Assembles the bid/no-bid file for one opportunity: source detail and qualification. Leaves the decision to a person. | Read |
| screen-eligibility | Checks the mandatory requirements against your approved, in-date capability claims and lists the gaps. | Read |
| review-pursuit-readiness | Briefs one pursuit: open tasks, coverage gaps, matrix health, and which sections are approved or only drafted. | Read |
| sweep-compliance-matrix | Reports the compliance-matrix rows that are at risk or changed since review. | Read |
| sweep-pursuit-deadlines | Lists every pursuit due inside a window, each with a risk band from its gaps, blockers and unapproved drafts. | Read |
| audit-answer-library | Finds answers going stale, duplicates and conflicts, and uploads that failed to parse. | Read |
| capture-pursuit-outcomes | Finds closed pursuits with no recorded result, confirms each, and records the outcomes it can evidence. | Low-risk write |
| advance-pursuit-stage | Confirms a pursuit’s stage and proposes a move to a target stage. Nothing moves until a person approves. | Approval-gated |
“Highest step” is the most consequential call a skill reaches. A skill that reaches an approval-gated call stops there: the call queues a proposal, and a person approves it. Skills are switched on per tenant. Agents holding an API key see seven of them. The others read opportunities, which API keys cannot yet do.
In public draft and on the roadmap
Not yet shipped — clearly labeled so you can tell where the platform stands today versus where it’s heading. These are what BidAngel is building toward in public, alongside the standards that are forming the agent economy’s wire formats.
A2A Procurement Profile (public draft)
In May 2026 BidAngel posted an intent to author a procurement profile as an extension to the Linux Foundation’s Agent2Agent (A2A) protocol. The draft is public: six crosswalks against UBL 2.3, Peppol BIS ESPD 1.0, OCDS, and EU eForms, and JSON-LD contexts for four payload fragments. The A2A project has not yet reviewed or adopted it.
Cross-protocol composition layer
A neutral substrate plus a composition layer that lets agent-economy protocols interoperate without locking the supplier or the buyer into any one of them. Proposed in our architecture record; not yet adopted by an external body. The discipline is to be upstream of the dependency, not downstream of it.
Cryptographic trust packets
Tenant-owned signing keys (anchored in your cloud KMS), signed submission-package manifests, and public manifest and claim-graph read surfaces for buyer agents. Sequenced and design-recorded; ships when a buyer-side counterparty integration is ready to consume it — we ship cryptography when a buyer is ready to verify it, not before.
How agent-readiness compares
Most tools in the category have engaged with the agent economy as a marketing question. We engaged with it as an engineering question. The difference shows up at the interface.
| Tool category | Agent-readiness posture | What’s missing |
|---|---|---|
| RFP writers (Loopio, Responsive, Qvidian, AutogenAI, Inventive, Arphie) | No external tool surface; agent-friendliness is marketing language | No MCP transport, no typed registry, no claim-level provenance, no standards-body engagement. |
| Discovery tools (GovWin, GovTribe) | APIs over opportunity search; nothing downstream | No drafting, no claims, no approval gates — no surface for an agent to do procurement work. |
| Generic AI assistants (M365 Copilot, ChatGPT, Claude) | General-purpose tool use; no domain artefacts | No procurement entities to act on, no capability-claim model, no governance, no audit. |
| Custom internal agent stacks | Sometimes have pieces — never all of them, rarely audited, never standards-aligned | Tenant-of-one. No shared protocol, no portability, no upstream voice in the standards forming around this. |
| BidAngel | MCP live, 98 typed tools, eight governed skills, claim-level provenance, public standards-profile draft | — |
You don’t have to be ready for agents to benefit from being on a platform that is
The same workflow discipline that makes BidAngel useful for human teams is what makes it safe for governed software ones. The capability claims you author for your team’s own use are the same artefacts a buyer-side agent will one day query. The audit ledger that gives your compliance officer a defensible trail is the same substrate that lets you delegate to an agent later without losing it.
The day your prime asks for a programmatic capability statement, or your team wants an agent to triage Monday’s RFPs, the surface is already there — on the same system of record you’ve been using all along.