Describe
The profile explains what an agent is good at. A proposed manifest identifies its publisher, bundle, runtime needs, capabilities, and evaluation evidence.
Manifest design proposed Context, work, and control
Useful agents.
On your terms.
Operanda connects a private Vault to clearly defined jobs and bounded agent runtimes. You choose the context, set the scope, and review the result.
One explicit path from context to workArchitecture overview
Your VaultSelected records
Job specIntent + boundaries
Agent runtimeBounded assignment
Your reviewAccept the result
Coordinator
Relays ciphertext and work metadata. Holds no content keys and invokes no models.
Current implementation: a synthetic local alpha. This page explains the design; its examples do not run agents or access a Vault.
02 / The Vault
Context with boundaries.
The Vault Agent is the trusted part of Operanda. It authorizes access, opens selected records, and seals results. An agent gets a bounded assignment.
Choose what a job can use.
Memories, preferences, work specs, and results are versioned records. A job pins the exact revisions it uses, so later changes require fresh authorization.
- Selective context
- Read permission alone doesn’t select a record for a job.
- Private stays private
- A shared output cannot consume a private input.
- Traceable results
- Results retain input revisions and runtime provenance.
What can this job see?
Synthetic exampleSelect context for a three-day meal plan.
2 records selected · private result
This selection respects the example’s space boundary. Other execution checks still apply.
Illustrates one authorization rule. All controls stay in this page; nothing is saved or sent.
What “private” means in the current alpha
The coordinator stores encrypted content and visible metadata, including record IDs, timing, and work state. The trusted Vault Agent can decrypt. Both fixture users currently trust one Mac administrator, who can access their keys and plaintext while the node is unlocked. Independent household custody and owner recovery remain open work.
03 / The job spec
Give the agent a clear brief.
A useful job says what to do, which context to use, where the result belongs, and how it will be reviewed. Runtime selection and permissions must be enforced by code.
More than a prompt.
The goal describes the work. The surrounding contract constrains it.
- IntentA concrete goal and expected deliverable.
- InputsExplicitly selected, authorized record revisions.
- ExecutionA pinned runtime and immutable bundle digest.
- Result + reviewAn allowed output space and separate owner acceptance.
These are conceptual groups. The example wire request uses the existing alpha contract; the Vault adds execution references when drafting.
Example job
DraftA simple meal plan
- Goal
- Plan three vegetarian dinners, each taking under 30 minutes.
- Selected context
- Food preferences rev 3
Kitchen equipment rev 2 - Deliverable
- Three recipes and one combined shopping list.
- Result destination
- Owner’s private space.
- Execution boundary
- Text generation only. No purchases, messages, or external actions.
- Review
- The owner reviews and accepts the proposed result.
A fixed, independent example. The context demo above does not edit this brief.
Illustrative work.draft body for coz-local-alpha/0.1. Fixture IDs must exist in an authorized snapshot.
{
"op": "work.draft",
"space_id": "10000000-0000-4000-8000-000000000001",
"title": "A simple meal plan",
"prompt": "Plan three vegetarian dinners, each under 30 minutes. Return recipes and one shopping list. Do not purchase anything.",
"context_record_ids": [
"20000000-0000-4000-8000-000000000001",
"20000000-0000-4000-8000-000000000002"
]
}At draft, the Vault resolves these record IDs to exact revisions and pins the admitted runtime. Activation and execution recheck authorization. The request travels inside a signed, encrypted envelope.
04 / Agents
Capability isn’t permission.
An agent profile describes suitability. Operanda must independently decide whether a particular runtime may perform a particular job.
Admit
Admission checks identity, policy, inputs, and the allowed runtime. Future package admission also needs verified signatures, revocation, and tested isolation.
Fixture admission existsConstrain
The harness receives selected context and output limits. It must not import Vault state, open its database, or receive reusable credentials.
General containment pendingMatching can rank. It cannot authorize.
An optional scorer may rank eligible candidates or abstain. A higher score cannot expand data access, add tools, change a budget, or approve a remote processor.
Coz
The interface for intent, context selection, and review.
Operanda
The trusted Vault and work coordination system.
OWP
The contract effort for interoperable work and authority.
Agent runtime
The executor of a bounded assignment.
05 / From intent to result
A result is a proposal first.
Each handoff has an owner and a check. Completing a run and accepting its result are separate events.
- 1
Draft the job
The owner chooses a goal, inputs, and output space. The Vault pins input revisions and the runtime.
draft - 2
Activate and authorize
Recheck access and revision bindings before queueing. A changed input or revoked permission prevents stale work.
queued - 3
Run with a lease
The admitted harness receives bounded context. An increasing fence prevents a stale or cancelled worker from committing.
running - 4
Seal the proposed result
The Vault validates output scope, seals the result, and retains its provenance. The owner can now inspect it.
waiting_dependency - 5
Accept explicitly
Only the owner accepts the result against the expected work revision. Accepting text does not authorize an external action.
completed
Wire states shown are specific to the local alpha. Work may also fail or be cancelled. Production waiting states and distributed coordination require further contract work.
06 / What’s built
The design, with its limits.
The local alpha demonstrates a narrow encrypted work loop using synthetic data. Production guarantees need their own evidence.
| Area | Current evidence | Next work |
|---|---|---|
| Vault & relay | AlphaEncrypted records, signed commands, selected revisions. | Owner recovery and durable private storage |
| Job lifecycle | AlphaAuthorization, leases, fences, and owner acceptance. | Encrypted phone-to-result flow |
| Agent execution | Bounded portsFixture and local-model harness interfaces. | Contained general-purpose runtime |
| Shared custody | OpenFixture principals share one trusted host administrator. | Independent household identity |
| Actions & payments | DisabledNo real effects or payment execution in the alpha. | Exact action approval and outcome reconciliation |
| Open contracts | In progressThe alpha has its own explicit profile. | Reconcile OWP and prove interoperability |
How this relates to the current Coz app
The primary Expo companion in this repository uses Hermes directly. Its local profile Vault is not the Operanda Vault Agent. The synthetic encrypted alpha is a separate implementation. Browser demos, profile storage, and successful fixtures do not establish production custody or native encryption guarantees.
Which job specification is shown here?
The code example uses the executable coz-local-alpha/0.1 contract. A newer unified job specification is still being reconciled with the current implementation. The proposed agent manifest and historical Coz 0.2 delta are not presented as adopted wire contracts.