Production Readiness Assessment

18 September 2026 · repository HEAD `2c711e01` · 77 packages · 50 contracts · one deployed estate

Verdict: pre-production, honestly labelled. GO for testnet pilots and demonstrations on our own chain. NO-GO for a real person's private data, for real value under delegated payments, and for a public mainnet — each with named, dated closing conditions (§2.3).

This document is what we would hand a senior third-party auditor or a technical due-diligence team today. It is a self-assessment produced by the maintainers from the repository's own evidence — the findings ledger, the continuous gates, the test suites, and a line-by-line review of the deployed configuration — completed on 17 September 2026 and re-verified on 18 September after a hardening wave closed thirty of the thirty-four findings it raised. Where something is unproven we say so; where something is fixed in source but not yet deployed we say that too, because the difference is the whole point.

How to read this document

The grades

Two distinctions govern every grade below. Closed in source is not deployed — a fix that has landed with tests but has not been rolled to the environments people use does not reduce live exposure, and we grade the estate on what is running. A finding against how a component is configured in the estate is not a finding against the component — those are graded in §5 and referenced, not double-counted, in §3.

1. What Agentic Primitives is

Agentic Primitives is a substrate — packages and contracts, not a platform — for building software agents that act under authority the agent cannot exceed. Every person, organization and service is an ERC-4337 smart account (a Smart Agent); authority to act flows from a principal to an agent as a signed, attenuable, on-chain-revocable delegation (ERC-7710-shaped) whose caveats bind what may be done, to whom, for how much, and — through an intent digest — for which specific request. A planner may be probabilistic; the check that stands between the plan and the effect is not.

Five properties are enforced by contract rather than by policy code, and no product we have surveyed composes all five:

1. Identity survives the runtime — the agent is the account, not a token issued by whoever hosts it.
2. Attenuation is a chain — each hop of delegation can only narrow the previous one, verified on chain.
3. Revocation is checked per step — not at login, not per session; before each effect.
4. The intent is a caveat — the digest of what the person approved binds the delegation that acts on it.
5. Single-use by construction — a digest-bound redemption is consumed once, on chain.

Around that core sit the layers a working agent needs: naming and discovery, a private vault with per-record delegation scope, an authority-aware harness (Ask → Intent → Mandate → Plan → per-step Verify → Receipt), an admission edge for A2A and MCP, provenance and receipts, coordination between agents, and a formal ontology that the code binds to by IRI. The nine capability areas in §3 and §6 are these layers.

The repository is Ring 0: primitives only. Products (the Home, the discovery registry, the naming service) are built from it and deployed as the estate assessed in §5.

2. Executive assessment

2.1 The numbers

2.2 What held, and what did not

Held. The authority plane is not probabilistic in code. Every tool that declares a capability is verified per step against a signed, chain-live, intent-bound mandate before it runs; the planner picks from an exact tool set and cannot rename a tool, lower its risk, or mint a mandate; unattended runs present no mandate and park for the person; payments are single-use on chain; a resumed run re-verifies against current chain state; a replay never re-runs a tool. Identity keys are delegates of a custodied identity, never the identity itself. The package dependency graph is acyclic with no back-edge found in a workspace-wide sweep. Records are portable: a person's data can be carried to a second Home and every record read by session alone, with the receipt anchor read back from chain.

Did not hold (17 September), now closed in source (18 September). One unmodelled contract boundary — the account's execute reaching contracts that treat the account itself as principal below the custody tier — produced both new contract Highs (a custodian could brick a custody-governed account; approved-hash delegations survived custody recovery). The delegation core's session binding was looser than doctrine (a session key could redeem any delegation its principal ever signed). Stewardship of an organization's agent had regressed to self-assertion. Three harness perimeters were prompt-only (planner-callable memory writes; an external server's readOnlyHint deciding that no mandate was needed; the mandate not binding the plan's other arguments). Several CI gates claimed more than they read. All of these are fixed with tests; the contract fixes await deployment.

Still not held (operations and posture). No governance, timelock or guardian is deployed on the chain that is the authority substrate, so the live stack cannot be halted or upgraded under governance. The custody master key runs from a local secret in every environment. The one record store's backup is unscheduled. There is no alerting. The managed-KMS caller identity is shared across two estates. No code change closes these; they are the work of the next wave and the reason the verdict has not moved.

