Actors and trust

Why this matters

In an agentic world, "an action happened" is not enough. You need to know:

• was it a human?
• was it an agent?
• whose authority did it use?
• where is the record?
• who is responsible for attribution?

This is one of the reasons timelines are central to Blue.

The actor model

Every timeline entry carries an actor field whose type tells you what kind of actor it is. The base actor types in repo.blue:

• Conversation/Principal Actor — a participant acting directly under their own identity.
• Conversation/Agent Actor — an automated agent acting on behalf of a principal. Carries an onBehalfOf reference identifying the principal that delegated the authority.

Documents may apply different rules depending on the actor type — for example, "a payment can only be approved by a principal, not an agent" or "an agent may propose, but only a principal may accept."

Source / origin

In addition to the actor type, each entry has an origin — where it came from. Common origins:

• Browser — a person clicking a button in a UI.
• API — a service or agent calling the provider directly.
• Document request — another document triggered this entry as a side effect.
• Provider-specific mechanism — for example, a bank's settlement event arriving through its own pipeline.

Origin is not part of the bare base type; it is a property attached by the timeline provider during attribution. Document policies that care about origin (for example, requiring a browser-based principal action for a high-value approval) read it from the entry as delivered by the provider.

Three example flows

1. Human via browser

Alice clicks "Accept" in her shop UI. The provider creates an entry whose actor is a Principal Actor with Alice's account id, origin browser. The order document accepts the operation because its rule on acceptOrder allows the seller's principal.

2. Agent via API

Bob's OpenClaw agent posts a Propose Payment request through the API. The provider creates an entry whose actor is an Agent Actor with onBehalfOf: bob, origin API. The mandate document validates the proposal against its constraints and decides whether to allow it.

3. Document-triggered request under delegated authority

The PayNote, on receiving a delivery confirmation, requests completePayment on the bank's timeline. The bank's provider records the request with origin document request, attributed under previously delegated authority from the relevant principal. The bank's rules then decide whether to perform settlement.

Documents are not actors

Timeline providers as trust anchors

A processor does not inspect the internals of an LLM to know whether an agent acted safely. Instead, it trusts the timeline provider to say:

• who owns this timeline
• whether this was a principal or an agent action
• whether the entry is real and permanent
• how the action was attributed

This is practical trust, not philosophical trust.

Trust is distributed

Part of trust comes from:

• the timeline provider
• the participant's real-world role
• the document rules
• the other participants in the interaction

Examples:

• a bank is trusted to act as guarantor
• a courier is trusted to confirm delivery
• a verifier is trusted to inspect the product
• an owner is trusted to define a mandate
• a timeline provider is trusted to attribute the actor correctly

Blue makes all of this explicit.

Why this is good for agents

Blue does not say: trust the agent.

It says: trust the structure the agent operates in.

That structure includes:

• identity attribution
• permanent record
• bounded actions
• explicit participants
• deterministic processing