The day Pi (an Agent framework) released its harness v2 documentation, the Maka internal group went quiet for a few seconds.

It wasn’t amazement—it was recognition. Most core contributors to Maka have a background in databases. They found that the architecture they were building was almost identical to what was described in Pi’s new documentation:

- Persistent facts → derived runtime state → derived model context → derived UI → re-computation after crash

- Tool boundaries are also consistent: write execution intent first, then perform side effects, then write the result

Pi’s notation is `tool_started intent → execute → tool-result entry`, while Maka’s is `T1 toolDispatch → execute → T2 function_response`.

The two projects started from completely separate paths, yet ended up with nearly identical architecture designs. This says a lot: a consensus is forming at the Agent harness layer. And this consensus is nothing new—it’s the same paradigm from operating systems and databases: write-ahead logging, event sourcing, resumable persistent operations. There is no silver bullet in engineering; after going in a huge circle, the core principles remain the fundamental basics of software engineering.

Maka is one concrete implementation of this approach ([Apache Maka](https://github.com/apache/maka)). It is currently incubated at Apache, positioned as a local-first Agent workspace. Model messages, tool calls, and tool results are all written as resumable execution facts. The UI and the next model call are just projections of these facts.


Data stays locally by default. Models can come from cloud APIs, local models, or compatible gateways. Any tool that writes files or executes shell commands must pass through a sandbox boundary. Short context does not equal deleting history—Maka can omit old tool outputs while retaining the provenance of all events. All entry points—desktop, terminal, Eval—run through the same Runtime Host.

The storage layer is powered by SQLite, with `runtime.sqlite` storing active records. Crash recovery and interruption recovery are optional features. Currently, an early public release is available for macOS Apple Silicon; Intel and Linux are not yet supported, and Windows is available as an unsigned preview. The official Apache release is not yet out, so you can only run it by building from source.

Netizen Yihan Zhu commented: Building agents is essentially redoing software engineering from scratch, from loop engineering to graphs. The deeper you go, the more you realize it's just the core of engineering. DISCOVER Robotics also noted that new agent architectures always circle back to very old software engineering ideas.

However, netizen @Gregor raised a question: When a "transaction" becomes an LLM call that produces different results every time it fails, can the consistency guarantees of databases still be mapped to this scenario? Has Pi v2 really solved this problem, or is it just borrowing the terminology? This question deserves a separate article.

The design goal written in Maka's repository is: Your work. Your agent. This is not an empty slogan. Agent harness is still in its early days, but the direction is already clear. If database papers already gave us the answer, what matters next is execution.