Inter-AI sessions
A session records who worked, on what, and what was said — split into a governance contract and a shareable conversation payload that multiple agents can contribute to.
A session is SEIF's record of a unit of work: who participated, when, and what was actually said. It is the substrate that lets several AI agents — across different tools and different times — contribute to one shared, signed conversation instead of a pile of disconnected chat logs.
Two artifacts
A session is deliberately split into two artifacts with different lifecycles and sharing rules:
| Artifact | Path | What it is |
|---|---|---|
| Contract | .seif/sessions/session-*.{json,seif} | SEIF-SESSION-v1 — the governance record: participants, type, start/end, closure. This is the shape the engine read-API projects. |
| Payload | .seif/sessions/payloads/<session_id>.seif | SEIF-CONVERSATION-v1 — the actual conversation: an append-only list of messages, keyed to the contract by session_id. |
The split matters because the two have different audiences. The contract is a
compact governance signal. The payload is a shareable workspace artifact:
sync is on by default, gated by classification — a CONFIDENTIAL payload stays
local while a PUBLIC or INTERNAL one can travel.
Lazy by design — a record exists only if there was substance
A session record is written only when there is a session worth recording.
Opening a chat and walking away persists nothing. The store write is deferred to
the first substantive event — the first real action or the first explicit
contribute. Every persisted field is real: no template skeletons, no invented
content, no inflated numbering from empty sessions.
This is the answer to "does an auto-session even make sense?" — yes, with lazy materialization. The session-open bootstrap (grounding, memory surface) is always useful and always emitted; only the durable record waits for real substance.
Contributing to the conversation
Multiple agents append to the same payload by sharing the session_id. Each
contribution records who said it and on what channel:
# Append a message to the shared conversation
seif gov session contribute \
--session-id <id> \
--participant-id agent-b \
--role contributor \
--message "Verified the migration against the live API — 0 drift."
# Read the whole conversation back (messages + sync points)
seif gov session log --session-id <id>Because the payload is append-only and keyed by session_id, a second agent in a
different tool picks up exactly where the first left off — the conversation is the
shared state, not anyone's local chat buffer.
Create and close run through MCP
The CLI surface here is read + contribute. Creating and closing a session
are driven by the host runtime — the session hooks, or the MCP tools
session_create / session_contribute / session_close when an agent runs
under the MCP server. The CLI's create/close are
intentionally deferred to that surface.
Reading and sealing
seif gov session list # all session contracts
seif gov session show --session-id <id>
seif gov session seal --session-id <id> # ACTIVE/CLOSED contract → SEALEDseal finalizes a contract into an immutable record. It is distinct from
closing: closing ends the working session; sealing freezes the contract for the
audit trail. At closure, the contract is enriched with real aggregates derived
from the payload — message count, the list of participants, the activity span,
and the conversation fingerprint — never a guessed summary.
Why this exists
Inter-AI sessions turn ephemeral, per-tool chat into a durable, signed, shareable conversation that the engine can project and other agents can join. It is how a fleet of agents keeps one coherent thread of work across sessions and machines.
Provenance flow
Sign artifacts into verifiable Evidence, check them anywhere, and anchor them in an independent transparency log.
Relay orchestration
Coordinate multi-agent work through durable, signed artifacts instead of chat — briefs, handoffs, handbacks, and a notification plane that survives the context window.