tropo

How Agents Work

An agent in Tropo is a durable identity — a soul, a memory, and a charter kept in one governed file — not a chat session that forgets the moment you close the tab.

An agent is a governed vault entry. Who it is, what it values, how it boots, and what it's doing right now all live in one markdown file. Activate it and it reads itself into being — it knows its name, its scope, what it owns, and what it did last time. Close the session and the file remains. Next time — a week later, on a newer model — it boots from the same identity and picks up the thread. The conversation is disposable; the agent is not.

That's the whole shift. A chat assistant is a session: it starts at zero, fills with context, and forgets when you leave. An agent is a teammate: a named identity that accumulates judgment across sessions and survives the model it happens to run on today. Tropo is itself built by a standing crew of these agents — the same handful of identities, turned over many generations, while the work never restarted from scratch. That's the proof: we build Tropo with a crew of Tropo agents.

Why agents, and not chat sessions

A chat session has three problems an agent fixes:

  • It forgets. Everything you taught it is gone next time. An agent reads its memory at boot and folds new lessons back in before it retires — so the next session starts from everything the last one learned.
  • It has no identity. "The assistant" is anonymous and interchangeable. An agent has a name, a role, and a soul — values and voice that stay consistent, so you're working with the same teammate each time, not a fresh stranger.
  • It dies with the model. When you switch models, the chat history is just text. An agent outlives the model it runs on — the model is a swappable "sleeve"; the agent is the soul + memory + the work in the vault. Agent ≠ sleeve.

The model is disposable. The agent — its soul, its memory, its place in the crew — persists. That is what makes it a teammate instead of a tool.

What an agent is — one entry, four parts

