Why CanyonOS

CanyonOS is an open-source platform that brings coherence and control to multi-agent workflows: design, deploy, scale, manage.

Agentic applications have matured rapidly and have crossed from demos into production. Most of that progress has been in the application layer, which is maturing fast: frameworks, model builders, prompts. Below it sits the infrastructure layer, already mature from the cloud era: Kubernetes, Docker, autoscalers, containers and queues. Mapping applications onto that infrastructure was always the job of DevOps teams, and it was a static exercise: decide the shape of the deployment once, then tune it. That is no longer feasible, because two underlying realities have changed. First, the applications are no longer deterministic. An agentic workflow decides at run-time which agents to call, how often, and what each call costs, so a static mapping is inefficient from the moment it is written. Second, the cost of that inefficiency is far higher than it used to be, because the compute these workflows run on is scarce and expensive.

CanyonOS automates the mapping. Its workflow intelligence layer sees every call made to an agent and uses that workflow-awareness to deploy, scale, trace and govern the workflow on the underlying infrastructure.

It does this through independent policy planes rather than through the code. Scaling, observability and governance each live in their own plane beside the workflow, so the workflow can evolve independently of its scaling, observability and governance policies, and each policy can change without touching the code.

Four problems, one per plane, and the same cause behind all of them.

A multi-agent workflow is usually a handful of agents and one loop. Today's frameworks make you express it through their own objects: nested wrappers, graphs and edges, crews and tasks, routing by string match. The result is hundreds of lines of orchestration before a single prompt or tool, and a different few hundred for every framework. The same workflow in plain Python is one file per agent and a short workflow file you can read top to bottom. Plain Python is neutral, importable into anything, understandable and timeless.

How CanyonOS answers it. The development plane stays yours. CanyonOS runs plain Python: agents are ordinary classes in ordinary files and the workflow is a program. There are no framework objects to learn and no code changes to make. One command, canyonos deploy, builds the images, launches the agents across machines and starts the dashboard; the only artefact added to your project is a small configuration folder, which is where the other planes live. Read more.

Under load, queues build in front of the workflow and an autoscaler scales the whole workflow. This is often wasteful, since not all components of the workflow are under equal duress. The real bottleneck is usually downstream, in another agent or in a shared resource such as a test sandbox or a database, and the queue is only its symptom. Autoscalers see queues; they do not understand the relationship between them.

How CanyonOS answers it. The scaling plane. Because every call between agents passes through CanyonOS, it sees the dependency graph of the workflow: which component is waiting on which, and where the work is actually piling up. Scaling decisions are made from that graph rather than from a single queue, so capacity goes to the component or shared resource that is saturated, not to the one that happens to have a queue in front of it, and nothing in the code has to say so. Today CanyonOS ships per-agent autoscaling on queue length or throughput; the workflow-aware scheduler that scales from the dependency graph is the core of the Workflow Intelligence Layer and is in development. Read more.

Tracing tools ask your code to carry them: imports, a provider and an exporter, a span around every call, attributes set by hand, trace context passed across every agent boundary, and a flush at the end. The workflow file can double in size, every agent file grows with it, and switching vendors means doing it all again with a different decorator.

How CanyonOS answers it. The observability plane. In CanyonOS the runtime is the tracer. Every agent-to-agent call is already a message through the runtime and every model call already passes through the gateway next to the agent, so traces, logs, tokens and cost are collected per query and per agent with no instrumentation in your code, and exported as OpenTelemetry to whatever dashboard you already use. Read more.

An agent that meets a bad input will reason about the failure and retry, and nothing in today's stack says stop. What frameworks offer are counters (iterations, rounds, steps), not policies: they count steps rather than dollars, they do not know which run they belong to, and they live in the code, so a new budget waits on a redeploy. Meanwhile the workflow changes every week. Governance has to be independent of development.

How CanyonOS answers it. The governance plane. CanyonOS puts policy in a file, not in code. A gateway beside every agent enforces which agents may call which model and the most one call may cost; a call that breaks policy is refused before it reaches the provider; the policy file is reloaded in seconds without a redeploy, so governance changes at its own pace, independent of development. Policy per workflow and per query, on the same plane, is next. Read more.

The four problems share one cause: nothing in today's stack sees the workflow, so the mapping onto infrastructure stays static and every concern ends up inside the code. CanyonOS's workflow intelligence layer does see the workflow, which is what lets it automate the mapping and move each concern into its own policy plane: scaling, observability and governance beside the workflow, not inside it. The workflow evolves at its own pace, and each policy at its own. CanyonOS is open source (AGPL-3.0) at github.com/CanyonCodeCoreAI/canyonos.

CanyonCode is built by people who have spent their careers on the two things this problem needs: distributed systems that run under real load, and AI products that reached production.

• Website: canyoncode.ai
• The blog series, one post per plane: Why We Built CanyonOS
• CanyonOS on GitHub (open source, AGPL-3.0): github.com/CanyonCodeCoreAI/canyonos
• Workflow design guide: WORKFLOW_DESIGN.md
• LLM gateway and policy guide: LLM_GATEWAY.md