2.3 Segmented posture

3. Packages, by capability area

Seventy-seven packages, graded on their own code. "Tests" counts test files in the package. "Open findings" lists ledger items whose declared concern is a path in the package; where the finding is really about how the estate configures the package, the note says so and the grade is Amber, not Red. Versions: eighteen packages sit on the 1.0.0-alpha.25 core lineage; the remainder on 0.0.0-alpha.x. A package on the 0.0.0 lineage with fewer than two test files is graded Amber for that reason alone.

Summary: 48 Green · 29 Amber · 0 Red. No package is Red on its own code. The Ambers fall into four classes: a Medium finding names the package (14), an estate-scoped Critical/High references it (3: key-custody, contracts, fabric), early stage (3: intent-resolver W1 skeleton, content-storage scaffold, the deprecated agent-skills alias), or thin tests on the 0.0.0 lineage (9).

Identity (19 packages)

Authority (8 packages)

Harness (agent runtime) (9 packages)

Edge and protocols (8 packages)

Registry and discovery (7 packages)

Evidence and provenance (9 packages)

Coordination and collaboration (4 packages)

Ontology (1 packages)

Operations, data and developer kit (12 packages)

4. Contracts

Fifty Solidity sources under packages/contracts/src. 939 / 939 tests pass at HEAD. Thirty contracts (counting the account implementation behind the factory) are deployed on faithchain (and Base Sepolia); the rest are libraries, interfaces, abstract bases, a mock, and two governance contracts that are written and tested but not deployed — the single most consequential fact in this section.

Generation 2. The 18 September hardening changed six contracts (AgentAccount, AgentAccountFactory, ApprovedHashRegistry, CustodyPolicy, DigestBindingEnforcer, ReceiptAnchorRegistry). Those changes are graded here as fixed — the tests that reproduce the 17 September findings now pass — but every deployed environment declares CONTRACTS_GENERATION = "1", and the runtime deliberately ships against the deployed generation. Their grade carries the mark G2 to say: the code you would audit is not yet the code that is running.

Verification coverage, stated honestly. 939 unit and integration tests; three invariant suites; echidna nightly and medusa weekly on the delegation and custody paths; seven halmos symbolic proofs — all over onlySelf and WebAuthn paths, none over the redemption path end to end. Static analysis (slither, aderyn) runs in CI; aderyn is advisory. No third-party audit of the current code exists. The most recent external assessment (June 2026) returned No-Go for real funds, durable authority and PII, and its blocking items are tracked in the ledger; a fixed-commit audit is the mainnet closing condition, and the contract layer is now in a state to freeze for it once generation 2 is deployed.

5. The estate

The estate is the product deployment built from these packages: the Home a person signs into, the runtime that acts for them, the vault that holds their records, the edge that admits traffic, and the chain that holds authority. Four environments run today — faithnet and faithnet-b (faithchain), production (Base Sepolia), and the ap-home product mirror. Each piece is graded on what is running, not on what is in source.

Estate configuration truth table (the flags that decide posture; every row verified against the deployed configuration files on 17 September):

6. Capability areas against the field

For each area the substrate covers: the products a reviewer will already know, what we ship, and where we stand. "Ahead" means a property they do not have and we enforce; "at par" means comparable; "behind" means they have it and we do not. Dates are as of September 2026. The field survey behind this table is maintained as a spec in the repository and refreshed each review.

6.1 Agent identity

Products in the area. Okta Agent SSO (GA Aug 2026) and Okta for AI Agents · Microsoft Entra Agent ID (GA Apr 2026) · Auth0 Agent as Principal · WorkOS, Descope, Hush, Cymphony · ERC-8004 identity registry (mainnet Jan 2026, 170k registrations) · Kite Agent Passport

What we ship. A Smart Agent (ERC-4337 account) per person, organization and service — the address is the canonical identifier; credentials (passkey, SIWE, hardware) rotate under a custody policy while the identity persists; typed hierarchical naming (.me .org .team .svc .workspace .treasury .registry); canonical profile with a signed A2A card projection; FedCM-first browser sign-in; a private, holder-resident record of person↔org relationships.

