Engine
Runtime
The engine that answers a question across my domains, runs agents for real work, and keeps nothing of its own.
The runtime is the orchestrator of AlanOS. It takes a question or a task, finds out from the domains themselves what each one can do, calls them, and combines what comes back.
It is a client of the federation, never its owner. It follows the constitution like everything else, and it is built so it could be replaced without any domain noticing.
What it does today
- Answers across the domains
- A question from the terminal or the console goes to whichever domains can answer it. The runtime combines their answers, cites only what a domain actually returned, and records the conversation in Memory.
- Work threads
- A task goes to Claude Code or Codex, working on my home server in a separate checkout of the repository, inside a sandbox. Nothing reaches the real branch until the repository's own checks pass.
- Scheduled runs
- Day reports, mail and voice notes are collected through the day. Overnight it audits dependencies and documentation, and once a week it runs each domain's improvement review.
- The API behind the console
- The console and every application talk to the runtime and never to a domain. The runtime serves both the API and the built console.
One question, end to end
What happens when I ask something no single domain can answer, like “I have a free Saturday. What's the most useful thing I could get done?”
- 01
Discover the federation
The runtime reads every domain's manifest: what it holds, which capabilities it offers and how to reach them.
- 02
Let a small model route
A small, cheap model chooses which capabilities to call. It only sees what domains allow it to see, and it cannot search a domain's files.
- 03
Call the domains
Calls go over the Model Context Protocol. Actions that change something are not handed to the model by default; the runtime calls them itself and says what it held back.
- 04
Answer with real citations
A citation is kept only if a domain returned it. The runtime observes what actually happened rather than trusting what it was told.
- 05
Remember the conversation
Each turn is sent to the Memory domain as its own session, so the next conversation can build on it.
The boundaries
- It keeps nothing of its own
- Anything worth keeping lives in a domain. Destroying the runtime loses nothing, and a different one could take its place.
- The framework is replaceable
- Mastra runs the orchestration, but removing it must cost only runtime code. No domain may depend on anything Mastra-specific.
- Local by default
- Traces are local, metadata only and off unless I turn them on. There are no hosted observability tools and no outside analytics.
- Its own description is checked
- The list of what the runtime can do is generated from the code, and a test fails when the two disagree, so the documentation cannot fall behind.
Measured, not assumed
Routing has its own evaluation suite: the same questions, run against different models and prompts, scored the same way. That is how a model choice is made here, rather than by impression. A separate check asks whether anything in the federation is quietly broken.
Where it goes next
More of the routine work moving from questions I ask to work the runtime does on its own, on a schedule, with only the results reaching me in the console.
The runtime is the part people expect to be clever. I have tried to make it the part that matters least: the domains hold the truth, and the runtime only carries it.