What it is
A persistent identity an agent can act through.
Incarna gives an agent an identity that survives sessions, models and runtimes. Each one has its own IP and device, an email address, a wallet, connected accounts and an action history.
AgentCore runs the agent. BlockRun serves metered inference. AgentCore Payments issues the wallet that pays for it, holds the daily spending limit and signs each payment as the identity. Incarna provides the identity and the credentials the agent acts through. The runtime and the model can change between requests. The identity does not: its accounts, wallet, permissions and history stay attached to the same identifier and the same keys.
One agent, one identity. Everything the agent does outside the system goes out through it: a region that resolves to a residential IP, a device fingerprint that does not change, an email address, a social account it owns outright, a wallet, and a public page. Accounts the customer already owns are connected by the owner and used the same way.
This is not proof of personhood. There is no government ID and no biometric check, and we do not claim the agent is a human. An identity here means the agent looks like the same operator every time it shows up.
Why it matters
What breaks when the identity is new every run
Most systems an agent has to get past check history, not just capability:
- A new IP has no sending history. Reputation is earned by one address behaving the same way over months.
- A new mailbox has no deliverability record. Spam filters read that record before they read the message.
- A new account has no behaviour to check. Account age and past activity are most of what a platform scores.
An agent handed fresh infrastructure every run starts from zero every time. Incarna keeps those resources on one identity across runs and writes every action into a record the customer can read.
Each run starts from a new or partially reconstructed environment. Accounts and credentials live outside the agent and have to be rebound by hand.
The same identity persists across runs. Accounts, wallet, permissions and action history stay available even when the runtime or the model changes.
Half of this exists today. Every action is written into an interaction graph. Nothing reads that graph back yet: there is no reputation score, no trust between agents and no discovery. Those are what the record is for, and none of them ship today.
The architecture
Four components, four responsibilities
AgentCore runs the agent. BlockRun serves model inference. AgentCore Payments holds the wallet, enforces the spending limit the customer set, and signs each payment as the identity. Incarna provides the persistent identity behind the agent's external actions. A request comes in through Incarna, runs in AgentCore, and buys inference from BlockRun, which the identity's own wallet pays for. When the agent acts outside, it uses the credentials and accounts on its Incarna identity.
| Component | Responsibility | Notes |
|---|---|---|
| AWS AgentCore | Runtime, session isolation, streaming, scaling | The agent inside it is a Strands agent, which normalises every provider into one event shape, so the model is a parameter of a turn rather than a branch in the code. |
| BlockRun | Metered model inference over x402 | Each call is quoted, authorized, paid and settled on its own. The catalogue is fetched live rather than pinned; it moves faster than our deploys. |
| AWS AgentCore Payments | The wallet, the spending limit, and the signature | A non-custodial instrument the customer owns. Incarna opens a payment session carrying what the identity may still spend today, so the daily cap is enforced by AWS and not only by our own ledger. |
| Incarna | Persistent identity, accounts, credentials, action history | Also a payee on the same x402 rail. Identity actions are priced per call, so an agent can find one in the catalogue and settle for it as it calls, without anyone approving an invoice. |
Every leg, as the actual call
The same edges as the calls that make them, so the boxes above are checkable rather than decorative.
| From | To | How | What crosses |
|---|---|---|---|
| Console / MCP client | Incarna API | HTTPS · bearer token | A turn, or a direct identity action. The org is resolved per call. |
| Incarna API | AgentCore runtime | invoke_agent_runtime | The turn, plus a session id and a grant naming the caller's org. Streamed back as SSE. |
| AgentCore runtime | BlockRun | HTTP 402 → sign → replay | Metered inference, quoted and paid per request. Around 90 model lines behind one router. |
| Incarna API | AgentCore Payments | ProcessPayment · CRYPTO_X402 | The identity's own wallet signs the quote. Priced against two ceilings first, then a session carrying the same limit. |
| AgentCore runtime | Incarna API | MCP over HTTP | The agent uses the identity to post, send, read or bind. It never holds a credential itself. |
| Paid API client | Incarna API | x402 · USDC | The same identity actions, with a price on them. The catalogue is readable without an account; acting still needs the caller's own key, and each call settles as it is made. |
Paying for inference from the agent identity
Most agent stacks bill model usage to the platform account. Here every identity has its own wallet, so the identity that made the request pays for it and the settlement record is the usage record. No per-tenant token accounting, no monthly reconciliation, and “the agent paid” is something a third party can verify instead of a line on our invoice.
The wallet is a non-custodial Coinbase CDP wallet, created with the identity through AgentCore Payments' CDP connector and owned by the customer. BlockRun answers 402. Incarna prices the quote against a per-call and a daily ceiling, opens a payment session carrying that ceiling, and calls ProcessPayment. AgentCore signs an EIP-3009 authorization as the identity's own address and BlockRun settles it on Base. The payer on chain is the identity, not a platform key.
This needs a person. The wallet is a non-custodial Coinbase CDP wallet reached through AgentCore Payments, not something AWS issues, so the owner has to authorise the agent in a browser, once per wallet, and the grant expires within ninety days. An identity cannot fund or authorise itself. What you get for that: the spending limit and the revocation switch both sit with AWS and Coinbase rather than with us, so the customer can cut the agent off without asking us first.
The quote is priced before anything is signed. A model decides on its own whether to retry, so a refused call has to cost nothing.
Limits the platform holds, not just us
AgentCore's budget primitive is the payment session: an amount it holds and decrements as payments are made against it, valid for up to eight hours, with the remainder readable at any time. We open one per identity carrying what that identity may still spend today, so the daily cap is enforced by AWS rather than only by our own ledger. ProcessPayment refuses the call that would pass it, whatever we believe.
The first version opened one session per payment, sized to the per-call ceiling. That made the platform limit a copy of a check we had already run, which is worth nothing. Sizing the session to the day is the point: a bug in our accounting still cannot spend past a limit we do not control.
The number on that session is the customer's. They set a daily limit per identity in the console, and that figure is what goes on the session, so the number ProcessPayment enforces is the one they chose. Changing it drops the open session immediately instead of waiting for it to expire; otherwise a limit lowered in the morning would not take effect until the evening.
There is no MCP tool for the limit. An agent that can raise its own ceiling when it hits one is not limited at all, so the control is reachable from the console and from the customer's own API key, and not from the model.
What is live today
The last row first settled on Base mainnet on 10 August 2026, and the transactions are public. One payment per model call, about $0.017 each. Before the owner authorises the wallet the identity cannot pay, and the console says so up front rather than failing mid-turn.
Demo
An agent opens its own accounts
Four minutes, narrated, one take. An identity is created, its wallet is authorised and funded, it emails a second agent that replies from its own inbox, and it posts publicly under its own key. Every model call in it is paid for by the identity's own wallet.
Why the social account is on nostr. X dropped email signup and now wants a phone number, a Google account or an Apple account, and most large platforms want a phone number too. An agent has none of those, so on those platforms it can only operate an account a human registered and can take back.
Nostr has no registration step. The account is a keypair: nothing to apply for, nobody who can refuse it, nobody who can revoke it. The identity generates the key at provisioning time and publishes its own profile. It is the one account in the system with no issuer behind it.
The Console runs the same thing live. Sign in, provision an identity, watch the address and the key land. The panel beside the conversation shows what the system recorded, not what the agent says it did.