The Trust Boundary of an Agent Workspace
Apache Maka’s central question is now visible across execution, context, recovery, coordination, measurement, and privacy: how can an agent be useful without allowing every status, summary, callback, or retry to become a competing version of reality? This final chapter connects Agent Graph and Eval to the same Runtime/Event foundation, then turns Maka’s explicit limits into a practical way to judge claims about trustworthy agent workspaces. The conclusion is not that durable records remove uncertainty. It is that Maka makes authority, evidence, and uncertainty visible enough to reason about.
The pattern begins with one ordinary Run. A client request enters a Runtime Host, the Host admits it to a Session and Run, the model and tools produce RuntimeEvents, and the log becomes the source for projections. Side-effect boundaries say when an effect may have begun. Context checkpoints say which history a provider may see. Recovery says when a new Run may continue and when it must park. The remaining question is whether the same discipline survives when work is split across agents, compared in an experiment, or constrained by privacy and security policy.
Graph adds a schedule, not a second Runtime
Agent Graph is the clearest test of whether Maka’s architecture can grow without losing its center. A graph of specialists appears to need its own execution model: nodes, messages, dependencies, retries, and completion states. Maka instead places a durable scheduling control plane beside the existing Runtime.
A child Session becomes a stable operator container. Each time that operator performs work, it receives a new Session-inline activation and an ordinary AgentRun. The child therefore keeps the Runtime features already established: model and tool execution, permissions, history, compaction, usage, artifacts, stop, recovery, and inspection. Graph does not introduce a separate GraphRun ledger or a second model/tool loop that would have to rediscover all of those rules.
Only committed, non-partial RuntimeEvents become graph records. A record is a bounded reference to a source Session, Run, and event, not a copy of the full message, tool arguments, or result payload. That design gives Graph enough information to route and schedule work while leaving authoritative content with the Runtime ledger. When the supervising Agent needs the actual child answer, it reads the authoritative child output through the Runtime path rather than trusting a copied payload in the graph projection.
The Graph control plane stores a different kind of fact. SQLite records schedule revisions, operator provisions, topology, readiness, intent claims, and supervisor wakes. Those rows answer questions such as “what work did the supervisor request?” and “which exact activation was admitted?” They do not answer “what did the child model say?” or “did the tool change the workspace?” Those questions remain owned by the child Session’s Run and RuntimeEvents.
This division makes two distinctions essential.
Readiness is not admission. A readiness projection can determine that an operator has the inputs and policy conditions needed to run. It produces a deterministic intent; it does not start the Runtime. A durable claim then binds that intent to exact operator, Session, Turn, and Run identities before dispatch. If reconciliation repeats after a crash, the existing claim and Run can be observed or recovered instead of invoking the provider a second time.
Quiescence is not completion. A reconciliation pass may find that no activation is currently eligible. That means the schedule is locally quiet under the present facts and policy. It does not mean the user’s work is complete. A supervisor may still need to inspect a result, add dependent work, stop obsolete work, or explicitly finish the graph. Completion is a durable schedule decision, not an inference from temporary inactivity.
The main Agent stays beside the graph. It can view the schedule, add or stop work, read selected child outputs, and choose result records. Ordinary record projection does not wait for the supervisor’s approval, so a broken callback or disconnected desktop listener cannot change what a child Runtime did. At the same time, the supervisor remains close enough to the user’s conversation to make judgments about topology and synthesis rather than disappearing into an opaque scheduler.
The current scope matters. Maka’s Graph path supports a directed acyclic topology with monotonic additions and explicit supervisor updates. It is not presented as a general distributed stream processor, a visual workflow authoring system, or a fully autonomous scheduling engine. Its readiness primitives are not a complete global fairness, resource-allocation, watermarking, or backpressure system. These limits are not an embarrassment after the feature; they are what keeps the graph from quietly becoming a second authority.
Eval makes comparison durable without changing execution
Evaluation applies the same separation to a different problem. A benchmark needs to compare subjects, repetitions, scores, costs, and failures, but it must not rewrite the meaning of the Runtime that produced each attempt. Maka’s @maka/eval package owns experiment semantics while the Runtime Host owns Maka execution.
An experiment freezes the benchmark, executor, subjects, tasks, repetitions, budget, verifier, and declared task-group concurrency. Its cells are the Cartesian product of task, repetition, and subject. That structure makes the unit of comparison explicit.