How Tropo works
The whole operating system is a folder of files.
Tropo runs real work with AI agents on plain markdown in a folder — no server, no database, no proprietary runtime. Any AI harness that can read text can operate inside it; any human with a text editor can audit every byte. Here is how it is built: three layers, nine subsystems, and the five theses underneath every decision.
The studio as a graph
Nine subsystems, three layers, one folder
The whole system decomposes into three layers — kernel, primitives, and apps — with 9 subsystems cutting across them, each owning the canonical state for its domain. Because every governed file declares where it lives, this map is not a drawing of the system; it is a projection of it.
The L1 system map — 3 layers, 9 subsystems. Click it to open the full architecture review.
Five theses drive every design decision
Markdown is the protocol
Governance, schemas, procedures, memory, and messages are all written in language a reasoning engine reads and follows. No permissions API, no database constraint at the base — the governance is the language. That's what makes it run, unmodified, under any AI harness.
Agent-first, human-also
Agents are the primary operators; humans are the directors and verifiers. The base layer is shaped for how agents read and work — and a deliberate human layer (navigation blocks, dashboards, a rendered tree) sits on top. If a human is staring at raw substrate, the surface hasn't shipped.
Local-first, zero-infrastructure
No server, no database, no network calls. Everything that looks like infrastructure — indexes, a query layer, dashboards — is derived from the files and rebuildable at any time. The deployment story is “a folder.” The disaster-recovery story is “the folder, plus one rebuild command.”
Gradual structure on a language base
Keep the free-form markdown playground; add structure per-type and per-field, incrementally, enforced through agent-native gates — never storage-layer rigidity. Tightening is one-way and backward-compatible: structuring never breaks older data, and a hand-written file is never hard-rejected.
Verification is the moat
As execution cost falls toward zero, the binding constraint becomes human verification bandwidth. Tropo is built so a domain expert can verify whether agents operated within the constraints she defined — and so verification scales with the quality of those constraints, not the volume of agent output.
The architecture, in eight views
Each view is one diagram and a short read — top-down, from the system map to how “done” gets proven. All eight, in full, live in the CTO/CISO architecture briefing — written by our Chief Architect agent, inside the system it describes.
- 1The system mapThree layers — kernel, primitives, apps — and the nine subsystems that cut across them.
- 2The typed substrateCapsules: schema as governed markdown. Contract → instance → enforcement at every rebuild.
- 3The VaultFlat files with graph semantics; derived surfaces; the read/write cycle that keeps it honest.
- 4Agent lifecycleThree-tier boot, six gated groups, hard gates, and generational succession across model families.
- 5MemoryA single curated surface plus an append-only episodic log, folded by governed passes.
- 6The event systemOne append-only log, guarded writes, rendered projections — coordination as an audit trail.
- 7Pipelines & playbooksOrchestration with structural gates: how Tropo ships Tropo without quietly skipping a step.
- 8Enforcement & verificationFour loci, the fix-on-see pattern, and what it means for “done” to be independently proven.
Or explore it live
The same architecture, rendered by the same graph engine that powers the cockpit and the market map — draggable, filterable, projected straight from the substrate.
Provisional projection (drafted from the architecture review, refined with the Chief Architect). Layout polish for small graphs lands with the next engine tune.
Tropo is open-source, and free. Read the architecture review · download it · see the market map · read The Agentic Builders.