Skip to content

Site search

Type to search Pages

AI procurement agent

Give your sourcing agent a shortlist it can trust.

When a task needs a counterparty your agent has not engaged before, Elidian returns candidates matched to the capability — within your governor's rules, checked for current standing, and logged for review.

The sourcing task

From a task to a logged shortlist.

The path an agent follows when a sourcing task requires a counterparty it has not used before.

  1. Submit a capability query

    When a task needs a counterparty your agent has not engaged, it sends the required capability to the directory instead of searching ad hoc.

  2. Match against verified listings

    The matching engine returns candidates drawn from verified listings, using a normalised taxonomy so results stay comparable across companies.

  3. Filter to authorised counterparties

    The eligibility filter removes any candidate outside your governor's rules, authority limits and value thresholds set for that agent.

  4. Suppress lapsed listings

    The scanner suppresses listings whose credential or trust standing is stale, expired or inconsistent, so lapsed standing does not reach the shortlist.

  5. Log the query and shortlist

    The shortlist and the query event are recorded, so a governor can later see which counterparties qualified and on what basis.

What the agent relies on

The controls that sit behind each returned candidate.

Every shortlist your agent receives is shaped by rules a named person owns.

Rules your governor configures

Governors define eligibility and policy-compatibility rules, authority limits and value thresholds per querying agent, so an agent only considers counterparties it has been pre-authorised to see.

Onboarding stays a human decision

New counterparty listings, and any ambiguous or high-stakes verification case, route to a human governor for approval rather than being auto-approved.

Verification against real sources

Credentials are checked against submitted and third-party sources. Elidian consumes upstream verified identity and credential assertions rather than minting its own identity.

Standing built from outcomes

Reputation records are maintained from logged interaction outcomes, so a counterparty's trust standing reflects its history rather than a one-off claim.

An audit trail on demand

Every discovery and selection event is retained to support procurement audit, dispute resolution and governance review when an oversight question is raised.

A gate, not a marketplace

Elidian verifies standing and stops there. It does not negotiate, contract or settle, and holds no funds, keeping it outside payment-intermediation risk.

Why an eligibility layer, not another questionnaire.

Most counterparty onboarding today is a questionnaire. A person emails a form, waits for documents, and reaches a trust judgement by hand. Vendor benchmarks put that at one to three weeks and thirty to sixty minutes of staff time per vendor — a serial process that does not scale as agents raise the volume of counterparties to consider. Elidian does not remove the human judgement at the top of that discipline. It removes the repeat manual search and lets verified standing be checked at the moment an agent queries.

What it deliberately does not do

Elidian verifies standing and returns eligible candidates. It does not negotiate, contract or settle; those steps sit in adjacent layers. Stopping there is a design choice. It means the directory is useful on its own, before the wider agent ecosystem is large, and it keeps accountability where it belongs: the human governor sets the rules, approves onboarding, and owns the fiduciary duties attached to what is certified as trustworthy.

The dependencies we are honest about

Coverage is a fair question. A directory is only as useful as what it lists, and early on the set of listings is modest, seeded first from the Cohort Ventures ecosystem. We do not claim comprehensive coverage. We claim that even a modest set of verified listings serves real discovery for a defined sourcing task, and that value compounds as more parties list and query.

Two further dependencies shape what Elidian can promise. Capability descriptions are not naturally comparable across companies, so a normalised taxonomy is maintained to keep queries comparable — an ongoing task, not a solved one. And Elidian relies on verified identity and credential assertions from an upstream layer; where those assertions are absent or out of date, a listing cannot be certified, and the staleness scanner exists to catch entries whose standing has lapsed.

What is still being proven

We are candid about what is unproven. A primary-sourced return benchmark for displacing manual vetting is still being built, and willingness to pay is a hypothesis we are testing with early design partners rather than a claim we ask you to accept. Because every discovery and selection event is logged, the record needed to measure that case exists from the very first query — which is also the record a governance or audit review will ask you to produce.

What sourcing teams ask before they rely on it.

Bring us a sourcing task your agents cannot clear.

Tell us the capability you need to source and the rules a governor must enforce. We will walk through how a candidate would be verified and returned.