A share landed on my feed that I couldn't stop thinking about: someone open-sourced an agent project called Morphz, and the pitch was a different way to organize context. Instead of leaning on session-history compaction, the agent maintains its own structured context through what they call context transactions. It decides what to keep, what to revise, and what to retire. The example that stuck with me was mundane in a good way: after processing a build log, the agent records its failure diagnosis, updates the blocking items, and moves the already-handled log out of active context in the same transaction. The raw log stays around and can be recalled later.
That framing is worth stealing, or at least stress-testing. So I sat down and built a reproducible version of the idea to see where it holds up and where the marketing gets ahead of reality.
Why compaction bugs people who run long agents
If you've operated an agent past a few dozen turns, you know the failure mode. The context window fills, something summarizes the history down, and you lose the exact detail you needed three steps later. Compaction is lossy by design, and you rarely get a say in what gets dropped. You also can't reach in and correct a bad assumption the agent baked into its rolling summary. It's a black box that quietly rewrites the agent's memory.
The Morphz framing flips that. Treat the active working context as a set of explicit records, not a transcript. The agent mutates those records deliberately. Nothing important vanishes because a token budget got tight; it moves to a recall tier instead.
I want to be honest about one thing up front: the strongest version of this pitch is "the agent autonomously maintains its context." That autonomy claim stays unverified in my build. What I actually implemented is an agent that maintains context when I give it the right tools and prompts, under conditions I controlled. Whether it reliably makes good keep/revise/retire calls across messy real workloads is exactly the part that needs long-run evidence I don't have yet.
The two-tier store
The design splits into an active tier and a recall tier.
Active context lives in a plain relational table. Each record has an id, a type (fact, decision, blocker, open question), the content, and a status. The agent doesn't stuff a growing transcript into the prompt. It reads the current active records, and every change happens as an explicit write: insert a new decision, revise a blocker, flip a handled item to retired. On the platform side I built this on the SQLite databases, which matters for a reason that's easy to underrate. When the agent gets something wrong, I open the SQLite editor and fix the row by hand. No prompt gymnastics, no re-running a summarizer and hoping. The context is data I can inspect and correct, which is the whole point.
When a record retires, it doesn't disappear. It gets embedded and pushed into a vector store so the agent can pull it back later by similarity. That recall tier runs on the LanceDB knowledge base. The active table stays small and cheap to load into the prompt; the long tail of processed logs, resolved blockers, and old diagnoses sits in the vector store until a query surfaces it. The recall step is just another tool the agent can call: "search retired context for anything about this error signature."
The loop, in Python
The agent loop itself is ordinary Python. On each turn it loads active records, builds the prompt, calls the model, and the model responds with either a normal answer or a tool call. The tools are the interesting bit, because they're all context operations plus the usual work tools:
- `add_record`, `revise_record`, `retire_record` for active context mutations
- `recall` for querying the vector store
- whatever domain tools the task needs
I wrapped the mutation tools so a set of related changes commits together, which is the transaction idea in practice. Retiring the handled log and updating the blocker land as one unit, so you never get a half-applied state where the log is gone but the blocker still points at it. I built and ran this on the platform's Python execution, and the model calls go through the Model Center APIs for models already available there. When I wanted to expose the loop to a small front end, API Endpoint Hosting handled the endpoint without me standing up separate infrastructure. If you're doing serious AI agent development, keeping the loop, the store, and the model access in one place cuts a lot of glue code that usually rots.
One boundary worth stating plainly: this all assumes the models you want are already in the Model Center. If your target model isn't available through the platform, that's outside what I can wire up here, and you'd need a different plan for model access.
Model choice is a real variable, not a footnote
While testing, the cost-and-latency question kept intruding. One developer's comparison made the point better than any benchmark: same task, same prompt, one model finished in about ten minutes while another ran over two hours before they killed it. For an agent that loops many times per task, that gap compounds hard. A queryable context store helps because it keeps each prompt lean, so you're not re-paying for a bloated transcript on every call. But the underlying model still dominates your wall-clock and your bill, and I'd treat model selection as a first-class knob, not something to settle once and forget. Region restrictions are also real; I saw reports of location-based API errors, which is the kind of thing that quietly breaks a deployment you thought was done.
Who actually wants this
The demand signal isn't just agent hobbyists. I noticed an early-stage team hiring for exactly this shape of problem: organizing scattered sources into a queryable, analyzable, traceable data network, then putting an agent on top to help people navigate it. That's the same instinct as the two-tier store, scaled to a domain. When your context is structured records instead of a compacted transcript, "traceable" stops being aspirational. You can point at the row, see when it was added, and see when it retired.
If you run long agents, the takeaway I'd offer after this build is narrow and practical. Make your agent's memory into data you can query and edit. Keep the active set small, push the rest into recall, and commit related changes together. Just don't oversell the autonomy part until you've watched it behave over real, long-running work. I haven't, yet, and I'd rather say so than dress it up.