How buyers find you, before any RFx is written.
The agent economy is arriving on both sides of the trade. Today most procurement begins when a buyer publishes an RFx and suppliers respond. Increasingly, it will begin earlier — with a buyer-side agent forming an intent and querying supplier capabilities directly, before any document exists.
BidAngel is being built to make you queryable on your terms: a tenant-owned, jurisdictionally-scoped capability graph that authorised buyer agents can interrogate under credentials you issue, with disclosure policies you control. An opt-in public directory exists for discovery — every field is supplier-controlled, no platform-issued scoring, no cross-supplier ranking. The supplier is the only party who decides what is exposed.
What is available today, and what is planned
Available today: capability claims with approval, evidence links and freshness tracking, and the opt-in supplier directory.
Planned, not yet available: buyer-facing credentials, the read endpoints buyer agents would call, tenant-owned signing keys, and signed responses. The sections below marked “planned” describe the design. We will build it when a buyer organisation is ready to use it.
What a buyer-agent query will look like (planned)
A buyer-side procurement agent at a Fortune 500 sourcing team is shortlisting suppliers for a forthcoming engagement. It needs FedRAMP-Moderate-authorised vendors with demonstrated past performance in healthcare, operating in CONUS.
The agent holds a credential you issued last quarter when their procurement lead reached out. It calls your discovery URL, authenticates, and queries your capability graph: FedRAMP-Moderate certifications, past-performance claims tagged healthcare, jurisdiction-coverage including CONUS, freshness current. It receives a signed response — not a sales pitch — with the claim ids, the kind-specific structured fields, the freshness state at the moment of read, and a verifiable link back to the underlying evidence (subject to your redaction policy).
The agent verifies the signature offline against your tenant-owned public key. A structured "verified" result feeds into the buyer’s shortlisting workflow. No RFx has been written. No human has been emailed. You have not lifted a finger. And yet you are now on the shortlist — because your published graph said you could be.
What you publish
A capability claim is a tenant-owned assertion backed by approved evidence, valid in stated jurisdictions, mapped to procurement category schemes (NAICS, UNSPSC, or tenant-defined), and freshness-tracked. Five kinds in the MVP — four with structured fields, one escape hatch.
Certification
Third-party attested credentials — SOC 2, ISO 27001, FedRAMP, ISO 9001, sector-specific licences. Carries certifying authority, certificate identifier, attested scope, validity window, attestation kind.
Past performance
Completed engagements offered as evidence of capability. Carries customer sector, engagement value range, period of performance, role (prime / sub), and reference-permission gating.
Capability statement
A capability assertion that does not naturally have a third-party attestation — for example, "we operate 24×7 SOC-controlled environments in three regions." Backed by your own approved evidence.
Jurisdiction coverage
Geographic and regulatory scope assertions — "authorised to deliver to US federal customers under SAM-registered status," "VAT-registered in Germany." Carries jurisdiction, regulatory regime, registration identifier.
Every approved claim is freshness-tracked across four inputs (calendar validity, evidence freshness floor, last review, evidence approval state). When a buyer agent queries your graph, the freshness state is computed at read time — never a stale cache. Material changes to an approved claim happen via supersession (a new claim version), not in-place edits, so historical reads remain interpretable.
What the buyer agent will do (planned)
The design has five steps, all under credentials you issue. None of them require BidAngel to be a trusted party in the trade. None of them is available yet.
Discovery
The buyer-side agent calls a per-supplier well-known URL (you share it with them out-of-band). The discovery payload tells the agent which endpoints exist, which manifest versions are supported, and how to authenticate.
Authentication
The agent presents a supplier-issued bearer credential (the bbk_ prefix). Each credential is per-buyer, per-scope, with a per-credential rate limit and quota — and is fully revocable at any time.
Read
The agent fetches the resource it is scoped for: a signed submission package manifest (Flow 1) or a query against your capability claim graph (Flow 2). Anything outside scope returns a uniform "not in scope" rejection — no information leakage.
Offline verification
The agent fetches your public key (rotatable, KMS-anchored, optionally tenant-anchored for sovereign requirements) and verifies the JWS signature offline. Verification has no runtime dependency on BidAngel — the agent could verify with us offline, with us down, or after we are gone.
Audit on your side
Every read — successful, scoped-rejected, rate-limited, or quota-exceeded — appears in your audit log. You see who read what, when, under which credential, with what redaction policy applied.
Governance you will control (planned)
The design is conservative on purpose. Every primitive that gives buyer agents something to query is paired with a primitive that gives the supplier control of disclosure. The directory rules in the last card are in force today; the rest is planned.
Tenant-owned signing keys
Per-tenant Ed25519 keys, KMS-anchored. BidAngel operates the read surface; we are not a trust authority. Buyer agents verify against keys you can rotate or, in sovereign deployments, hold yourself.
Per-buyer scoped credentials
You issue a credential per buyer relationship, scoped to specific packages, pursuits, opportunities, or claim-graph slices. Rate limit and quota per credential. Revoke individually without affecting any other buyer.
Redaction-aware signed responses
Three MVP redaction modes for manifests (full, redacted-audit-excerpt, redacted-evidence-manifest). Each mode is independently signed at assembly time, so verification works offline against the variant the buyer actually receives.
No marketplace, no scores, no platform-curated rankings
BidAngel does not aggregate suppliers, does not score them, and does not rank them. The opt-in supplier directory exists for discovery, but the API rejects every sort other than alphabetical or recency, surfaces no engagement metrics, and exposes no cross-supplier comparison surface. The cryptographic verification surface (claim graph, signed manifests) requires a credential you issued; there is no path to verifiable supplier data that you did not authorise.
How this composes with bid response
Flow 1 (RFx response) and Flow 2 (capability discovery) share one capability graph. Every pursuit you run through BidAngel approves more claims, links more evidence, refreshes more validity windows. The graph that powers your bid responses today is the same graph buyer agents are planned to query.
The two flows are not alternatives. They are the same primitives expressed in two directions — one inbound (you respond to a buyer’s published intent), one outbound (a buyer agent queries your published graph). The compounding works because the substrate is the same.
Pricing — planned to be included in your plan
When buyer-facing credentials are available, each tier will include a quota of them, with claim-graph access unlocking at Operate and above. Buyer-side reads will be absorbed into your existing agent-operations envelope at a steep discount weight (typically 0.1–0.3× a supplier-side dispatch).
We will not charge you per buyer-agent query as a separate line item. Being discoverable should not cost you money — that is the whole point.
Buyer-facing credentials are not yet available for either flow. We are looking for design partners, on the supplier side and the buyer side, to build them with. Interested? Get in touch.
See tier allowances →