One Runtime Host, Many Entry Points
Apache Maka’s Runtime Host solves a specific ownership problem: how can a Desktop window, a terminal client, a bot, and an evaluation run work with the same State Root without quietly creating competing execution histories? This chapter follows the Host boundary, its admission rules, and its shutdown behavior. The practical judgment is whether a client is observing durable work, requesting new work through the owner, or accidentally pretending to be the owner.
The need becomes clear when the same task is approached from two places. A user may start a long-running change in the desktop application, inspect it from the TUI, and later use the CLI to ask what happened. If each surface constructs its own runtime around the same files, both may believe they are in charge. One can miss the other’s tool call, overwrite a status, or make a retry decision without knowing whether the first attempt already reached the outside world.
Maka’s solution is not to make every client smarter. It gives each State Root one writer Host at a time. The clients can differ in presentation and connection path, but execution control, durable facts, and recovery ownership remain behind one public boundary.
The Host is an owner, not a socket
A State Root is the durable home for one coherent body of runtime state. The Host that owns it is more than a server listening for requests. It is the authority that admits connections and operations, routes requests, retains processes when appropriate, drains work during shutdown, and coordinates the components that interpret the root.
The one-writer rule is the first protection. At most one Host may write a given State Root at a time. Maka validates the root’s real identity and takes an operating-system lock on a stable ownership boundary. A registration file can help another process discover a candidate Host. A process ID can help with observation. A socket can provide a route. None of those artifacts, by themselves, grants write authority. Deleting a cache or editing a PID must not create a second owner.
This distinction matters because discovery and authority fail differently. A discovery record can be stale after a crash. A process can disappear while its durable work remains. A path can have aliases. The system therefore treats those clues as evidence about where a Host might be, then validates ownership through the root identity and OS-enforced lease. If the ownership or composition check fails, the safe outcome is to stop business entry and report the conflict, not to make the new process “helpfully” take over.
Inside the Host, responsibilities are deliberately separated:
- The Host Kernel governs admission, connection lifecycle, routing, retention, draining, and protocol behavior.
- A Domain module owns the meaning of its business operation; it does not open a second Runtime outside shared admission.
- The hosted execution authority admits and recovers a Session’s root execution.
- The Runtime and AgentRun own model steps, tool steps, and RuntimeEvents.
- Session Continuity builds snapshots, transcripts, and live projections from canonical facts.
- A Client Capability supplies bounded client-side abilities, such as a provider connection or a reverse call, without taking ownership of the Session or Run.
The list is useful only as a map of decisions. It does not describe six independent services or six competing databases. It says which question belongs where. The Host decides whether a request may enter. The Runtime decides what the model and tools do. Continuity decides how durable facts are shown. A client decides how to display or supply an explicitly granted capability.
The diagram’s arrows are about ownership and calls, not a mandatory route for every operation. A read-only observation may not pass through every node shown. The important boundary is that a client reaches the shared execution authority instead of composing a parallel one. Eval follows the same principle when it runs a Maka subject; its experiment semantics remain separate from the Runtime.
Admission is short; execution is long
A Host still needs concurrency. One user may have several Sessions, and different Sessions should not be forced to wait for one another. At the same time, two requests that change the same Session cannot be allowed to race through the model loop as if they were independent.
Maka handles this with two levels of control. A per-Session admission gate protects short critical sections. It can serialize the decision to admit work without holding a lock during a provider request that may take seconds or longer. Multi-Session operations acquire their short-lived gates in a stable order, avoiding one class of lock-order deadlock. Once work is admitted, execution leaves that narrow admission context and proceeds under an execution handle.
Above the Session gate, a root turn coordinator manages reservations and active execution. Its rule is straightforward: one Session has at most one logical root execution being admitted or running, while different Sessions may execute concurrently. Child Sessions and graph lineage add their own constraints, but they still use the shared Runtime authority rather than bypassing it.
A request does not become safe merely because it has a string saying “run.” Admission creates a single-consumption reservation and records the exact intent: the Session, Turn, Run, user message, source messages, and predecessor chain. Reusing an identity with different content is not an acceptable retry. If the system cannot prove that a repeated request has the same intent and place in the admission chain, it fails closed instead of allowing two interpretations of one action.
Successful admission returns handles for different questions. A completion result says whether the execution completed, failed, was cancelled, or could not establish authority. A settled signal says that cleanup has finished. Those promises are not interchangeable, and callback order is not another persistence guarantee. A listener may miss a notification; a reconnecting client may arrive after the callback; a process may exit while a local promise is unresolved. Durable admissions, RuntimeEvents, and control stores remain the place to reconcile what actually happened.
This is the architectural reason not to stretch a database lock over the whole model/tool loop. A long transaction would make external work look atomic when it is not. It would either block unrelated activity or pretend that a filesystem change, remote provider call, or child process belongs to the database’s transaction. Maka instead makes the admission decision durable, lets the execution run, and records the facts that settle it through the Runtime’s event and Run boundaries.
The result is controlled concurrency rather than maximum concurrency. Different Sessions can make progress together, but the same Session retains a clear order. That trade-off costs bookkeeping: exact identities, reservations, residency handles, and cleanup paths must line up. In exchange, the Host can explain which work it admitted and avoid using a vague “busy” flag as a substitute for ownership.
Observation is not ownership
A shared Host is valuable only if clients can observe it without becoming hidden schedulers. Maka therefore treats observation as a projection over durable state. When a client opens a Session subscription, it receives a canonical snapshot, a position from which live updates can be observed, and information about active streams. The live sequence helps the connection track changes. It is not the same counter as a durable transcript cursor or an event ordinal used for pagination.
That separation prevents a common failure mode. A client may receive events 10 and 12 after losing event 11, or reconnect after the Host process has acquired a new generation. The correct response is to reopen the subscription and reread canonical state. The client should not replay the command that originally produced the missing notification merely to make its screen look complete. Queries can often be retried because they are read-only. Mutations need a stronger rule: if a command was sent but its result never arrived, the outcome is unknown until the owning domain reconciles its exact request identity or durable result.
The same rule applies to the user interface. A renderer can show a live tool card and a TUI can show a status line, but neither display is permission to execute again. A local outbox can preserve the identity of a message or attachment during a crash, but that is a product-specific delivery contract, not a general license to replay every mutation. The Host must distinguish “the client did not hear the answer” from “the operation did not occur.”
Client capabilities introduce another boundary. A client may offer a provider connection, a local UI action, or another bounded reverse call. The Host chooses a binding according to the admitted principal, capability contract, provider instance, and affinity rules. Losing a session-affine capability cannot silently switch the work to an unrelated machine. A client can perform a local capability while the Host retains ownership of the Run, Session, and recovery decision.
This design also explains why multiple entry points can share a task without sharing every privilege. A connection’s grants are fixed when it is admitted. Guest observation, turn requests, Host operations, tool sandbox permissions, and client capabilities are separate contracts. Being connected to a Host does not imply authority to create new work, inspect every payload, expand a sandbox, or stop another resource.
Drain, process lifetime, and recovery
Ownership becomes most visible when the Host closes. Maka distinguishes natural idle exit, graceful drain, launcher exit, and operator stop. An idle residency can keep a Host available for future work without representing active work that shutdown must await. A drain residency represents work that must settle: an admitted execution, a persistence handoff, or an active resource process.
During a safe close, the Host rejects new operations, waits for admitted work and starting work covered by the drain contract, closes stores, and releases the writer lease only after store access has ended. Module shutdown proceeds in reverse construction order, and one owner failing to close does not give the Host permission to skip the others. This accounting is more demanding than a single active-task counter, because queued work, asynchronous waits, and external resources can all exist between “request arrived” and “process is done.”
The Host also owns resource identity, not merely the screen that observes it. A shell or pseudo-terminal can outlive an observing client. Disconnecting that observer does not automatically terminate the process. Recovery must reconcile retained resources using more evidence than a bare process ID, because a PID alone neither proves which process is still present nor proves that every descendant has ended.
Client lifetime is therefore deliberately limited. Disconnecting an ordinary client releases its connection-scoped subscriptions, capability offers, and controller leases; it does not automatically cancel already-admitted work. Conversely, closing any arbitrary client is not a universal guarantee that work survives. Desktop quit, TUI detach, a one-shot CLI invocation, and an operator-managed service each follow their own lifetime contract. The Host boundary makes those differences explicit instead of hiding them behind a single promise that “the agent keeps running.”
Startup uses the same authority sequence in reverse. The candidate first acquires and validates the root writer, checks that the installed composition is compatible, establishes listeners and registration, constructs the fixed modules, and runs recovery phases before publishing readiness. A discoverable process is not necessarily a ready Host. A reconnecting client must respect that distinction and wait for the Host to prove that its durable state can be interpreted.
This is where the Runtime Event Log from the previous chapter becomes operational. The Host does not reconstruct a Session from a notification cache or from an in-memory list that died with the process. It reopens the durable Runtime and control records, repairs interrupted executions according to their facts, and rebuilds projections where necessary. If the records are ambiguous or unreadable, it preserves the problem as an explicit diagnostic rather than admitting new work on a guess.
What the Host boundary buys—and costs
The one-writer model buys a clear answer to “who may change this State Root?” It also lets clients reconnect independently, lets different Sessions execute concurrently, and lets projections be rebuilt without asking every client to agree on a mutable status. These properties are especially valuable for an agent because model calls, permissions, and tool effects do not respect the lifetime of a single screen.
The cost is that the architecture cannot treat every operation as a simple request and response. It needs durable intent, exact identities, bounded subscriptions, process generations, drain accounting, and explicit unknown outcomes. It also has a scope: one Host owns one State Root; multiple Hosts do not become one global execution authority merely because they can connect through a network, and the project identifies Peer functionality as experimental.
The useful test is simple. When adding a feature to Maka, ask whether it creates a second writer, a second execution owner, or a second interpretation of terminal state. If it does, the feature is not merely adding a client convenience; it is challenging the architecture’s central contract. If it does not, the feature can usually be understood as a new operation, capability, or projection within the existing Host boundary.
The Host has now given the event log an owner and a lifecycle. The next question is how those two ideas behave when they meet the outside world: a tool can change a file, a permission decision can pause execution, and a process can stop between dispatch and outcome. That is where Maka’s explicit side-effect boundaries become decisive.