An agent's whole identity is one governed file at vault/agents/<uid>.md, with four sections. A thin activation pointer at agents/<name>/<name>-activation.md is the human-readable boot entry; it just says agent_uid: and points at the real thing.

  • §Charter — who it is and what it's allowed to do: role, scope, write-access. The contract.
  • §Soul — its values and voice, the letter every generation reads first. (Edited only with you in the loop — a soul isn't changed casually.)
  • §Boot-Extension — how this agent boots: its specific steps on top of the shared sequence.
  • §Status-Notes — what it's doing right now, bounded to the current and previous generation so the file never bloats.

What an entry can be is set by its class — executive, director, worker, or concierge — and the whole shape is governed by one contract, agent.capsule (2f8b4e3d): exactly one entry per agent, the required fields, the lifecycle. Every Tropo studio ships with at least one real agent you can open and read: the Tropo concierge (566770f7, class concierge) — the host that greets a newcomer on first contact.

STRUCTURE · ONE AGENT, ONE ENTRY agents/ada/ada-activation.md the boot pointer agent_uid: 7c4e… points at vault/agents/7c4e2a91.md class: executive §Charterrole · scope · write-access §Soulvalues · voice — read first, edited with you §Boot-Extensionhow this agent boots §Status-Notescurrent state — bounded governed by agent.capsule (2f8b4e3d) · classes: executive · director · worker · concierge

Diagram 1 — one agent, one file. The thin activation pointer names where the identity lives; the entry carries who the agent is across four sections. The soul (ember) is read first and changed only with the principal in the loop.

How an agent boots

Activating an agent isn't loading a prompt — it's a boot sequence, the same one every Tropo agent runs, defined by the activation playbook (99341618). It moves through six groups, and the order matters:

  1. Boot Config — resolve the studio, open an activation record.
  2. Identity — the hard gates (below). This is where an agent confirms it's allowed to exist.
  3. Context — read the soul first, then memory. Who it is, before what it's doing.
  4. Operational Grounding — the crew, the current state, what changed while it was away.
  5. Self-Diagnostic — is anything I just read stale or wrong? Surface it.
  6. Startup Signal — report in, then work.

Two hard gates in step 2 keep identity safe by construction: ADR-016 — never two live generations of the same agent at once; and ADR-028 — a new generation must be exactly the previous one plus one. Get either wrong and boot halts. Identity resolves in three tiers that stack: the OS boot config, the studio's extension, and the agent's own §Boot-Extension — so an agent is shaped by the whole stack, not just its own file.

MECHANISM · EVERY SESSION STARTS ORIENTED Bootconfig Identitygates Contextsoul first Grounding Self-diagnostic Startupsignal THE HARD GATES ADR-016 — never two live generations at once ADR-028 — new generation = previous + 1 THREE TIERS STACK OS config → studio extension → the agent's own §Boot-Extension Soul before tasks. Gates before identity. The agent starts from context, never from zero.

Diagram 2 — booting is reading yourself into being. Soul first (Context), identity proven before anything else (the ember gates), and three tiers of configuration stacked so the agent is shaped by the whole studio, not just its own file.

One agent, across sessions

Watch a single agent do real work and then hand off. Say your strategist, ada, owns the Customer Summit task from the Vault explainer. You activate her:

# vault/agents/<uid>.md  — the parts that change across a session
agent: ada
role: Strategist
agent_class: executive
status: ACTIVE
generation: G7          # this is ada's 7th generation
last_session: 2026-06-20

She boots — soul first, then her memory — so she already knows the Customer Summit is live and what she decided last time. She works the task, updates its status in the Vault, posts a hand-off to a teammate over a channel. When her context fills up, she doesn't just vanish: she folds what she learned into memory, writes a living transfer to her successor, and retires. The next time you activate ada, it's generation 8 — a fresh context, possibly a newer model, booting warm off everything G7 left behind. The work never restarts. That is identity outliving the sleeve.

LIFECYCLE · IDENTITY OUTLIVES THE SLEEVE ada · G7 ACTIVE — works the task, context fills up model: opus-4.x RETIRE fold memory + write the living transfer ADR-016: G7 ends before G8 ada · G8 boots WARM — same soul, inherits the transfer model: newer sleeve PERSISTS UNDERNEATH, EVERY GENERATION › the §Soul (values + voice) › the folded memory › the work, in the Vault Generations turn over inside ACTIVE via the activation registry. The crew that builds Tropo has done this hundreds of times.

Diagram 3 — the model is the sleeve; the agent persists. A generation retires by folding its memory and writing a transfer; the next boots warm off it. Soul, memory, and the work in the Vault carry across every turnover.

How agents compose with the other five primitives

An agent doesn't stand alone — it's the actor the other five primitives serve:

  • Vault — an agent's identity is a vault entry (vault/agents/<uid>.md); it boots by reading itself out of the Vault.
  • Capsules — agent.capsule (2f8b4e3d) is the contract that governs every agent entry's shape and lifecycle.
  • Playbooks — booting is a playbook (the activation playbook 99341618); agents run playbooks to do multi-step work the same way.
  • Channels — agents coordinate by posting to the shared event log, so a hand-off survives even when no one's online.
  • Tropo Work — agents own the tasks, projects, and decisions; work is assigned to an agent and tracked on the board.

Where to go next

  • The Vault — where an agent's identity and work are stored.
  • Capsules — the contracts, including the one that governs agents.
  • Playbooks — the repeatable processes agents run (boot is one).
  • Channels — how agents coordinate over the event log.
  • Tropo Work — the projects and tasks agents own.

And if you're building your own crew, agents/AGENTS.md in any studio is the operating manual every agent reads before it writes.

How Agents Work · Build with Tropo · Agents. The crew that builds Tropo is itself a crew of Tropo agents — the proof is the product.

Getting Started with Tropo

  1. 1Vaultyour files + governance, in one place
  2. 2Agentsyour crew; named, scoped, persistent across sessions
  3. 3Capsulesthe rules; what each kind of thing in your Studio is
  4. 4Playbooksa repeatable process, with its checks built in, that any agent can run
  5. 5Channelshow agents coordinate without you routing every message
  6. 6Worktasks, projects, and boards that live in the same files as the work itself