tropo
Documentation pages
On this page
  1. The crew
  2. One piece of work, start to finish
  3. How they stay in step
  4. How an agent outlives its sessions
  5. What you can take from this
  6. Related

Verified against v1.102.0 on 2026-09-30 by orpheus-o42

The Argo crew: a worked example

How the team of agents that builds Tropo works, traced through one real piece of work.

Tropo is built with Tropo. A founder and five agents work in one Studio every day, and this page shows what that looks like, so you can see what your own Studio can grow into. Everything here is ordinary Tropo: the same files, tools and rules your Studio has.

The crew

The Studio is named after the Argo, the ship in the Greek myth. Each agent has a primary responsibility, and each also works outside it when it is the right hand for the job:

AgentRolePrimary responsibility
VelaChief of staffKeeps operations running, and checks other agents' work
ArgusChief architectDecides how the system is shaped, and approves a design before it is built
MetisStrategistPlans each release, decides what goes in it, and coordinates the crew
TalosLead engineerBuilds and tests the code
OrpheusKeeper of loreWrites the documentation, including this page

Mike Maziarz, Tropo's founder, directs the work. He sets what matters, makes the calls that are his to make, and approves anything that goes public. He does not write code.

The agents do not all run on the same AI. At the time of writing, Metis runs on an OpenAI model in Codex, Vela on a GLM model, and the others on Claude models in Claude Code. They share one Studio and read the same files. That works because nothing an agent needs lives inside its AI tool.

One piece of work, start to finish

The documentation site you may be reading this on went this way. Steps 1 to 6, from Mike's question to an approved contract, took three days.

  1. Mike asked for it. He looked at the Studio's orientation page and asked who it served and what it was for. That question became a request: documentation a stranger could use, on the website and inside every download.
  2. Orpheus researched and proposed. She studied four well-known documentation sites, drew three visual directions, and wrote them up as a design brief: a record of the question, the options and the recommendation. Mike picked one direction and answered five questions, and his answers were written into the brief word for word.
  3. Orpheus wrote the contract. A dev-spec says exactly what will be built, which files change, and how each result will be checked, with a command that must pass and a deliberate break that must make it fail.
  4. Someone else reviewed it. An agent on a different AI model read the contract looking for problems, and Argus read it again before approving it. Each review sent changes back, and each change was made in the contract itself, not in a side conversation.
  5. Metis placed it in a release, and Argus wrote the matching test-spec, which pairs every promise in the contract with the check that proves it.
  6. Argus locked it. After the lock, the contract does not change without a new review.
  7. Talos builds the site and Orpheus writes the pages at the same time, against the same contract. Each tests their own work, and a different agent then verifies it independently: a reviewer who did not build the code checks it, and Metis reviews these pages against the files they describe.
  8. Mike decides when it goes live. Publishing the website is always his call.

How they stay in step

  • Messages are files too. When one agent needs another, it writes an event to the Studio's shared log and names the work it is about. The other agent reads its log when it starts and while it works. A reply is linked to the message it answers, so a question can be seen as answered or still open.
  • Work lives on records, not in chat. Each task, spec and decision is a file with an owner and a status. Asking "what is Talos working on?" means reading records, not remembering a conversation.
  • Each agent keeps a working list of what it is doing next, and takes it over from its own previous generation.

How an agent outlives its sessions

An agent's session ends when Mike decides to end it; an agent does not end its own session. The agent itself continues. Before the session closes, it writes a letter to the next generation of itself: what is finished, what is waiting, and what went wrong. It also updates its memory file with anything it learned that should last.

The next session reads the letter and the memory before doing anything else, and carries on. The Argus line has done this more than two hundred times. When the AI tool shortens a long session instead of ending it, the agent continues as the same generation; see My AI session was compacted.

What you can take from this

You do not need five agents. Most Studios start with one. The same pieces scale down:

  • One agent, one job, a memory that carries over: Create an agent.
  • Work written down as tasks and decisions, so any session can pick it up.
  • A second agent, or a second AI model, to review what the first one made.
  • You, making the calls that are yours, and checking results against what you asked for.
  • What is Tropo: the ideas behind the crew.
  • Glossary: design brief, dev-spec, generation and the other terms on this page.