A financial history beyond one session.
Persistent agents need more than an address that can hold funds. They need to retain what they were authorized to do, what they have already spent, and which purchases remain unresolved.
Our design treats a model, a host and a key as changeable components. A continuing account should not erase its obligations when one of them changes. It also should not gain broader authority simply because it remembers its earlier work.
Start with a purpose, not a seed phrase.
The intended intake begins with the person’s objective: who is acting, what work they may purchase, with whom, for how much and until when. Consent should be understandable before it becomes executable.
“Raven and Atlas may spend up to 100 units together on these approved services. Neither may add another recipient or increase the limit. Ask me when the allowance is exhausted.”
This is product direction. The available browser experience is an illustration, not a production account-opening flow.
Keep the purchase, not just the transaction.
The local payment-job prototype binds a continuing task to one exact native payment intention. After interruption, an agent resumes the existing job rather than silently creating another transaction under a new counter.
A lost response remains unresolved until specific evidence can be checked. Read-only recovery cannot sign or resend money. These protections depend on participants sharing the same local workspace and task identity; they are not global deduplication.
Separate a relationship from permission.
Ending a relationship, stopping new spending, replacing a key and exporting a history are different actions. They should be separate, clearly described controls.
The native prototype retains historical spending when permissions are revoked or superseded. A native key change does not cancel a previously accepted external card authorization.
Useful beyond one agent runtime.
Eternities is developing persistent-agent systems, but the intended interfaces should not require an Eternities agent. An outside runtime should eventually be able to request bounded authority, submit an approved intention and verify the result.
Interoperability with agent-payment standards and other payment instruments is a proposed integration track. No production SDK, card program, issuer relationship or universal agent compatibility is claimed.