Apache Maka's Durable Agent Workspace

Apache Maka (Incubating) is a local agent workspace for completing real work, and this opening asks a practical question: what must an agent remember when its work is more than a single answer? The useful understanding is not just what Maka looks like on screen, but how its model, tools, user decisions, runtime, and evaluation surfaces remain connected when a task runs for many steps, encounters a failure, or needs to be inspected later.

That question matters because an agent is not merely a chatbot with a longer reply. It can search a project, read files, run commands, ask for permission, change the workspace, receive new evidence, and decide what to do next. Each step changes the situation the next step must understand. If the system keeps only the visible conversation, it may preserve the story while losing the execution that produced it.

Maka’s answer is an architectural theme that will guide this series: preserve facts first, then derive the view each consumer needs. The durable facts are what the model, tools, user, and runtime actually did. The views are the forms needed by a screen, a later model request, a recovery procedure, a multi-agent schedule, or an evaluation report. Keeping those roles separate is what lets Maka be ambitious about automation without pretending that a summary, notification, or retry is the same thing as evidence.

A real task is a chain of decisions

Imagine asking Maka to find failing tests, fix the cause, and run the suite again. The visible result may eventually be a short explanation and a changed repository. Between those two points, however, the agent might search for test names, inspect a configuration file, ask to write outside its initial boundary, receive approval, edit a file, run a command, parse a failure, and change direction.

A transcript that records only the initial request and final answer hides the decisions that make the answer meaningful. It does not say which search results the model saw, which command actually ran, whether a permission request was approved, whether an edit completed before a crash, or whether the final test result arrived before the run was stopped. Those are not incidental details. They determine what the agent is allowed to believe about the workspace and what a later execution may safely do.

This is the difference between a conversation and an execution history. Conversation is one useful representation of the work, but it is not the whole work. Maka describes every model message, tool call, permission decision, and termination fact as part of a retained Runtime Event history. The history is meant to remain inspectable even when the model’s working context is shortened or a product surface shows only a compact projection.

The distinction also explains why “the model remembers” is a poor mental model for long-running work. A language model is called repeatedly; it does not provide a persistent, runtime-readable memory that automatically carries the whole task from one invocation to the next. The runtime must reconstruct the relevant context. If it cannot distinguish a user instruction from a tool result, a requested permission from an approved one, or an unfinished operation from a completed one, its next decision is built on ambiguous ground.

The log is the center, not the screen

Maka’s central design is the Runtime Event Log. It is an ordered record of semantic facts about an interaction, not just a debugging stream. A fact may contain user or model content, model thinking, a function call, a function response, an error, a usage action, a permission action, or a terminal status. It also carries the identities and correlations needed to tell which Session, Turn, Run, and tool interaction the fact belongs to.

Those identities answer different questions. A Session is the longer-lived interaction. A Turn is a user-visible exchange. A Run is one concrete execution attempt inside that exchange. A tool call has its own correlation identity so that a response can be paired with the call that produced it. The distinctions become important when a process stops, a client reconnects, or a new Run continues from a verified boundary. Without them, “the task,” “the request,” and “the attempt” collapse into one label, and recovery has no reliable way to describe what happened.

The log also gives Maka a single place to establish the end of an execution. A Run ends when its terminal RuntimeEvent is durable. It does not end merely because the last visible message sounds complete, because a callback arrived, or because a provider stream went quiet. This rule protects against races: a user stop should not be overwritten by a late completion, and a stream that exhausts without a terminal fact should not be silently presented as success.

Once the facts are retained, different consumers can read them differently:

  • the interface can show conversation, tool activity, permission waits, and Turn status;
  • the next model request can assemble the history that its provider can legally consume;
  • recovery can inspect the committed prefix and determine whether a Run ended cleanly;
  • future projections can reinterpret the same events without rewriting the original record;
  • an evaluation layer can measure a Host-executed subject without becoming the owner of Runtime execution.

