Agentic PrimitivesAGENTIC PRIMITIVES

01 · The stack you would buy

An agentic solution takes 29 products. Or one substrate.

Sign-in. Wallets. Accounts and custody. Scoped permissions. Private data. Credentials. An agent loop. Durable workflows. Tools. Agent-to-agent calls. Payments. Admission. Names. Discovery. Evidence. Each is a product you select, contract for, integrate — and then reconcile with the others, because each brings its own idea of who a user is, what a permission is, and what a log line means. We built it that way first. Below is the wall of products it took, band by band, with the seam each band drags in — and beside it the same needs as slots in one model.

Thirty products, seven seams, three identity models, two permission shapes, three evidence formats — or one substrate where the same needs are slots in one modelSTITCHED — 29 PRODUCTS TO SELECT, CONTRACT, INTEGRATE, AND KEEP AGREEINGOR THE SUBSTRATEEvery band boundary is a seam: a person becomes a token, the token becomes a row, the row becomes a log line.pnpm add @agenticprimitives/*Sign-in + identity3 productsAuth0login · SSOPrivyembedded walletsWorkOSorgs · rolesidentity model #1 · a user idAccounts + custody4 productsSafeaccounts · multisigPimlicogas · bundlerTurnkeykeys · signing policyguardiansrecoveryidentity model #2 · a wallet address — joined by a table you writePermissions4 productsMetaMask DTKscoped authorityCerbospolicy engineOpenFGAdata accessHashiCorp Vaultsecretspermission shape #1 in a DB · shape #2 on chain — nothing joins themPrivate data5 productsPostgres + RLSprivate recordsVeramocredentialsEASattestationsDocuSignagreementsBoxcontentidentity model #3 · a row key, a DID, a credential subjectRuntime + wire6 productsLangGraphagent loopTemporaldurable workflowsMCP SDKtools + autha2a-jsagent callsXMTPmessagingStripepaymentsauthority as a callback the framework calls — if the code remembersEdge + discovery4 productsKongadmission · limitsENSnames8004 registrydiscoveryTailscaleprivate reachreachability mistaken for authority · an API key, a registry rowEvidence + tooling3 productsDatadogtracing · auditTopBraidvocabularytemplate repoconventionsevidence formats #1 spans · #2 logs · #3 attestations — joined by ids you inventorIdentityagent-account · connect · orgsCustodykey-custody · account-custodyAuthoritydelegation · tool-policy · entitlementsVaultvault · content-storage · credentialsHarnessharness · orchestration · a2a · mcpEdge + registryadmission · naming · registry-kitEvidenceprovenance · receipts · witnessOntologyontology · types — bound by IRI77 packages · 33 contracts · one identity29products7seams3identity models2permission shapes3evidence formats33contracts to write or fork1install0seams1identity1grant1trailone identity, one grant mechanism, one evidence trail — the seams are designed out, not papered overagenticprimitives.dev
Left: 29 products in seven bands, one realistic pick per need. The dashed line under each band is the seam it introduces — a second identity model, a second permission shape, a third evidence format. Right: the substrate, the same needs as eight slots in one model. There is nothing to reconcile because there is only one identity, one grant mechanism and one evidence trail.

Stitched — what it took the first time

30+
products to select, contract, integrate
and keep on the same page, release after release
3
identity models
user id · wallet address · credential id — and the joins
2
permission shapes
roles in a database; caveats on chain; nothing that says which one authorized an act
3+
evidence formats
spans, log lines, attestations — joined by ids you invent
33
contracts to write or fork
then audit, then deploy, then keep in step with the packages
seams
every one of them is where identity becomes a token and a token becomes a log line

On the substrate — now

77
packages under one scope
@agenticprimitives/* — one install, one type system, one changelog
33
contracts, written and under audit
ERC-4337 · 7710 · 7579 · 1271 · 6492 — deployed to any EVM
1
identity
the Smart Agent address; credentials rotate around it
1
grant mechanism
a signed, caveated delegation, verified at redemption, revoked in one transaction
1
evidence trail
PROV-O receipts the owner carries; a span is an activity
0
seams
the needs are slots in one model, not products at a boundary

The nightmare was never any one product. It was the thirty seams between them, every one of which was where a person became a token, the token became a row, and the row became a log line nobody could trace back to a decision.

Richard Pedersen — after building it the first time

Product by product — what you would buy, what you would buy instead, and the packages that cover it here

Every one of the 77 packages appears below exactly once, against the product it stands in for. Not because each row is impossible elsewhere — because here every row shares one identity, one delegation model and one evidence trail, and the seams between rows are where stitched stacks leak authority.

01Sign-in and identity

seam · identity model #1 — a user id in a vendor’s directory
Auth0
login, SSO, MFA
or · Okta · Clerk · Cognito
Privy
embedded wallets
or · Dynamic · Web3Auth
WorkOS
organizations, members, roles
or · Okta groups · your own tables

02Accounts, keys and custody

seam · identity model #2 — a wallet address, joined to the user id by a table you write
Safe
smart accounts, multisig
or · ZeroDev · Alchemy Account Kit
Pimlico
bundler, sponsored gas
or · Alchemy Gas Manager · Biconomy
Turnkey
key management, signing policy
or · Fireblocks · a cloud KMS console
Argent-style guardians
recovery, trustees
or · a Safe recovery module

03Permissions and delegation

seam · permission shape #1 — roles and policies in a database; shape #2 — session keys on chain; nothing joins them
MetaMask Delegation Toolkit
scoped agent authority on chain
or · Smart Sessions · Lit Vincent
Cerbos
policy engine, per-call decisions
or · OPA · Permit.io · Cedar
OpenFGA
fine-grained data access
or · Okta FGA · ABAC in the app
HashiCorp Vault
secrets, key release
or · AWS Secrets Manager

04Private data and credentials

seam · the third copy of every identity — as a row key, a DID and a credential subject
Postgres + RLS
private records per user
or · Inrupt Solid · an encrypted store
Veramo
verifiable credentials
or · SpruceID · walt.id
EAS
attestations
or · Verax
DocuSign
bilateral agreements
or · a signatures table
Box
content library, sharing
or · SharePoint · Drive · Notion

05Agent runtime and protocols

seam · authority as application code — a callback the framework calls if the code remembers to
LangGraph
the agent loop
or · MAF · ADK · OpenAI Agents SDK
Temporal
durable workflows, approvals
or · Dapr · Restate
MCP SDK + custom auth
tools and data for agents
or · an MCP gateway (Permit · Cerbos)
a2a-js + a task store
agent-to-agent calls
or · REST webhooks + API keys
XMTP
agent messaging, inbox
or · Matrix · Nostr
Stripe
payments, escrow, recurring
or · x402 · AP2

06Edge, naming and discovery

seam · reachability mistaken for authority — an API key at the gateway, a row in a registry
Kong
admission, rate limits, quotas
or · Zuplo · an API gateway
ENS
names
or · Unstoppable · GoDaddy ANS · LF ANS
an ERC-8004 registry
discovery, agent cards
or · AGNTCY directory · a hand-kept list
Tailscale
private reachability
or · DNTLS · a VPN

07Evidence, vocabulary and tooling

seam · evidence format #1 spans · #2 log lines · #3 attestations — joined by ids you invent
Datadog
tracing, audit, evals
or · LangSmith · Langfuse · OpenTelemetry + a backend
TopBraid
a shared vocabulary, schemas
or · a hand-rolled types repo
create-next-app + a wiki
scaffolding, conventions, CI checks
or · a template repo

And the 40 contracts you would otherwise write, fork or audit — already written, under audit, deployed as one set

Account

6

ERC-4337 · ERC-7579 modular core · ERC-1271 / 6492 · P-256 passkeys

AgentAccount.solAgentAccountFactory.solCustodyPolicy.solUniversalSignatureValidator.solSmartAgentPaymaster.solApprovedHashRegistry.sol

Delegation

9

ERC-7710 manager + caveat enforcers; the intent digest is ours

DelegationManager.solAllowedTargetsEnforcer.solAllowedMethodsEnforcer.solValueEnforcer.solTimestampEnforcer.solCallDataHashEnforcer.solPaymentEnforcer.solQuorumEnforcer.solDigestBindingEnforcer.sol

Naming

5

.agent root · ten typed subregistries (.me .org .team .svc .workspace .treasury .registry .church .circle .household)

AgentNameRegistry.solPermissionlessSubregistry.solAgentNameUniversalResolver.solAgentNameAttributeResolver.solAgentNamePredicates.sol

Registry kit · profile · relationships

8

What registries are built from; SA-anchored facets

AgentRegistryBase.solAgentProfileResolver.solAgentProfilePredicates.solAgentRelationship.solRelationshipTypeRegistry.solAgentRelationshipPredicates.solSkillDefinitionRegistry.solGeoFeatureRegistry.sol

Ontology on chain

3

Terms, shapes and typed attributes anchored for public facts

OntologyTermRegistry.solShapeRegistry.solAttributeStorage.sol

Commerce · evidence · governance

5

Receipts and agreements on chain; governance of the deployment itself

PaymentEscrow.solPaymentReceiptRegistry.solAgreementRegistry.solAgenticGovernance.solGovernanceManaged.sol

Libraries

4

Ported patterns, no runtime dependency

P256Verifier.solWebAuthnLib.solSignatureSlotRecovery.solMultiSendCallOnly.sol

Solidity 0.8.28 · ERC-4337 · ERC-7579 · ERC-7710 · ERC-1271 / 6492 · EIP-712 · P-256 / WebAuthn. Ported patterns, no runtime dependency on any third-party multisig or account kit. Deployed to faithchain with the ten typed name subregistries; deployable to any EVM.

The bill of materials, need by need — what you would assemble, what you would configure, where it bites, and what covers it hereshow
Sign-in and identity
agent-accountbrowser-identityconnectconnect-authconnect-clientfedcm-idpfedcm-rpAgentAccount.solAgentAccountFactory.solUniversalSignatureValidator.solP256Verifier.sol
Stitched
  • an identity vendor (Auth0 · Okta · Clerk)
  • a WebAuthn library
  • an embedded-wallet SDK (Privy · Dynamic · Web3Auth)
You configure: three identity models — a user id, a wallet address, a passkey credential id — and the mapping tables between them; OIDC clients per app; JWKS rotation; a recovery flow you write.
The seam: The person is a row in one system, an address in another and a credential in a third. Rotate a credential and the address changes; nothing downstream survives it.
On the substrate

One Smart Agent per person, organization and service. Passkeys and wallets are rotating credentials on it; the address never changes.

Accounts, custody and recovery
account-custodykey-custodyap-kmsdelegated-signerCustodyPolicy.solApprovedHashRegistry.solQuorumEnforcer.sol
Stitched
  • a multisig (Safe)
  • a guardian / social-recovery product
  • a cloud KMS
You configure: owner sets and thresholds per account; Safe modules; recovery ceremonies you design; key-rotation runbooks; who is allowed to add an owner, decided in a spreadsheet.
The seam: Custody governance lives in the multisig, application authority in your database. They do not know about each other.
On the substrate

Custody is an ERC-7579 module on the account: thresholds, guardians, recovery, approvals — governed on chain, one policy.

Permissions and delegation
delegationagentic-authorizationentitlementskey-authorizationtool-policyvault-authorityDelegationManager.solAllowedMethodsEnforcer.solAllowedTargetsEnforcer.solTimestampEnforcer.solValueEnforcer.solCallDataHashEnforcer.solDigestBindingEnforcer.solPaymentEnforcer.sol
Stitched
  • a policy engine (OPA · Cerbos · Permit.io)
  • a session-key or delegation toolkit (ZeroDev · MetaMask DTK)
  • your own roles table
You configure: two permission shapes — roles in a database, caveats on chain — kept in sync by hand; policy files; scopes on tokens standing in for authority; expiry as the only revocation.
The seam: A permission granted in the app is a token; a permission granted on chain is a delegation; nobody can say which one authorized a given act.
On the substrate

One grant mechanism: an ERC-7710 delegation with caveats that are enforcer code, verified at redemption, revoked in one transaction.

Agent runtime and orchestration
harnessorchestrationorchestration-anthropicorchestration-openai-compatservice-agentcontextruntime-memberDigestBindingEnforcer.sol
Stitched
  • an agent framework (LangGraph · MAF · ADK)
  • a tracing product (LangSmith · Langfuse)
  • a memory store
  • a model gateway
You configure: prompts that carry the domain rules; tool JSON schemas per agent; per-agent config; retries; a human-in-the-loop hook you wire to a chat approval.
The seam: The planner decides and the executor acts inside the same process. A "yes" in chat is the approval. Nothing outside the model checks the step.
On the substrate

Planner proposes, mandate authorizes, executor acts, receipt proves — the loop is a Ring-0 package; every step is verified outside the model.

Tools and MCP
mcp-runtimemcp-protocolmcp-oauthtool-policyvaultvault-authorityDelegationManager.solAllowedMethodsEnforcer.sol
Stitched
  • an MCP server framework
  • an OAuth authorization server for MCP
  • a per-tool secrets scheme
You configure: bearer scopes per tool; a service-account key in each server config; token exchange between hops; scopes that mean "decrypt everything" because they cannot mean less.
The seam: The MCP server holds the key. Whoever holds the server holds the identity, for anything, forever.
On the substrate

MCP is a private capability interface behind an admitted runtime; OAuth is the envelope; the on-chain grant is the authority; the service key is a revocable delegate.

Agent-to-agent and admission
a2aacpadmissionedge-runtimeedge-cloudflarerate-controlrate-control-cloudflareagent-profilefabric
Stitched
  • an A2A SDK
  • a message bus
  • an API gateway
  • mTLS / SPIFFE tooling
  • an agent-card you type
You configure: agent cards by hand; an endpoint registry; certificates per workload; rate limits per gateway; an allow-list nobody remembers to prune.
The seam: A certificate says which workload connected. It cannot say which agent, under whose authority, for what purpose.
On the substrate

A2A over HTTPS with admission always required; mTLS optional transport evidence; agent cards projected from the profile and signed; the edge admits, it does not orchestrate.

Payments and treasury
paymentsagreementsfulfillmentintent-engagementintent-marketplaceintent-resolverSmartAgentPaymaster.solPaymentEscrow.solPaymentReceiptRegistry.solPaymentEnforcer.solValueEnforcer.solAgreementRegistry.sol
Stitched
  • a payments processor (Stripe · Circle)
  • a paymaster / bundler (Pimlico · Alchemy)
  • a spend-control product
  • a reconciliation job
You configure: webhooks and their retries; two ledgers to reconcile; spending limits in a dashboard; who may pay whom, as a setting.
The seam: The limit lives in the processor; the approval lives in Slack; the transfer lives on chain. Three records, no receipt.
On the substrate

A treasury is a Service Agent. A payment is a delegation with a PaymentEnforcer caveat; the paymaster sponsors gas; the receipt is anchored.

Human approval
homeharnessdelegationsurface-catalogDigestBindingEnforcer.solApprovedHashRegistry.sol
Stitched
  • a Slack / Teams approvals bot
  • a workflow tool (Jira · ServiceNow)
  • a signing UI you build
You configure: approval rules per workflow; who is an approver, in a group nobody audits; a click recorded in a SaaS.
The seam: The approval is a click in someone else’s database. It authorizes nothing the executor can verify.
On the substrate

The approval is a signature: the confirmation IS the mandate, bound to the digest of the exact intent, verified at redemption.

Evidence, audit and provenance
provenanceverification-receiptsauditattestationswitnessevaluationAttestationRegistry.solPaymentReceiptRegistry.sol
Stitched
  • OpenTelemetry
  • a SIEM (Datadog · Splunk)
  • an LLM-tracing product
  • an attestation scheme (EAS)
You configure: three formats — spans, log lines, attestations — joined by correlation ids you invent; retention policies; a dashboard per product.
The seam: A trace says what ran. It cannot say who allowed it. Provenance and authorization are in different systems with different ids.
On the substrate

One PROV-O graph: a span IS an activity; every protected step leaves a receipt the owner carries; a trace id is correlation, never trust.

Records, privacy and consent
vaultvault-authorityprivacy-credentialsverifiable-credentialscontent-storagecontent-primitives
Stitched
  • a database
  • a field-encryption library
  • a KMS
  • a consent-management platform
You configure: a PII schema; a key per tenant; consent flags disconnected from the code path that reads the field; a DSAR process.
The seam: Consent is a flag; access is a query. Nothing makes the second depend on the first.
On the substrate

Vaults are the record: encrypted envelopes with per-record scope, released only under a delegation the owner signed; the KB holds only what the chain already says.

Organizations, relationships, coordination
organizationagent-relationshipsrelated-agentssituationscoordinationcollaborationgeo-featuresAgentRelationship.solRelationshipTypeRegistry.solAgenticGovernance.solGeoFeatureRegistry.sol
Stitched
  • an org / team model in your DB
  • a project tool (Linear · Jira)
  • a workflow engine (Temporal)
You configure: membership tables; roles per org; tasks with an assignee but no principal; workflows that cannot say under whose authority a step ran.
The seam: An organization is a tenant id. A relationship is a foreign key. Neither can sign, hold funds or be verified by a counterparty.
On the substrate

Organizations are Smart Agents; relationships and roles are on-chain records and vault situations; coordination plans are signed and adopted by decision.

Naming, registry and discovery
agent-namingregistry-kitregistry-resolutionagent-resolutionidentity-directoryidentity-directory-adapterscapability-claimsAgentNameRegistry.solAgentNameUniversalResolver.solAgentNameAttributeResolver.solPermissionlessSubregistry.solAgentProfileResolver.solAgentRegistryBase.solSkillDefinitionRegistry.sol
Stitched
  • ENS or DNS
  • an internal directory
  • a search index
  • an ERC-8004 registry
  • sync jobs between them
You configure: three name systems; a directory schema; an indexer you run; the mapping from name to address to card to endpoint, maintained by hand.
The seam: A name resolves to an address in one place and to an endpoint in another. Discovery is a search box over a table you own.
On the substrate

Typed names on chain (`.me .org .svc .treasury`); a registry kit with pluggable membership; discovery projected only from chain state; resolution grants that are never authority.

Domain vocabulary
ontologytypessurface-catalogOntologyTermRegistry.solShapeRegistry.sol
Stitched
  • — nothing. It lives in prompts, in tables, and in the heads of two engineers.
You configure: a system prompt per agent that explains the domain; app tables that encode it differently; a glossary in a wiki.
The seam: Three encodings of one fact, none checkable against the others. The one the resolver used was wrong.
On the substrate

One ontology, bound by IRI, checked at build. Vault records, Ask vocabulary, agent cards and playbooks are projections of it.

Chain access and operations
chain-statechain-state-viemcontractsap-kmsdevkitcreate-appevaluationSmartAgentPaymaster.solMultiSendCallOnly.sol
Stitched
  • an RPC provider
  • a block indexer
  • a secrets manager
  • CI you write for nightly checks
You configure: RPC keys per environment; an indexer schema; env vars in a dozen deploys; a service account per service that IS the service’s identity.
The seam: The service-account credential is the identity. Compromise it and you are that agent, for anything, until someone notices.
On the substrate

Typed chain reads with no log scans on hot paths; service keys as revocable delegates; live gates run nightly against the real estate; `ap doctor` and `ap conform`.