A model answers.
theo coordinates.
Build your own model orchestration with MCIR memory built in. Choose models, add skills and permitted tools, then deploy the combination into agents and connected applications. Relevant context stays with the work.
What should run?
What can it see?
What happens next?
Three system questions. Not three things a prompt alone can guarantee.01separate the responsibilities
The answer is only one part of the request.
- The model
- Generates or transforms an output from the context it receives. A Theo capability such as
theo-1-reasonortheo-1-codeis a destination for work, not the whole application. - The orchestrator
- Coordinates intent classification, available skills, model selection, and tool use. Configured context and policy checkpoints influence what can reach the next step.
- Built-in memory / MCIR
- Supported paths can bring relevant owner-scoped history into the request. The full MCIR intent pipeline and Memory Chain have separate activation requirements. Context is not shared across tenants.
- Your application
- Authenticates the person, decides what data and actions they may access, presents the result, and owns any human review or approval before an external action.
One entry point, different paths.
A short question may need a single model response. An application assistant might also need a domain skill, a reference from an earlier conversation, and a permitted tool.
Orchestration makes those choices explicit. It does not turn a model response into a verified fact or remove the need to test your application.
read the request pipeline (opens in a new tab)02follow the handoffs
A system around the model, not another model.
This map shows responsibilities, not a promise that every component runs on every request. Availability, enabled stages, key configuration, and policy bindings determine the actual path.
- 01 / requestYour application
Authenticated task, relevant context, and permitted actions.
- 02 / entryGateway
API-key scope and any bound input-policy rules.
- 03 / coordinateOrchestrator
Intent, context, skills, routing, and configured checkpoints.
- 04 / performModel + tools
The selected Theo capability and tools available to this request.
- 05 / returnResponse
Any bound output rules, then content and request metadata.
Built-in recall on supported paths. Full intent-driven assembly and Memory Chain require separate activation.
Persona, domain skills, and the tools an assistant may use.
Routing preferences choose a path; bound policies evaluate content.
Back in your application ↳Validate the result, expose its sources, and ask a person to approve consequential actions.
03configure, then inspect
An orchestrator graph is a set of connected decisions.
The opt-in orchestrator graph has a deliberately small vocabulary: an entry, classifiers and routers, model nodes, guardrail checkpoints, and description notes. Edges connect the path; model nodes can carry their own skills, and checkpoints can reference policies.
These are orchestrator graph nodes, not the different skill-building nodes in E.V.I. Canvas. A description annotates a graph; it does not execute an action. The marketing workbench adds a demo-only Output endpoint, not a node in the current product editor.
An enabled graph should be treated as the configured route. If it has no reachable model, surface the configuration error rather than silently answering with an unrelated model. A supported fallback is a deliberate part of configuration, not permission to ignore a broken graph.
04go one layer deeper
Start with the part your application needs.
Build your own intelligence layer with reusable instructions, knowledge, and permitted tools.
Explore local models, skill authoring, and orchestrators alongside connected cloud access.
Built-in continuity across models, sessions, agents, and connected apps. Inspect the source and owner scope.
Compose a persona, skills, and tools without confusing a skill canvas with an orchestrator graph.
Make a server-side completion, inspect the response, and plan for errors.
before you ship
Keep the boundaries visible.
Does every request use every layer?
No. Supported memory paths are distinct from the full gated MCIR pipeline. Skills, tools, graph stages, and policies have their own configuration. A feature’s existence is not evidence that it ran for a particular response.
Where does human approval happen?
In your application. Build explicit review states and permission checks around actions such as sending a message, changing a record, or making a consequential recommendation. A prompt asking for caution is not an approval workflow.
Does Arca protect every theo request?
No. Arca is a scoped research architecture, not a blanket guarantee for the gateway, every model, or every application. read the Arca scope
Your models. Your memory. Your way to build.
Start with a sample orchestrator, then bring routing, skills, and built-in MCIR memory into an agent or connected application.