How the CMX Platform Is Structured: Continuum, Coordinator, Authority, Runtime, and Infrastructure
A conversation can end while an approval is still outstanding. Continuum is designed to keep track of that unfinished responsibility even when a different model or tool handles the next step. Coordinator helps people understand what’s happening, while Runtime attempts actions the system is permitted to perform. The result needs its own evidence, because requesting an action doesn’t prove that it succeeded. Some of these foundations are working today; the wider experience is still being developed.
For more detail about the product direction, read Continuum. Our Kubernetes engineering article explains part of the infrastructure underneath it.
Continuum Owns the Long Running Responsibility
Continuum keeps responsibility for unfinished work after the conversation ends. A model might help investigate a problem today and never be used again, but the goal and its outstanding approvals still need to be there tomorrow. The record of what happened belongs outside that model’s temporary context.
Waiting is normal in a project. An approval may take days, and a failed integration may need a different approach. Neither event should force someone to piece the situation back together from old messages.
Continuum is designed around the state that needs to survive those transitions. The product direction is broader than a single assistant session: goals, current state, responsibility, attention, authority, and verified outcomes can remain part of the system even when the intelligence used to reason about them changes.
Coordinator Is the Human Facing Layer
Coordinator makes the state of a goal understandable without asking someone to piece together old conversations. It should show what changed since the last check and where an approval is holding things up. If Runtime attempted an action, the person needs to see its verified result rather than another summary of what was supposed to happen.
The Coordinator is also where provider backed reasoning and Product Self Knowledge meet the current state of the product. Product Self Knowledge helps the system distinguish what is supported today, what is still being built, and what remains longer term direction. That distinction is important because a product should be able to explain its real capabilities without pretending that planned architecture is already live.
Context Runs Keep Intelligence Bounded
Continuum treats a model’s context window as temporary working context, while durable state lives elsewhere in the system.
A context run is a bounded reasoning execution. It receives the information needed for the current problem, performs reasoning or planning, and produces structured output that can be evaluated by the rest of the system.
This means the architecture can use different models for different jobs without making one provider or one conversation the permanent owner of truth. A difficult planning problem may use a stronger model. A routine classification step may use a faster model. A future implementation could swap providers again without redefining the durable responsibility underneath.
That same separation is why our AI Model Selection guide treats model choice as an architectural decision instead of a single universal answer.
State and Context Are Different Things
Context is what a reasoning step needs right now. State is what the system needs to remember later.
Keeping those two concepts separate is one of the foundations of the architecture because temporary reasoning context and durable product state have very different lifetimes.
Durable state can include verified facts, current status, ownership, goals, responsibilities, receipts, and other information that still matters after a model run ends. Context can be regenerated from that state plus the current request, relevant evidence, and trusted temporal information.
This design avoids a common failure in AI systems where long conversations become the only memory of what happened. Conversation text can still be useful evidence, but the architecture is stronger when important facts can be promoted into structured state with provenance and later reconciled against new evidence.
Evidence, Observations, and Durable Truth Need Different Treatment
Information enters the system at different levels of certainty, so provenance and confidence need to survive long enough for later reconciliation.
Incoming information is evidence, even when it arrives through a trusted integration. The system can record an observation from that evidence and consider whether it supports a change to what the relevant domain accepts as true. Reconciliation is responsible for that decision. A document’s existence alone doesn’t make every claim in it correct.
One document can disagree with another. A later message may correct an earlier claim. The system needs to keep the original evidence so it can revisit what it believes instead of treating the latest sentence as truth.
This same discipline appears in our public research work. From OSINT to Search explains why provenance and contradiction handling matter when several public sources describe the same real world entity differently.
Capability and Authority Are Separate
Knowing how to do something doesn’t mean the system should be allowed to do it. A connected tool might be capable of changing a customer record, but that particular request may still need approval from a person.
CMX separates capability from authority. Capability describes what an integration or runtime path can technically do. Authority describes what the system is allowed to do in the current situation.
That separation creates a consequence path where reasoning, permission, execution, and verification remain visibly distinct from one another throughout the workflow.
- A decision or proposal is produced. Intelligence can recommend or structure an intended action.
- The proposal is validated. The system checks whether the requested operation matches a known capability and contract.
- Authority is evaluated. The product decides whether the action is permitted under the current user, account, and workflow state.
- Runtime executes. Approved consequential work is handed to the execution layer.
- A receipt returns. The system records evidence about what actually happened.
- State is reconciled. The result can update durable state when the evidence supports it.
Model output can propose an action, while authority comes from the surrounding system. Keeping that boundary outside the model is part of the architecture itself.
Runtime Owns Consequential Execution
Runtime is the layer responsible for approved work that changes something outside the reasoning process and therefore needs a verifiable execution result.
That can include operations where a real system needs to be called, changed, or instructed. The important architectural point is that consequence is separated from reasoning. The reasoning layer can propose. Runtime is where an approved action is actually attempted.
The receipt is evidence of the execution result, rather than another statement of intent. A deployment request might be accepted while the application itself fails to recover. The product needs to preserve what Runtime reported and use later evidence to establish whether the goal was reached.
This distinction is one of the foundations for longer running coordination. Continuum can keep responsibility attached to the goal while Runtime and receipts establish what has actually happened along the way.
Human Attention Is a Separate Resource
Some work needs a person because another model run would not resolve the uncertainty, approval need, or judgment involved.
Human Attention gives the architecture a place to represent cases that may need review without automatically converting the incoming material into authority or action. That makes attention a bounded resource the system can surface and manage separately from automated execution.
The current Human Attention foundation accepts and stores cases as untrusted evidence for possible review. Submitted material stays separate from authority, external action, URL retrieval, and verified truth.
That separation is deliberate. A system that can receive information from outside needs to preserve the difference between “someone submitted this” and “the system has verified this and is allowed to act on it.”
The Infrastructure Layer Supports the Product
Continuum is designed so the product model can survive changes in providers, integrations, databases, and execution infrastructure underneath it.
CMX operates infrastructure that includes Kubernetes, real time communication, backend services, databases, and execution paths. Parts of that implementation are documented publicly in our infrastructure articles.
The specific infrastructure matters for reliability, control, performance, and cost. It is still replaceable compared with the durable concepts above. A database can migrate. A model provider can change. A runtime integration can be replaced. The responsibility, authority boundaries, evidence, and state model should survive those changes.
That is why we treat infrastructure as a layer instead of making the product definition depend on one framework, one cloud provider, or one AI model.
Real Time Systems Still Need Ordinary Engineering Discipline
Parts of CMX use real time communication, but the architecture still depends on ordinary engineering concerns such as connection ownership, recovery, and backpressure.
Persistent connections can fail in ways that ordinary page requests do not. A network interruption may leave thousands of clients trying to reconnect together. The system needs to recover those connections without losing the state that matters.
Our WebSockets at Scale guide covers those failure modes directly. The same principle applies across the platform: product ideas still need measurable engineering behavior underneath them.
The Current Product and the Longer Term Architecture Are Not the Same Thing
Some of the architecture described here already exists as working foundations. Other parts are still being expanded into the complete Continuum experience.
Current foundations include durable goals and conversations, Coordinator reasoning, Product Self Knowledge, bounded context runs, explicit Capability and Authority separation, Runtime foundations, receipts and reconciliation, Human Attention, and structured state across areas such as Library, People, Check In, Current State, goals, responsibilities, authority, and runtime.
Further work is planned to support more persistent coordination across longer tasks. That includes richer ways to delegate approved work and return to it when new information becomes available. These are directions for the product, and should not be mistaken for features available today.
We keep that boundary visible because architecture is most useful when readers can distinguish a working foundation from a future capability.
Why This Architecture Matters for Founders
Founders often end up keeping the history of unfinished work in their heads. An approval is waiting somewhere, a technical problem has changed the plan, and yesterday’s AI conversation doesn’t know what happened this morning. Continuum is designed to retain that responsibility and bring forward the decision that matters next.
It also needs to know when to stop. A connected tool might be able to make a change, but Authority still has to permit it. After Runtime attempts the action, the result needs evidence. Those boundaries are what make continuing work safer than simply asking a chatbot to keep trying.
How the Architecture Connects to the Rest of CMX
The platform sits beside CMX’s client work as a separate product direction. The same engineering ideas show up in the systems we build and operate for businesses: clear state, explicit ownership, reliable integrations, measurable execution, sensible permissions, and infrastructure that can evolve without forcing the whole product to be rebuilt.
For the product direction, read Continuum. For infrastructure implementation, read Bare Metal Kubernetes with Cilium, eBPF, and BGP. For operational scaling, read What Breaks First When Infrastructure Scales. For AI placement inside larger systems, read AI Model Selection.
Frequently Asked Questions
What is Continuum in the CMX architecture?
Continuum is the durable coordination layer. It is meant to keep responsibility, state, blockers, and verified outcomes available across model runs, tool calls, waiting periods, and changes in plan.
What is the difference between Coordinator and a context run?
Coordinator is the human facing coordination layer. A context run is one bounded reasoning execution used to solve or evaluate a specific problem. Coordinator can use bounded reasoning while the durable responsibility remains outside any single model run.
What is the difference between capability and authority?
Capability describes what an integration or execution path can technically do. Authority determines whether that consequence is permitted in the current situation. The architecture keeps those decisions separate from model output.
What does Runtime do?
Runtime owns approved consequential execution. It attempts the action, returns evidence about the result, and gives the rest of the system something concrete to reconcile against the intended outcome.
Is everything described here already live?
No. Several foundations are working today, while the complete long running Continuum experience is still being developed. This page separates current foundations from broader product direction so planned architecture is not presented as finished capability.
How does the infrastructure relate to Continuum?
Kubernetes, real time communication, backend services, databases, and execution paths provide the implementation layer. Continuum is designed so the responsibility and state model can survive changes in those underlying technologies.
The Short Version
Continuum keeps unfinished work attached to a durable goal, while Coordinator helps people see what needs attention. Context runs let models work on bounded problems without making their temporary conversations the source of truth. Before Runtime attempts an action, Authority checks whether it’s permitted. Receipts provide evidence of the outcome so the system can update its state. Human Attention gives questions that need a person’s judgment somewhere to go. The infrastructure underneath can change without losing the responsibility that ties the work together.
Keeping responsibility separate from a model’s temporary context lets the system revisit unfinished work without treating an earlier answer as the final record of what happened.