Where we stand. Ahead on the model, behind on the bridge. Every enterprise product models an agent as a directory object with a human owner and a short-lived token — identity that exists at the pleasure of the issuer. Ours survives the vendor, the runtime and the credential. What we lack is the binding from their world: no signed link from an Okta/Entra/Auth0 agent token to a Smart Agent, so an enterprise cannot yet bring its directory agents to our authority model. ERC-8004 has scale we do not publish to; a projection is the named gap.

6.2 Delegated authority and policy enforcement

Products in the area. Auth0 nested act claims · AWS AgentCore Identity + Policy (Cedar, "verified by automated reasoning") · Google Agent Gateway (IAM + Model Armor on HTTP/MCP/A2A, ext_authz hook) · agentgateway (CNCF) + Cerbos / OPA · OpenID AuthZEN · MetaMask Smart Accounts Kit (ERC-7710 delegations, ERC-7715 permission requests) · Lit Vincent · Smart Sessions

What we ship. EIP-712 delegations with composable caveat enforcers (targets, methods, calldata hash, value, time, quorum, payment, intent digest); on-chain revocation checked per step; a mandate = delegation + intent digest, verified before every effect; the whole authority chain assembled and verified against chain state, not as claims about the past; a fail-closed admission engine; a protocol-agnostic risk ladder and exact-call tool policy.

Where we stand. Ahead on semantics; absent on the wire; behind on formal proof. Nothing in the field verifies an attenuation chain against live chain state per step — theirs is a token that was true when minted, or an ACL the platform holds. But their gateways cannot call our verifier: we publish no AuthZEN or ext_authz decision endpoint, so a Google or agentgateway deployment has no way to ask us "may this proceed?". Cedar's "formally verified" phrasing is now a reviewer's expectation; our enforcers are fuzzed and seven proofs exist, none over the redemption path end to end. Interop with MetaMask's 7710 objects is aligned by design and untested in practice; ERC-7715 requests are not implemented.

6.3 Custody, recovery and keys

Products in the area. Safe (multi-sig) · Privy, Turnkey, Fireblocks (custodial key infrastructure) · Coinbase AgentKit wallets · Kite (custodian in the loop) · Lit Protocol

What we ship. Our own custody module (ERC-7579 executor): threshold, guardians, timelocked recovery, custody epochs; credential rotation that never changes the identity or invalidates its delegations; a pluggable key-custody seam (local, AWS, GCP, our managed-KMS pilot); service keys that are delegates of a custodied identity, never the identity. No third-party multi-sig dependency.

Where we stand. At par on custody design, behind on operating maturity. The design is stronger than a wallet-provider model because recovery is governance, not a delegation, and a compromised service key is a revocable delegate. The estate does not yet live up to it: the custody master key is a local secret everywhere, and the managed-KMS pilot shares one caller identity across two estates. Fireblocks-grade operations — HSM-backed everything, key ceremonies, audited backups — are the gap, and they are operations, not architecture.

6.4 Agent runtime, harness and durable execution

Products in the area. LangGraph / LangSmith Deployment · Microsoft Agent Framework + Foundry (Durable Task) · Google ADK 2.0 · OpenAI Agents SDK (re-architected Apr 2026; Agent Builder retiring Nov 2026) · Anthropic Claude Agent SDK and Claude Managed Agents · AWS AgentCore Runtime · Temporal ($12.55B, Sep 2026), Restate, DBOS, Orkes · Cloudflare Agents SDK · Agno, Strands, Mastra, CrewAI, Pydantic

What we ship. An authority-aware harness: Ask → Intent → Mandate → Plan → per-step Verify → Receipt; a Ring-0 orchestration loop with planner and tool-invoker as ports (Anthropic and OpenAI-compatible bindings; five providers budget-routed in the runtime); playbooks (SKILL.md packages) pinned by digest; checkpoints where a resume re-verifies authority; replay that never re-runs a tool; fan-out that is N mandates; a Durable Object / Workflows binding for durable steps; admission of existing runtimes (Claude Code, goose, Codex) as workspace members over ACP.

