Apache Maka makes the agent log the runtime, not the model

Apache Maka, now incubating under the Apache Software Foundation, makes a quiet but consequential design bet: the log is the runtime. Model messages, tool calls, tool results, permission decisions, and termination events all land in an append-only Runtime Event Log. Sessions, the UI, model context, and crash recovery are projections over that log, not separate state. That framing, stated plainly in the project’s README, is the most interesting thing about Maka. It treats an agent’s execution history as the source of truth, and the model as a component that reads and writes into that record.

The distinction matters for the broader agent ecosystem. Most agent frameworks treat the conversation transcript as a convenience: something to render in a chat window, prune when context grows, and discard when the session ends. Maka inverts that. The project’s architecture splits “context” from “history” explicitly. Tool Result pruning and LLM Compaction change what the next inference sees, but they do not delete the underlying evidence. The recorded facts survive. That separation is the difference between an agent that remembers and an agent that can be audited.

One execution authority

Maka’s backend spine is deliberately narrow. Desktop, TUI, and CLI all route through Runtime Host, which owns Session, Turn, agent lifecycle, continuation, tools, and events. The evaluation subsystem, maka eval run <spec> --out <directory>, executes Maka subjects only through that same Runtime Host. Eval owns experiment semantics and results, nothing else. One execution authority means one place where permission decisions and tool side effects get recorded.

That design carries real consequences for reproducibility. Maka’s eval system expands declarative multi-arm experiments into task × repetition × subject cells, with immutable per-cell attempts and earliest-valid selection. Each attempt records score, normalized usage, attributable cost, duration, status, failure reason, and artifacts. Because subjects and evaluators share the same runtime spine, a benchmark result in Maka maps directly to the execution facts that produced it. That is a meaningful improvement over the common pattern of benchmarking agents through ad-hoc harnesses that capture only final outputs.

Local-first as an accountability posture

Maka is local-first by default. Sessions, settings, and run records stay on the machine. Users choose their own model connection: a cloud API, a local model, or a compatible gateway. The project does not bundle a shared model account. On first launch, the user adds an API, local-model, or supported account connection under Settings → Models.

The security boundary is unusually explicit for an early open-source release. Workspace data lives under Electron userData, with runtime.sqlite as the sole operational authority. Credentials sit in a local plaintext credential-vault.json, protected by the OS account boundary, POSIX directory mode 0700, and file mode 0600. The renderer never receives plaintext credentials. File writes, Shell, and dangerous tool calls pass through the permission engine. That is a sane baseline for a tool that can run Bash and write files on your behalf.

There are honest limitations. The current release stores credentials in local plaintext, which is acceptable for a single-user desktop tool but would not survive multi-user or server deployments. The project acknowledges this directly in its security documentation. The macOS Apple Silicon build is the only signed release tier; Windows is an unsigned preview, and Intel Macs and Linux are not supported yet. Computer Use is not in this first public build. This is an early public release, and the README says so without apology.

The data-loss boundary is a feature

Maka makes an unusual choice for an agent tool: it deliberately does not migrate legacy data. Conversation history that exists only in older transcript files opens as an empty thread. Pre-existing safeStorage-encrypted credential files are not imported; affected users must re-authenticate. The project calls this “intentional for this release” and flags it before upgrade.

That is the right call, and more projects should copy it. Migrating agent state across storage formats is how subtle corruption enters the record. If the log is the runtime, then the log’s integrity matters more than user convenience. A clean break at the storage boundary preserves the append-only guarantee. The project’s backup and restore path reinforces this: full operational backup uses the SQLite online backup API, binds every file by size and SHA-256, and validates the snapshot’s integrity, foreign keys, and schema registry before restore.

What Maka means for the agent ecosystem

The agent space is crowded with frameworks that promise autonomy and deliver demos. Maka’s contribution is narrower and more durable: a reference architecture for how to record agent execution faithfully. The append-only event log, the separation of context from history, and the single execution authority are patterns that any serious agent platform will need to adopt as agents gain permission to run tools and touch production systems.

The project’s recovery semantics show the thinking is grounded. Runtime continuation is opt-in via MAKA_RUNTIME_SAFE_BOUNDARY_RESUME=1, which enables interrupted-turn resume and startup auto-resume. Those paths may call the configured model provider and consume tokens. Phase 2 provides a durable write-side boundary with fail-closed continuation. Phase 3 reconciliation for indeterminate tool side effects is not implemented; ambiguous tool outcomes remain parked rather than retried. That last point is the honest one. Agents that run Bash and write files will sometimes leave the world in an unknown state. Maka’s answer is to record the ambiguity and not pretend it resolved.

For AI builders, the takeaway is concrete. When you design an agent system, decide what the source of truth is before you decide what the model sees. Maka chose the event log. That choice makes permission decisions, tool results, and termination events first-class citizens rather than incidental transcript entries. It makes cost attribution possible per attempt, which matters as agent usage becomes a budget line. And it makes evaluation a projection over the same record that production runs use, which closes the gap between benchmark behavior and deployed behavior.

Apache Maka is incubating, early, and limited to Apple Silicon for now. But the architectural stance is mature. The log is the runtime, context is not history, and one execution authority governs all surfaces. Those three principles, applied consistently, are what an accountable agent platform looks like. The rest is implementation detail, and the implementation is open source for anyone to inspect.