I kept losing the state of real engineering work inside long agent conversations. Cards started as a way to fix that, but they changed much more than I expected.
I kept asking the same question
I'd have several agents running in tmux, switch back to one after an hour and immediately ask myself: what was this agent doing again?
The answer was technically in the conversation. Somewhere. The original request was near the top, then investigation, tool calls, questions, decisions, failed approaches, implementation and probably a few unrelated messages from me.
That works reasonably well when there is one agent and you're sitting there with it. It gets much worse when there are five, ten or more sessions and you're moving between them.
A conversation is useful execution context. I don't think it is a good durable representation of the work.
The problem gets worse when the code is real
I'm not using agents only for throwaway prototypes. The code I submit is my responsibility and gets reviewed by my peers.
If somebody asks why a change was made, I need to understand the answer. I need to know what the agent thought the task was, what assumptions it made, where it changed direction and why the final implementation looks the way it does.
"The agent did it" isn't an engineering explanation.

So I moved the state out of chat
In Grid, the durable unit of work became a Card. Underneath, it is basically Markdown.
The conversation can still be noisy. The agent can investigate, use tools, make mistakes and recover. But the Card should stay concise enough that I can open it later and understand the work quickly.
- What is this Card actually trying to accomplish?
- What has changed so far?
- Which assumptions matter?
- Did the implementation deviate from the plan?
- What still requires my attention?
- How are we going to prove this is finished?
The conversation is where the agent works. The Card is where the state of the work lives.
Fresh agents became much easier
Once the task state isn't trapped in one context window, I don't need one giant conversation to own a task from beginning to end.
A Prepare agent can investigate and write a useful plan. A fresh Doing agent can implement it. Review can inspect the result without needing the implementation agent's entire history. Verification can use the checks recorded earlier.
This has a second benefit: each agent gets context for the job it is doing instead of inheriting every token from every earlier stage.
The Card is also a handoff to me
The same artifact that lets one agent hand work to another also lets the system hand work back to me.
That's important when many agents are running. I don't want ten streams of consciousness. I want a small number of clear interruptions: this assumption needs a decision, this implementation is ready to review, this verification failed.
Markdown was intentionally boring
I like that Cards are basically files. They can be inspected, changed, diffed and understood without inventing another opaque state store for the important parts of the work.
That doesn't mean Markdown magically solves context. The hard part is deciding what deserves to survive and what should stay in the transient conversation.
I'm still changing that constantly.
What I think I was actually solving
At first I thought I was building a nicer way to manage agent sessions.
I now think the bigger problem is preserving engineering state while execution becomes increasingly disposable.
Agents will change. Context windows will change. Providers will change. A task still needs a durable description, decisions, evidence and a definition of done.
That is the part I don't want to lose inside chat.
Comments