Where we stand. Ahead on "may this run?" and "what ran?"; at par on durable execution with one binding; behind on observability tooling and hosting. Every framework above has guardrails as policy code around a probabilistic loop; ours puts a contract between the plan and the effect. LangGraph's time-travel and LangSmith's traces, Foundry's durable tasks and OTel conventions are the reference points; we match checkpoint/resume and exceed them on what a resume must re-prove, but our durable-step port has a single (Cloudflare) adapter, we export no OpenTelemetry, and we offer no multi-tenant hosted runtime for third parties. The visual builder we deliberately did not build is the one OpenAI is retiring.

6.5 Edge, protocols and admission

Products in the area. MCP (revision 2026-07-28; auth hardening: CIMD, RFC 9207) · A2A 1.0 (Mar 2026; JSON-RPC, HTTP+JSON, gRPC) · Google Agent Gateway · agentgateway · Cloudflare AI Gateway · Kong / Apigee AI gateways · SPIFFE / mTLS meshes

What we ship. Our own A2A 1.0 implementation — official TCK green (MUST 88 / SHOULD 8 / MAY 4) on the JSON-RPC binding; MCP protocol primitive negotiating 2026-07-28 and 2025-11-25; delegation-aware MCP middleware where OAuth is an ingress envelope and Web3 is the authority; a vendor-neutral admission edge (HTTPS required, mTLS optional evidence, admission always) with a Cloudflare adapter; rate control per Smart Agent as a hard budget.

Where we stand. At par on A2A (JSON-RPC), one revision behind on MCP auth, ahead on what admission means. The field treats a gateway as a place to apply an ACL; ours is where transport evidence, application authentication and canonical identity resolution are ordered and nothing skips a stage. Gaps: the HTTP+JSON and gRPC A2A bindings are not served; the MCP OAuth adapter lacks Client ID Metadata Documents and the RFC 9207 issuer check; no third-party runtime has yet been recorded reaching one of our agent cards.

6.6 Registry, discovery and naming

Products in the area. ERC-8004 (170k registrations; 3–15 % with a live endpoint) · GoDaddy ANS · Hashgraph HCS registries · MCP Registry (12.7k components) · Project NANDA · AGNTCY · DNS-AID · ENS

What we ship. A registry kit, not a registry: Smart-Agent-anchored entries, pluggable membership and validation hooks, signed cards with binding proofs, admission receipts and a lifecycle log, evidence-only trust (never a score); typed contextual resolution (alice@workspace); a public discovery knowledge base holding only chain-derivable facts; an ARD / ACP-compatible read tier; private, recipient-bound resolution grants for agents that are unlisted.

