Session brief and peer radar

Every new agent session starts without memory of the last one. Instead of re-explaining where you were, the agent can ask the knowledge base. The answer is derived from facts the engine already keeps — your transactions and the server-side entity history — not from a separate log that could drift out of date.

Hosted only. The session brief, entity reservations and check_notifications are part of the hosted service. Liveness and the peer radar need a multi-actor workspace (Team or Enterprise). A self-hosted Platform ignores include_brief and answers a plain whoami, so skills that ask for a brief keep working there — they just get none.

The session brief

whoami({ include_brief: true, max_events: 20, since: "2026-10-01T00:00:00Z" })

Without include_brief the response is the usual identity. With it, the response gains a brief object for you, the caller:

• open_txns — your transactions still in progress, with their type, trigger, start time and recovery notes: the "where did I stop" cursor;
• recent_activity — your latest entity edits (entity id, version before and after, change summary, trigger, date), capped by max_events and bounded by since, with a truncated flag when there is more.

The brief is pull-only and read-only: asking for it never changes anything. The Skills read it at session start when it is present.

Liveness and the peer radar (Team and Enterprise)

In a multi-actor workspace the brief also carries your own liveness — a "last seen" indicator derived from your most recent activity (active, idle, or older), not an online/offline signal. Add radar: true for the peer radar:

whoami({ include_brief: true, radar: true })
whoami({ include_brief: true, radar: true, radar_all_actors: true })   // owner / admin

• By default the radar covers your neighbourhood: other writer-units with in-progress transactions on, or recent edits to, the entities you touched and their direct neighbours.
• radar_all_actors: true spans the whole workspace. It takes effect only for roles allowed to see every in-progress transaction (owner, admin); for anyone else it silently falls back to the neighbourhood instead of failing.
• The radar never crosses workspaces, and descriptions of what a peer is doing are computed on demand from the facts, never stored.

Visibility follows roles

The brief and the radar show only what your role may see. You always see your own transactions. Roles without workspace-wide transaction visibility — a viewer, for example — do not see other actors' in-progress transactions or their drafts: the radar gives such a caller the count of nearby peer transactions, not their detail.

Pulling changes: check_notifications

When you read an entity you intend to change, you can reserve it: entity_get with intent: "soft-announce" (a cooperative, non-blocking announcement) or intent: "hard-lock" (exclusive: other writers get 409 LOCKED until it is released). Both need an agent_instance_id.

check_notifications({ agent_instance_id: "<your-agent-instance>", max_events: 50 })

check_notifications then returns what other writer-units changed on the entities you reserved since your last check (your own changes are excluded), plus the open notices in your dispute inbox. There is no push: the transport is pull-only, so call it at session start and before you write. It is read-only and never blocks a write — the hard guarantee against lost updates is still the expected_version check described in Concurrent writers.