The data is real: your browser fetches the live Traverse capability registry and a client-side heuristic -- not a hosted AI model -- groups related capabilities and orders them into a plausible pipeline, the shape of what an AI agent could compose over MCP. Nothing is precomputed; only the WASM execution afterward is simulated, not actually run. Full breakdown of what's real and what's not in how this is actually built, below.
How to read it: your Goal is the request that starts everything. The Traverse system -- the AI agent, its MCP connection, and the runtime -- is the architecture a real agent would talk to, discovering and validating a matching workflow along the dashed line. The runtime then chains together the right capabilities to do the actual work, producing a Result along the solid line. Click any capability to open its real, published contract in the registry. The step-by-step animation shows execution order; it doesn't run the WASM.
This page is static (Astro, no backend). On load, it fetches the same public catalog.json that powers the registry's catalog site, groups the current version of each capability by namespace, and orders any namespace with two or more active capabilities into a pipeline (ingest → interpret → decide → act) using a simple verb heuristic on each capability's name. That's the entire "agent" -- a composition heuristic running on live data, not a hosted model deciding anything. Once a workflow is composed, the graph steps each node through idle → running → completed to show execution order -- that sequencing is simulated in the browser, not a real invocation of the WASM binaries. Running a composed workflow for real is what traverse-cli serve is for. Click "Discover another workflow" to re-query the registry and see a different set of capabilities get composed.