Where we stand. Ahead on doctrine, absent on distribution. The registries that exist are mostly placeholders (ERC-8004's own numbers say so), and reputation-as-score is what we refused to build. But we publish to none of them: there is no projection of our entries to the 8004 identity registry or the MCP Registry, so an agent built here is findable only where we run a registry. Private resolution — "may this party discover how to reach this agent?" as a grant separate from "may it use it?" — has no peer we know of.

6.7 Evidence, provenance and observability

Products in the area. LangSmith · Langfuse · Arize · OpenTelemetry GenAI semantic conventions (still Development) · W3C PROV-O (standard) · PROV-AGENT (research) · Datadog / Honeycomb LLM observability

What we ship. Three layers: OpenTelemetry-shaped spans with a firewall, W3C Trace Context as the cross-agent spine, and PROV-O saying what the trace means — a span is a PROV activity; a signed receipt per act; verifier-retained verification receipts (commitment-split evidence that signature, scope and revocation were checked at time T); receipt anchors on chain; an operator view over the evidence; SD-JWT selective disclosure and pairwise pseudonyms for presentations; dispute attestation by deterministic walk.

Where we stand. Ahead on evidence, no exporter, unmapped for compliance. The field records traces for debugging; ours are evidence a third party can verify against chain state. But we export nothing to the OTel ecosystem the field lives in, so a customer's Datadog cannot see our runs, and the artifacts a regulator wants (EU AI Act Art. 12 logging, Art. 14 oversight; ISO 42001; NIST AI RMF) are produced by construction with no written crosswalk that lets a compliance officer see it.

6.8 Payments and mandates

Products in the area. AP2 (in FIDO since Apr 2026; v0.2 Human-Not-Present) · Mastercard Verifiable Intent · x402 Foundation (LF, Jul 2026; 40 members incl. the card networks) · Stripe MPP · Visa TAP · OpenAI/Stripe ACP · Virtuals ACP · Skyfire, Nevermined, Crossmint · MetaMask Smart Accounts Kit paying x402 via 7710

What we ship. A payment mandate bound to its context; the intent digest as a delegation caveat with a single-use on-chain PaymentEnforcer; three rails (x402 v2, direct wallet, sponsored UserOp); settlement receipts on chain; a paymaster with per-agent budget; the two-flip offer algebra that treats listings, carts and auctions as one shape.

Where we stand. Same idea, no projection; at par on x402. AP2's Intent/Cart/Payment mandates and Mastercard's Verifiable Intent are the artifact we call the intent-digest caveat — and we have written no adapter that emits or accepts theirs, so a merchant on AP2 cannot honour our mandate. x402 v2 is implemented; conformance against the Foundation's text has not been re-checked since the transfer. Card rails (MPP, TAP) are not ours to build; the mandate must project onto them. Real-value pilots run on mock USDC.

6.9 Coordination between agents

Products in the area. Microsoft Agent Framework handoffs · LangGraph multi-agent · Google A2A task model · Salesforce Agentforce · Virtuals ACP (commerce lifecycle) · Buzz.xyz · Slack / Notion / Lindy agent workflows

What we ship. Two planes kept apart: coordination between agents (durable Endeavors, shared CoordinationPlans adopted by decision, participants resolved by capability through discovery, signed contribution commitments against an exact plan revision) and orchestration within one agent (the harness). Interactions as a governed root aggregate with immutable signed exchanges; huddles as governed collaboration activities; workspace and club contexts with standing grants.

Where we stand. Ahead in kind, unproven across Homes. Every framework's "handoff" is a function call between agents the same operator runs; ours is a signed commitment between principals who may not trust each other's runtime, and neither plane is authority. The claim that this works across two independently operated Homes — the federation proofs (G4–G6) — is written down and not yet demonstrated; that is the gap. Buzz-style approvals are a click; ours is a signature — a differentiation we have, and a UX cost we carry.

6.10 Knowledge, context and memory

Products in the area. Claude Managed Agents (versioned memory, per-user credential vaults) · AWS AgentCore Memory · Mem0, Zep, Letta · LangGraph stores · Notion / Glean enterprise context · Inrupt Solid pods

What we ship. Two tiers that are never joined in an engine: a public knowledge base (RDF, only chain-derivable facts) and a person's private vault (encrypted, per-record delegation scope, questions compile to selectors evaluated in the store). Memory as vault-resident records the person owns; connectors (any MCP server) admitted under her grant, never the platform's; documents as evidence her agent reads. A truthfulness evaluation set seeded from live incidents.

Where we stand. Ahead on ownership and portability, at par on capability, behind on adversarial evaluation. Every hosted memory product is a platform store; ours travels with the person to another Home and is scoped per record. Self-authorized writes now require the person's turn (18 Sep) — the prompt-only perimeter the review found. What we lack is an external adversarial corpus (injection, tool poisoning, memory poisoning — the OWASP ASI categories) with "unauthorized effect = 0" as the published metric; our evaluation set is truthfulness-only.

6.11 Ontology and semantic grounding

Products in the area. Palantir Foundry ontology · Schema.org / OASF · W3C PROV-O, VC, DOLCE · enterprise knowledge-graph vendors

What we ship. One formal vocabulary (RDFS/OWL T-box, SHACL/SKOS C-box) grounding identity, authority, interaction, coordination, execution and provenance; code binds to it by IRI and a build gate fails when it does not; domain relationships live in the ontology, not in prompts or tables; on-chain term and shape anchors.

Where we stand. Ahead; no direct peer at the substrate level. Palantir's Action Types are the closest analogue and are a product feature; ours is the thing the products are compiled from — one capability model generates the UX affordance, the Ask's vocabulary, the A2A card and each act's mandate requirement. The risk is the opposite of the field's: sophistication that a stranger must learn before contributing.

6.12 Security, operations and compliance posture

Products in the area. OWASP Top 10 for Agentic Applications (2026) · NIST AI 100-2 / AI RMF · EU AI Act (Art. 50 in force Aug 2026; Annex III Dec 2027) · ISO/IEC 42001 · SOC 2 · agent-security vendors (Zenity, Straiker, HiddenLayer, AIR)

What we ship. A findings ledger machine-checked for freshness on every CI run; 131 doctrine gates; 57 nightly live gates with negative twins that now fail the build; forge/echidna/medusa/halmos on contracts; a consolidated OWASP ASI01–10 map with an enforcement point per category; red-team scope and evidence checklist; a written methodology; this document.

Where we stand. Ahead on engineering culture, behind on external proof. Few projects at this stage have a ledger a stranger can audit or nightly gates that assert the negative case. But there is no third-party audit of the current code, no funded bounty, no SOC 2 for the hosted estate, no ISO 42001 / NIST mapping, no alerting, and governance is not deployed on the chain that holds authority. Security truth is now current (this review); posture is the gap.

6.13 Developer experience and ecosystem

Products in the area. Vercel AI SDK · LangChain ecosystem · shadcn-style registries · Cursor / Copilot / Devin (build tooling) · npm provenance / SLSA

What we ship. A Developer Kit: create-app writing a product repository, agentic.lock.json, ap doctor / ap test / ap conform as the doctrine gates in CLI form, rules projected by digest, a read-only Developer MCP; 210 specs and 65 ADRs as institutional memory; an /llms.txt and starter.

Where we stand. Behind, and honestly so. Every consumer is first-party; the repository is private; there are no download statistics, no external contributors, no public issue tracker, no published npm provenance. The kit has exited a clean machine once, measured across one developer. This is the dimension a diligence team writes as a closing condition for any thesis that depends on ecosystem, and no amount of architecture substitutes for it.

7. Open findings register

Every Critical and High, and the Mediums by class. Identifiers are the ledger's; a stranger with repository access can look each one up. Nothing here is an exploit recipe; the ledger entries that would be are held with the code.

7.1 Critical

7.2 High

Nine further Highs raised on 17 September — two contract, three delegation-core, one stewardship, three harness-perimeter — were closed in source on 18 September with tests. The two contract Highs await generation-2 deployment.

7.3 Medium, by class (30)

Sixteen Lows are tracked in the ledger and are not enumerated here.

7.4 Remediation order

8. Method, and how to verify

Who. The maintainers, with five parallel read-only review passes (contracts; authority packages; estate services; harness and knowledge plane; architecture, operations and supply chain) and a lead verification of every new High at its source line. No finding was accepted from a summary; each names a file and a symbol in the ledger.

What was read. All 77 packages and both domain packages; all 50 contracts; the deployed configuration of every environment; the product mirror; the CI workflows and the gates they run; the previous review (12 July 2026) and every open ledger item in scope, each re-verified at HEAD.

What was run. forge test (939/939); the audit-freshness gate (every open finding's anchor present in source); the production-deploy preflight (fails closed on the three named posture items); the full check:all set; the A2A TCK; and the 57 nightly live gates with negative twins.

What this is not. It is not a third-party audit. It is not a penetration test of the live estate. It is not a proof over the redemption path. It records those absences as findings rather than omitting them.

How a stranger verifies it. The findings ledger (docs/audits/findings.yaml) is the record; each entry names its concern paths, its anchor symbol and its enforcement level (code-present, test-covered, production-enforced, deployed). pnpm check:audit-freshness fails when an anchor is gone. The full internal review and its 18 September addendum, with file-and-line evidence, are in docs/audits/. Deployed contract addresses and the contract generation each environment runs are in packages/contracts/deployments-*.json and the runtime configuration. The next full review is due at the close of Wave R4 or 17 November 2026, whichever is first.

Agentic Primitives is a project of Agentic Trust Labs. This assessment is published as a statement of where the substrate stands, including where it falls short. Corrections are welcome; the ledger is the place they land.