Data and trust
You do not need to know how the platform is built to ship on it. You do need a model of where your code runs, where data lives, and what has to be true for the two to meet. This page is that model.
Data classes
| Class | Examples | Where it lives | Owner |
|---|---|---|---|
| Vault data | Events and objects in a scope | The customer’s vault, backed by a storage bucket their wallet owns | The vault owner |
| Memory Bank | Records and relations, each privacy-classified | The customer’s vault | The vault owner |
| Connector secrets | Bot tokens, SMTP passwords, API keys | Sealed in the customer’s vault; never returned, not to people and not to agents | The vault owner |
| Cubbies | Your service’s working tables | One database per vault, service, and alias | Stored in the vault; schema declared by your service |
| Agent code | Bundles, manifests, widgets | Your Agent Service’s storage bucket, content-addressed; each version is immutable | You |
| Agreements | Signed consent between a vault owner and your service | The agreement registry | Signed by the vault owner |
| Run records | Jobs, Tasks, task logs, usage | The platform | Attributed to the run’s agent and initiator |
Connection settings are not kept on run records. The platform reads them from
the vault when a Task runs and hands them to your code as ctx.settings.
Where to put something:
- Working state your service needs next time: a cubby.
- A conclusion the customer should keep and see, with a visibility class: the Memory Bank.
- A file: an object in a scope (
ctx.vault.objects, orscope.objectsin the Vault SDK). - A credential for an outside system: a vault connector, never your bundle.
Nothing survives in an isolate’s memory between events.
How data reaches your code
- You publish an agent or workflow to your Agent Service’s bucket and deploy a version.
- The owner connects it, signing an agreement for named scopes. The vault pins the bundle they consented to.
- Data arrives in a scope: from your app, a widget, a connector, a schedule, a webhook, another agent, or a person. See Data onboarding.
- An event dispatches to every active connection on that scope, opening or advancing a Job.
- Your code runs with an execution token scoped to that vault, scope, and
run. It reaches the vault only through
ctx(or the workflow runner’s steps). - Results land back in the vault.
What proves each crossing
| Crossing | Proof |
|---|---|
| Owner or member → vault | Wallet signature over the canonicalized request (X-Public-Key, X-Signature), or a scoped delegation token |
| Owner → agreement registry | Wallet signature on the agreement |
| You → your Agent Service’s bucket | The bucket owner’s key, or an access token the owner granted |
| Running agent → vault | A per-task execution token, short-lived and bound to the connection |
| Running agent → outside system | A connector action, using the secret sealed in the vault |
Your code never signs as the customer. It runs inside a Task the platform
already authorized against the agreement, which is why nothing in ctx asks for
a credential, and why nothing in your code can widen what a run may touch.
The invariant
The customer’s data and consent do not depend on your app. The bytes live in storage the customer’s wallet owns; the agreements are records their wallet signed. Switching agents, or switching away from yours, is a permission change, not a data migration: nothing has to move, because your service was never the source of truth for the customer’s data.