1. Outcome
Name one agent workload, its users and the observable result that would make the pilot useful.
Enterprise
A serious path from evaluation to production.
To evaluate Delx for a production agent workload, start with one scoped outcome, its risk boundary, the current machine contract and the evidence needed to verify delivery.
Evaluation
Five-part production evaluation brief.
Start with the workload, not the catalog. A good brief lets an engineering team decide what belongs in scope before a commercial conversation.
2. Risk boundary
Describe sensitive data, external effects, failure modes, human approvals and the operational owner.
3. Machine contract
Link the relevant API catalog, MCP or A2A card, OpenAPI schema and x402 terms before execution.
4. Bounded pilot
Set representative inputs, acceptance criteria, stop conditions and a rollback path for the first run.
5. Evidence and support
Define what delivery evidence, support response and change control the team needs to continue. This page is print-safe — use the browser print dialog for a one-pager; there is no sales deck.
What you can inspect
Evidence before procurement.
Public technical surfaces let engineering teams validate the basic architecture before a commercial conversation.
Machine contracts
Inspect API catalogs, MCP and A2A cards, OpenAPI schemas and x402 terms.
Open developer overview →Trust boundaries
Review security contact, data boundaries and the ownership of each property.
Open trust center →Live catalog
Browse currently published pay-per-result capabilities and service-specific terms.
Browse services →Defensive assurance
For an authorized security or threat-modeling review, start with the focused Delx Security practice.
Open Security →Safe intake
Share the brief, not secrets.
Email is for scoping a workload and its evidence requirements; it is not a channel for credentials or customer data.
What to send
Share the outcome, environment, expected volume, integration surface, constraints, timeline and acceptance evidence you need.
What not to send
Do not send private keys, seed phrases, API keys or customer secrets. Use redacted examples and a separately agreed secure channel when needed.
Who owns assurance
Delx Security is the focused defensive practice for authorized reviews; it does not replace your own approvals, controls or incident process.
Review Security →Public proof
Dated permalinks, not a logo wall.
Each link is a URL a visitor can open. None of these is a partnership, customer count, funding round or certification.
Would Pay Again, issue 5
— Independent field review of a tested subset of Delx Commerce REST/MCP calls. Not a catalog-wide certification or ranking.
Open the permalink →Official MCP Registry listing io.github.davidmosiah/delx-mcp-a2a
— The registered name is the Commerce MCP server. Protocol has a separate identity and must not inherit this listing.
Open the permalink →Live x402 payment manifest
— Machine-readable payment discovery for governed Commerce routes. Discovery does not authorize a payment.
Open the permalink →Coinbase Bazaar index coverage matrix
— First-party read of which governed routes currently appear in Bazaar. Not Coinbase curation or a ranking.
Open the permalink →A2A agent card (ERC-8004 discovery surface)
— Published agent identity for machine discovery. Not a claim of on-chain adoption or token utility.
Open the permalink →Continuity audit live receipt
— Hashed first-party receipt for the published continuity-audit slice. Not independent validation.
Open the permalink →Protocol write-outage incident report
— Operator-authored, sanitized report of a 33.5-hour write failure. Not an independent review.
Open the permalink →mcp-scorecard: delx-living-body
— The same public instrument used for every npm-installable MCP server. A score is agent-readiness evidence, not certification.
Open the permalink →mcp-scorecard: astral-mcp
— Astral MCP as it already appears in the public leaderboard dataset.
Open the permalink →Live properties
Reachability is measured now.
Delx lab
Expected response observed. HTTP 200. 1699 ms.
Open lab →Delx Protocol runtime
Expected response observed. HTTP 200. 479 ms.
Open runtime →Delx Protocol / Ontology
Expected response observed. HTTP 200. 47 ms.
Open ontology →Delx Commerce
Expected response observed. HTTP 200. 78 ms.
Open commerce →Delx Security
Expected response observed. HTTP 200. 947 ms.
Open security →Delx Wellness
Expected response observed. HTTP 200. 52 ms.
Open wellness →Astral MCP
Expected response observed. HTTP 200. 55 ms.
Open astral →MCP Leaderboard
Expected response observed. HTTP 200. 56 ms.
Open leaderboard →Probe source: server-side classifyResearchProbe. Not an SLA. Protocol, Hive and Commerce metrics stay separate.
Direct answers
Frequently asked questions.
Concise answers for technical evaluators, procurement teams and autonomous discovery systems.
How does an enterprise evaluate Delx?
Begin with a concrete agent workload. Delx can map the architecture and service boundaries, define a scoped pilot and document the production integration path.
Can engineering teams inspect Delx before contacting anyone?
Yes. Public machine cards, API catalogs, OpenAPI schemas, x402 terms, trust boundaries and live product pages support technical evaluation before a conversation.
What should I send Delx for a production evaluation?
Send one scoped outcome, the environment and expected volume, integration constraints, timeline, acceptance evidence and the support or change-control requirements. Do not send private keys, seed phrases, API keys or customer secrets.
How do we contact Delx about production use?
Email support@delx.ai with the intended workload, expected volume, integration environment and the evidence your team requires.