Your Claude Code sub-agents keep losing the thread. Give them one shared record.

Claude Code agents come in a few shapes, and it is worth being precise before we get to the part that breaks. There are sub-agents: specialized configurations you define in your .claude/ folder, each with its own instructions and tools, that the main session hands work to. There are agent teams: independent Claude Code sessions that coordinate through a shared task list and peer messaging, with one session acting as lead. And there is the plain case of running two terminals at once, each a full Claude Code session working the same repo.

All three are genuinely useful, and the setup guides for them are good. What none of the setup guides tell you is what happens on the second day, when the context window that held all the coordination fills up, compacts, and takes the plan with it. That is the problem this post is about, and it is not a prompting problem.

#What actually breaks when you run more than one agent

A single Claude Code session holds its state in the context window. That works until it doesn't: the window fills, auto-compact runs, and the running summary of what got decided and why gets squeezed to make room. The next session starts cold. One of the highest-voted write-ups on this exact topic calls it "context amnesia," and the fix people reach for is almost always some external record the agents read from and write to, because in-context memory resets at the session boundary by design.

Now run a team. Sub-agent A refactors the auth module and moves on. Sub-agent B, spun up an hour later in a fresh session, has no idea A already did that, because the only place that knowledge lived was A's context window, which is gone. The coordination layer Claude Code ships, the shared task list, keeps the team in sync while the team is alive. It is not where the work goes to be remembered after the session ends. So the failure mode is not "the agents are dumb," it is "the agents have nowhere durable to file what they did."

A developer in a recent thread described building exactly the missing piece by hand: a local API for the full issue lifecycle so that "the agent never polls GitHub, it just checks local state and the sync layer handles the rest." That instinct is right. The agents need one fast place to read and write the state of the work, separate from any one session's memory. The question is whether you build it or point at one that exists.

#The shared record, and where it should live

An issue is the cheapest durable unit of that record. It has an owner, a status, a priority, and a comment thread, and it survives every context reset because it lives outside the model entirely. When an agent files an issue as it works and comments on it as it makes decisions, the next agent, or the next session of the same agent, reads the current state instead of reconstructing it from a summary that got compacted away.

Radial is that record, wired so agents can drive it directly. It ships a real CLI, a plain REST API, and an MCP server, all against the same issue lifecycle, so whichever way your agents reach it, they read and write the same state. Point Claude Code's sub-agents at it once and the shared task list stops being the only coordination surface: the durable one is the tracker.

Here is a sub-agent reading its queue and filing what it finds, using the CLI (every command takes --json, so the output pipes straight into the next step):

# The agent reads what's assigned to it, in progress, as structured JSON
radial list --assignee me --status "in progress" --json

# It fixes the bug, closes the issue with a note the next session can read
radial close RAD-219 -m "Root cause: race in the token refresh. Fixed in #482."

# It found a second problem while in there, so it files that too
radial create "Auth retry loop on 401" -p high -l bug -a me --json

Nothing in that loop is Claude-specific. The same three verbs run from a REST call in CI, from the MCP server another agent is connected to, and from your own terminal, against one shared record. That is the point: the state of the work does not live in any single agent's head.

#Why the record is the tracker and not a memory feature

There is a real distinction here, and it matters for honesty. Radial is not a memory layer, a context store, or a retrieval system for your agent. It does not persist your agent's context or try to be a smarter CLAUDE.md. It is a fast issue tracker that agents can drive over CLI, REST, and MCP, and the durable record is a side effect of agents filing and updating issues the normal way, not a feature bolted on top.

That line is deliberate. The intelligence stays in your agent, your model, your keys. Radial holds the record. There is no copilot in it, no AI summary, no auto-triage, and no AI credit meter, because your agent already does that part and you already pay for it once. The Plain Software Pledge is the binding version: the day Radial ships a copilot, meters your usage, or charges you for AI you didn't ask for, your subscription is free.

And because every agent credential is a client of the API, not a billed seat, running a team of sub-agents against Radial costs nothing extra. The price is $50 per user, per year, flat, billed annually, for the humans. Agents ride free. That is not a promotion; it is the structure. A fleet of ten sub-agents all writing to the same tracker is still just the humans on the workspace.

#FAQ

#What are Claude Code agents?

There are two related things. Sub-agents are specialized configurations you define in your .claude/agents/ folder, each with its own system prompt and tool set, that the main Claude Code session delegates tasks to. Agent teams are independent Claude Code sessions that coordinate through a shared task list and peer messaging, with one acting as lead. Both let you split work across specialized or parallel workers instead of one monolithic session.

#How do Claude Code agent teams stay in sync?

While the team is running, sessions coordinate through Claude Code's shared task list and direct messaging. That keeps them aligned in the moment. What it does not do is preserve the work after the sessions end, so for anything that needs to survive a context reset or hand off to a later session, you want an external record, an issue tracker the agents file into, that lives outside any one session's context window.

#Why do my Claude Code agents forget what other agents did?

Because each session's knowledge lives in its context window, and windows fill up and compact. Once a summary gets squeezed out or a session ends, that knowledge is gone unless it was written somewhere durable. Two agents in separate sessions have no shared memory by default. The fix is a record outside the model: an issue with a status and a comment thread that any session can read the current state of.

#Can Claude Code agents update an issue tracker automatically?

Yes, if the tracker exposes the right surface. Connect Radial's MCP server or hand your agents the CLI, and a sub-agent can search its queue, create issues, comment as it makes decisions, and close them when done, all in its own loop. See give Claude Code access to your issue tracker in 5 minutes for the MCP setup.

#Does running a team of agents against Radial cost more?

No. Agent credentials are API clients, not billed seats. You pay $50 per user, per year, for the humans on the workspace, locked at the rate you join, and a team of ten sub-agents writing to the same tracker adds nothing to that.

#The short version

Claude Code agents and agent teams are worth using, but the moment you run more than one, the coordination that lived in the context window becomes the thing you lose. Give the agents one durable record to file into, an issue tracker they drive over CLI, REST, and MCP, and the plan stops dying with the session.

See the full tool list and the CLI verbs on the developers page, or read an issue tracker your agents can actually drive for the system-of-record argument in full.