When an Agent Touches the World

Apache Maka’s most consequential boundary appears when a model request becomes a file edit, shell command, network call, or other outside effect. The question is not merely whether the user approved a tool. It is where Maka records that execution may have begun, where it records the result, and what the system is allowed to conclude if the process stops between those points. Understanding that boundary lets the reader judge both the T1/T2 durability protocol and the narrower security claim made by a platform sandbox.

A tool call is an instruction from the model, not yet an accomplished action. Before Maka lets it run, the Runtime performs preflight checks: it validates the arguments, confirms that the tool is available, applies loop and failure controls, checks permission and the active execution boundary, and verifies that the correct Runtime owns the operation. Those checks decide whether the call may cross into the side-effect path. They do not themselves prove what will happen outside the process.

The dangerous gap is the point

A database transaction is good at committing records in one process. It cannot make an arbitrary shell command, file system mutation, network API, or child process part of an atomic transaction merely by keeping a database connection open. The external system may take seconds or hours, may have its own failure modes, and may change state before the Runtime can record the result. Maka’s design starts by accepting that gap instead of hiding it.

In the canonical SQLite path, the Runtime uses two short durability cuts. The first is called T1. After preflight succeeds, T1 records the tool call together with a dispatch fact before the implementation runs. The second is T2. After the implementation returns, T2 records the function response and the associated outcome before the result is made available to the next model step.

The shape is therefore:

preflight and permission checks
  → T1: call and dispatch fact committed
  → external tool effect
  → T2: response and outcome committed
  → result published to the next model step

T1 does not mean that the tool succeeded. It means that the Runtime passed its pre-execution guards and crossed the point after which it is no longer safe to assume that the implementation did not run. The file may have been changed, the command may have started, or the network request may have reached a remote service. T1 records the possibility of the effect, not its success.

T2 has the opposite role. It makes the returned result part of the canonical history. If the tool implementation reports success but T2 fails, the Runtime does not publish that uncommitted result to the next model step. Otherwise the provider could reason from a result that the durable history cannot later explain.