The reliability problem in AI agents is almost never the model

After a year of putting AI agents with Yempik into production, here is the boring truth I keep running into: when an agent is unreliable, the model is almost never the reason. The model is the easy part. Everything around the call is where things break.

The model is the easy part

Give a good model a clear task and the right context, and it does the task. That part has gotten very good. The failures I see in production are somewhere else entirely. They come from the state around the call: the tool that timed out and got retried twice, the decision that was made three sessions ago and quietly got re-litigated, the constraint everyone agreed on that the agent never saw because it lived in a different chat.

Reliability is a state problem, in two halves

The state around an agent has two halves, and most teams only solve one.

The first half is execution state: retries, idempotency, policy enforcement, durable state for the API calls. This is real engineering and people are building good tools for it.

The second half is the operating state of the work itself: what was already decided, what is still open, what changed since the last session, what to do next, what must not be retried. This is the half that silently rots. The agent finishes a session, the context window resets, and that state goes with it unless something outside the window is holding it.

Native memory helps, but it is not a process

In 2026 the models do have memory, and for remembering facts it is genuinely useful. We use it. But memory is not a process. It does not give you a decision log, a list of open questions, a readable handoff between sessions, or a closing routine. It remembers that you exist. It does not run your work.

So you end up being the memory by hand. Every new chat, you re-explain the project, repeat the constraints, and hope the model reconstructs the part you actually needed.

What we built

cowork-os is the workspace layer for that second half. It keeps the operating state in plain Markdown that your Claude Cowork project reads and that you can open and correct: decisions, open questions, project state, routines, and a closing habit we call Memory Update. It is not a memory engine. It sits next to one. One command to install, MIT licensed, and your files stay yours.

The point is not to remember more. The point is to hand off the right operating context to the next session, in files you control.

The habit that stops the rot

Here is the concrete part, and it came straight out of a public back-and-forth with two other builders this week.

A decision file rots the same way a CLAUDE.md does. The reason is that the same entry is two different things at two different times. "We tried approach X and reverted it" is live policy the day after: do not reattempt X. Months later, once the constraint that killed X is gone, the exact same line is just history, and worse, it is now a stale constraint actively misleading the agent.

So the real job of the file is not only to separate policy from history. It is to demote an entry from policy to history when its condition expires. And that demotion will never happen on its own. A human remembering to move lines is the thing that always fails.

The fix is a fixed review step at the close of every task: re-justify what stays as active policy, let the rest fall to a dated log. That is exactly what the Memory Update habit does. It is a small, cheap pass, and it is the difference between a file you trust and a file that quietly lies to your agent.

Try it

cowork-os is live on the Peerlist Launchpad this week. If you push real work through Claude, I would love for you to try it and tell me where it breaks. Open source, MIT, one command. Built in public at Yempik, yempik.com.