tropo

How Tropo Work Works

Tropo Work is the work-management surface built into every Tropo studio — projects, tasks, decisions, and pipelines, tracked together in plain markdown, that you and your agents run day to day.

This is the headline application: the place where the work actually lives. It's not a separate app bolted on top of the Vault — it's four typed primitives composing into a board you and your agents share. Tasks move through states, projects roll up from their tasks, decisions record the calls you made, and pipelines capture the workflows you repeat. All of it is plain markdown in the Vault, so the same work surface a person reads is the one an agent operates.

The four primitives

Tropo Work is built from four types, each governed by its own capsule and each with its own lifecycle:

  • Project — a container with a name, a purpose, and a board. It owns work. Its stage: moves ideate → build → done (with cancelled as the early-out).
  • Task — a unit of work that lives member_of: a project. Its status: moves new → accepted → active → closed, and on close it records a resolution: (done / rejected / cancelled).
  • Decision — a recorded choice: what was decided, why, what else was considered. design → done; a superseded decision stays done but flips to state: archived.
  • Pipeline — a repeatable workflow that defines the stages a project moves through (e.g. specify → build → ship). draft → active → locked → archived.
STRUCTURE · FOUR TYPED PRIMITIVES projecta container that owns work stage:ideate → build → done taska unit of work, member_of a project status:new → accepted → active → closed decisiona recorded choice + its reasoning status:design → done pipelinea repeatable workflow of stages status:draft → active → locked → archived

Diagram 1 — four primitives, four lifecycles. Each is a governed type with its own state machine — there's no universal lifecycle. The ember state is the one that means "this is where the work pays off."

How they compose

The primitives aren't separate lists — they form one graph. Tasks belong to a project (member_of: [project-uid]). Decisions hang off a project or stand alone. A pipeline defines the stages a project flows through. And their state machines compose: a project sits at stage: build while its tasks are open, and only when every task is closed with resolution: done can the project move to stage: done. High-level status stays honest because it's computed from the work underneath.

COMPOSITION · THE PROJECT ROLLS UP Customer Summit project · stage: build tasksmember_of the project decisionsthe calls, recorded pipelinethe stages it follows A project is done only when its tasks are — the state machines roll up, so the board never lies.

Diagram 2 — the project rolls up from its parts. Tasks belong to it, decisions record its calls, a pipeline shapes its stages — and the project can't reach done until its tasks do. Status is computed from the work, not asserted.

A working day — the Customer Summit project

Here's the shape of operating inside it. You start a project — "I want a project for the Customer Summit" — and your agent creates the entry and seeds the first task. You add work by saying what you want — "add a task to send the save-the-date to our top 50 accounts" — and the agent authors it member_of the project. As work happens, the agent moves tasks across the board (new → accepted → active → closed). When a real call gets made — "let's send a week earlier this year" — you record it as a decision, so six months from now the reasoning is right there. And when you notice you run the same sequence every quarter, you capture it as a pipeline so the next event plugs straight in.

THE BOARD · CUSTOMER SUMMIT 2026 · stage: build NEW ACCEPTED ACTIVE CLOSED book the venueowner: ada send the save-the-dateowner: ada lock date + venueresolution: done draft the agendaowner: lex The board is just the project's tasks, grouped by status — a view of governed files, not a separate database.

Diagram 3 — the board is a view, not a place. Each card is a task file member_of the project; the columns are just status:. Open the project's UID file and you're looking at the same board your agents operate.

Continuity — the work outlives the session

The reason this holds together: the work lives in files, not in an agent's memory. When an agent boots, it reads its own active work, the boards for projects it owns, and the index (vault/00-index.jsonl) to filter open tasks — and it drains the event log to see what landed since last time. New session, same context. The same property lets different agents share a project: an analyst, a writer, and a reviewer all read the same board, and their coordination is auditable. Six months later, "why did we decide X?" is answered by opening the decision file. No archaeology.

To see what's happening at any moment: open a project's UID file for its board, query vault/00-index.jsonl for everything open by owner, or just ask your agent "what's open right now?" — it reads the index and tells you. This public studio ships with real projects you can open and read — e.g. 1a17e001 ("Lantern — Monthly Newsletter Planning").

How Tropo Work composes with the other five primitives

  • Vault — every project, task, decision, and pipeline is a governed Vault entry; the board is a view of the index.
  • Capsules — each primitive is a capsule type (project.capsule 34e4cb0b, task.capsule 3289712a, decision.capsule 179d74e9, pipeline.capsule e4c8a6b2).
  • Agents — agents own projects and operate the board; work is assigned to an agent.
  • Playbooks — a pipeline is a playbook subtype that drives a project's stages; start-a-project is the playbook that opens one.
  • Channels — every change (a task accepted, a decision closed) emits an event, so the work's history and its coordination are the same trail.

Where to go next

  • The Vault — where all the work entries live and are indexed.
  • Capsules — the contracts behind project, task, decision, and pipeline.
  • Agents — who own projects and run the board.
  • Playbooks — including pipelines, the workflow subtype.
  • Channels — the event log that records every change.

And the source of truth for any primitive is its capsule: open .tropo/capsules/project.capsule.md (or task, decision, pipeline) to read the contract.

How Tropo Work Works · Build with Tropo · Tropo Work. The headline application: four typed primitives, one board, all plain markdown you own.

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