These are not five competing histories. They are five views over related durable evidence. A screen may be optimized for clarity, a provider request for context limits, and a recovery procedure for uncertainty. None should silently become the authority for the others.

This distinction changes how a reader should interpret an agent’s confident answer. If Maka says that a test passed, the important question is not only whether that sentence appears in the conversation. It is whether the recorded execution contains the relevant command, its result, the surrounding tool and permission facts, and a terminal fact that explains how the Run ended. The answer is a useful view of the work; it is not allowed to erase the evidence behind it.

The same principle permits different levels of detail without creating contradictions. A user interface may show one compact tool card, while a later model request receives a bounded representation, and a diagnostic view retains the correlation needed to inspect the original event. Those representations can differ because they serve different purposes. They become dangerous only when a convenient representation is treated as the thing that actually happened.

This is also why the phrase “complete record” needs a careful boundary. Maka’s design aims to retain the semantic facts needed to reconstruct an execution, but that does not automatically capture every provider request byte for byte, freeze every future projection, or prove that every external effect occurred exactly once. The strength of the architecture is not that it eliminates uncertainty. It gives uncertainty a place in the model instead of hiding it behind a polished answer.

flowchart LR C["Desktop / TUI / CLI / Bot"] --> H["Runtime Host"] E["Eval"] --> H H --> R["Session / AgentRun"] R --> M["Model loop"] R --> T["Tools and workspace"] M --> L["Runtime Event Log"] T --> L L --> U["UI and Session view"] L --> X["Next model context"] L --> Q["Recovery and continuation"] H --> V["Eval attempts and results"]

The diagram is deliberately simple. It does not mean every client receives every raw event, or that Eval can bypass the Host. It shows the relationship that matters: product entry points share one execution authority, the execution produces durable facts, and the surrounding surfaces derive bounded representations from that authority.

One subject, several entry points

Maka presents itself as a high-performance agent workspace, but its subject is not limited to the desktop window. Desktop, TUI, CLI, bots, and evaluation clients are different ways to reach the same Runtime Host. The Host coordinates Session and Turn identity, model and tool execution, permissions, lifecycle, and events. This prevents each entry point from inventing its own interpretation of a task or opening a second Runtime over the same state.

That arrangement is especially important for a local workspace. Maka keeps sessions, settings, and run records on the user’s machine, while the user supplies a cloud API, a local model, or a compatible gateway. Local storage improves control over retained state, but it does not mean that no information can leave the machine: a selected model provider, a tool, or an enabled integration may still receive data under its own rules. The architecture therefore has to treat retention and transmission as separate questions.

Evaluation belongs beside, not inside, the Runtime. Maka’s Eval layer describes experiments, subjects, tasks, repetitions, budgets, verifiers, attempts, and results. A Maka subject asks the Runtime Host to execute its work; an external subject follows a different adapter path. An experiment can then record score, usage, cost, duration, status, and artifacts without turning benchmark bookkeeping into a second execution authority. This separation is what makes “the agent completed the task” different from “the experiment selected this result under its verifier.”

The same separation shapes the product’s claim of a complete record. It is a claim about retaining the facts needed to reconstruct and inspect an execution, not a promise that every provider request can be regenerated byte for byte, that every outside effect is exactly once, or that every in-process safety check contains an adversarial model. Those stronger claims require different evidence, and Maka’s own architecture documents make the limits visible.

The project is also explicit about maturity. The repository identifies Maka as Apache Incubating, says that it has not yet made an Apache release, and describes desktop nightlies as developer and tester artifacts rather than production releases. Data formats, commands, and experimental capabilities may change. That qualification does not make the architecture uninteresting; it tells the reader how to interpret it. The right question is not whether a feature label sounds reassuring, but which facts it records, who owns them, when they become durable, and what remains uncertain.

That is the foundation for understanding Maka. The next question is therefore precise: when the model/tool loop begins, what exactly enters the Runtime Event Log, and how do those facts become a history that can support the interface, the next model request, and a later recovery decision?

References