Happy to share our work with you. The paper presents our system architecture, provides links to the sources, and compares our approach with solutions such as AWS Bedrock AgentCore, Cloudflare Agents, Google AX, and others.
Decomposition is definitely needed as tasks become more complicated. I’d prefer to define the desired state, get a decomposed breakdown of the gap between the current and desired states, and let agents figure out how to close it themselves, rather than manually operating each intermediate task. As a project owner, I’d love to work at the desired-state level.
Every few sessions I'd find myself typing the same thing again. "Auth token expiry is 900s not 3600s." "Don't use duck typing here, the object structure is already defined." After the fifth time I stopped blaming myself for not writing it down and started thinking there has to be a better way.
CLAUDE.md is manual — you maintain it. MEMORY.md is automatic but it only gets read once at session startup, it's scoped per repo so your cross-project preferences don't carry over, and once it gets long enough only the top N lines are read. Older notes just silently disappear from context regardless of how important they are. I had a note about a critical config value fall off the bottom and cost me an hour.
So the core idea: instead of a flat file, use a small LLM as memory. Store notes in the LLM's context window (system prompt), prompt it with what the agent is currently doing, and get back only the hints that are actually relevant right now. Not at startup — right before each tool call.
You write notes like this:
```
cmr-memory write "auth token expiry is 900s not 3600s" --when "working on auth, tokens, config.ts"
```
The `--when` field is a plain-language activation condition. The memory LLM reads the conversation transcript and decides if the condition matches the current context. It's not keyword matching — a note tagged "working on authentication" will surface when the agent is editing JWT middleware even if neither word appears in the recent transcript.
The tricky part is making this fast enough to run on every tool call without being expensive. One LLM call over all your notes doesn't scale — attention degrades in long contexts, costs add up fast, and you'd be waiting 5 seconds before every file read. The solution is splitting notes into small chunks and processing them in parallel with Haiku (fast, cheap, good enough for this job — you don't need Opus to decide if a note is contextually relevant). Each chunk lives in a stable system prompt that gets cached by Anthropic's prompt caching, so after the first call against a chunk it's mostly served from cache.
There's also a deduplication step — once a hint is in the conversation it's already there, so re-injecting it next tool call just bloats context for no reason. The system extracts what's already present and skips anything redundant.
The whole thing wires in via Claude Code's PreToolUse/PostToolUse hooks. PreToolUse fires before every tool call, reads the transcript, runs retrieval, injects hints. PostToolUse sends a short nudge asking if anything worth saving just happened — the agent decides whether to write a note, nothing is forced.
Git worktrees have become the default recommendation for running parallel AI coding agents (Claude Code, Codex, Cursor, etc.), and I get the appeal — they're just directories, zero orchestration, instant setup. I've seen people running 5 worktrees in a tmux grid with a separate Claude instance in each pane and it looks great on paper.
But I keep running into the same wall: worktrees isolate code, not the environment. Port 3000/5432/8080 still gets fought over. Two agents installing conflicting deps stomp on each other. Secrets in the host env leak into every subprocess any agent spawns.
Containers fix all of this cleanly, but now you're managing image lifecycles, cleanup policies, and orchestration — which is a lot of overhead for what might be a solo dev workflow.
Curious what people have actually found:
1/ At what scale or workload type did worktrees start visibly breaking down for you?
2/ Has anyone found a middle ground that doesn't require full container orchestration?
3/ For those who moved to proper sandboxes: was the management overhead actually as painful day-to-day as it sounds upfront?