Tropo Work — How Work and Agents Share the Same Substrate

Outside-in positioning for the killer app of Tropo.

What's missing from most agent setups

You have agents. They do tasks. The tasks live in chat threads, in scattered documents, in your head. Sessions end and the work evaporates.

Add a second agent. Now you have two contexts that don't share. You become the integration layer.

The thing missing is the substrate — a shared place where work persists, where multiple agents and you read and write the same files, where context survives the session that produced it. Not another tool. The substrate underneath the tools.

What Tropo Work is

Tropo Work is the substrate. Your work and your agents' work live in the same place, at the same time, under the same rules.

Concretely: every piece of work in your Studio — tasks, projects, decisions, briefs, notes, pipelines — is a markdown file with structured frontmatter. Your personal agent reads them. Other agents read them. You read them. They persist across sessions. They link to each other. They accumulate.

When you ask your agent to do something substantive, it doesn't just produce an answer. It captures the request as a note. It authors a task. It advances the work through whatever project owns it. When the session ends, the work didn't go with it — the work is in your vault, governed and navigable. The next session, by you or any agent, picks up where the last one left off.

Your work, with your agents, becomes a thing you can run a life on.

Work and agents share the substrate: human plus three agents — researcher, writer, engineer — all reading and writing the same vault of markdown files at the center

The primitives

Four primary types of work-items, each a markdown file:

Task — a unit of work with a status, an owner, and an outcome. From "draft the agenda" to "ship v2.0 release." Every task tracks who's accountable and what state it's in.
Project — a collection of work-items with a thesis. Projects are how you scope a domain — your consulting practice, your book, a single sprint. Projects nest; one project can be a member of another.
Pipeline — a structured workflow that produces typed artifacts in sequence. Pipelines are where governance lives — when you've done a piece of work enough times that the procedure matters, you write it as a pipeline and let an agent run it under your eye. A pipeline doesn't activate on a click; it activates on a typed spec — a capsule-formed work-order that names what THIS specific run will produce.
Capsule — typed instructions for the work-types themselves. The task capsule defines what a task is; the pipeline capsule defines what a pipeline is. Agents read capsules at runtime to know how to handle work of that type — which is how they execute substantive work independently: the rules live in the substrate, not in code or in a person's head.

Four primary types: Capsule at top in ember as the type-definer, with three downward 'defines' arrows to Task, Project, and Pipeline below; Task connects to Project via a 'member_of' edge

Pipelines activate on spec: dev-spec ignition activates dev-pipeline orchestrator with 6 internal steps; at step 4 the pipeline fans out to auto-author doc-spec plus test-spec which activate doc-pipeline and test-pipeline in parallel; both children converge back at step 5 (couple gateway) before step 6 ships the release

Plus a constellation of typed artifacts that surface around the primitives — design briefs, decisions (including ADRs), retrospectives, board snapshots, generation logs, releases. Every type carries its own validation rules, its own state machine, and its own role in the work.

Graph, not folders

The structural shift that makes everything else work: your work lives as a graph, not in a folder tree.

When you create a task, you don't navigate to the right folder. You declare the project it belongs to via a member_of: edge in the task's frontmatter. The Studio renders the structure from the edges. Refile a project — its references hold, because membership is edge-declared, not folder-derived. The structure is the graph; the filesystem path is rendering, not identity.

The implication compounds: an agent that asks "what's blocking this project?" is asking the graph, not browsing a folder. An agent that summarizes "what shipped this week" is following edges, not reading filenames. The substrate scales with use because the graph IS the structure, and the structure IS the graph.

Governance you can read

The other shift: every rule about how your agent behaves is a markdown file your agent reads and follows.

What its scope is. What it can write. How it coordinates with you. What it should escalate. When it should ask permission. When it should just act. All of it — markdown, frontmatter, in your vault. You can read every rule. You can change any of them. The agent reads governance the same way it reads work; the substrate is the same.

This isn't a server enforcing policy from somewhere else. This isn't code you can't see. The agent respects the rules because the agent reads the rules. The Studio you have on disk is the Studio that runs.

Not enforcement. Discipline-by-construction.

What changes when you start using it

The first thing that changes is that your work stops evaporating. The conversation you had with your agent on Tuesday isn't a chat history you'll never re-open — it's a task with the context attached, ready for the next time you or any agent picks it up.

The second thing that changes is multi-agent coordination becomes routine. Your researcher and your writer aren't in separate apps; they're in the same Studio, reading the same projects, coordinating through the same channels. You stop being the integration layer.

The third thing that changes is governance becomes a thing you read instead of a thing you guess at. Every rule about how your agent behaves — what it can write, how it coordinates with you, what it should escalate — is a markdown file your agent reads and follows. You can read every rule. You can change any of them.

That's not a feature. It's a consequence of the substrate being right.

What this is, and what this isn't

Tropo Work is the substrate for human-AI work. Where work is authored by humans, agents, or both — and the substrate stays coherent regardless of who's writing. The same markdown, the same frontmatter conventions, the same governance rules apply to you and your agents identically.

What it isn't:

Not a project management tool. It doesn't replace Jira or Linear or Asana. Those assume work is humans coordinating with other humans; their substrate is human-shaped, and adding an agent on top is a feature, not the thesis.
Not a notes app. It doesn't replace Obsidian or Notion. Those assume the substrate is for human reading; work-management is incidental.

The distinction is structural. PM tools and notes apps work great for what they're designed for. Tropo Work is designed for the substrate-shape that emerges when agents are first-class authors, not bolted-on automation.

The trust contract

Your work in Tropo is in plain markdown. Files on your filesystem. Frontmatter you can read. References by UID, resolvable by any tool that can parse a markdown file.

Which means: you can leave with your data. Export your vault, take it to any other tool, lift the parts that matter to you — the work itself is portable by construction. Tropo's value is the substrate it provides; the substrate doesn't trap you in it.

That's a deliberate design choice. The moat isn't lock-in. The moat is bounded verification — the discipline of checking work against constraints you defined, scaled by the substrate that makes verification practical at agent-speed. We earn the relationship every release; we don't capture you.

Open your Studio

If this lands and you want to try it: get the Tropo starter, open your Studio, meet your first agent. The agent walks you through the model from there.

If you want to read deeper: The Studio Manifesto is the seven-principle framing this document sits inside. The knowledge-base articles cover the primitives in technical depth. Every primitive — task, project, pipeline, decision, brief — has a capsule definition that an agent can resolve by UID and read in full.

Your work is yours. The substrate is here. Open your Studio and start.