Context Engineering for AI Agents: What Anthropic Learned Building Claude Tag

Context engineering for AI agents is quietly becoming the harder half of agentic development. Writing a prompt is easy. Deciding what an agent should remember, who it should trust, and when it should act on its own is not. That's the territory Anthropic has been mapping with Claude Code and its newest product, Claude Tag, and it came up in detail in a recent episode of The AI Native Dev with Lamis Mukta, Member of Technical Staff at Anthropic.

The conversation with hosts Guy Podjarny and Simon Maple covered a lot of ground, but the throughline was consistent: as models get more capable, the constraint on agentic development stops being intelligence and starts being infrastructure. Context, memory, and permissions are the new bottleneck, and how you engineer them determines whether an agent is genuinely useful or just noisy.

From single-player to multiplayer agents

To make sense of the shift Claude Tag represents, it helps to plot agentic tools across two dimensions: how session-bound they are, and how many people they serve at once. Claude Code, in this framing, sits closer to single-player. A developer opens a session, states a goal, and manages context for that one thread of work. It's powerful, but it's still built around one person driving one task.

Claude Tag moves the same underlying capability into a different shape. Rather than a session tied to an individual, there's a persistent, shared identity inside a Slack channel that anyone on the team can tag in. Mukta described this as agentic development becoming "less session focused and less single player focused." In practice, that means a support ticket, a product spec, and an engineering review can all happen in one thread, with the agent picking up context from each participant rather than requiring one person to relay it manually.

This matters because a huge amount of coordination overhead in software teams isn't really about coding. It's about making sure the right people see the right context at the right time. A multiplayer agent, done well, absorbs some of that coordination cost instead of adding to it.

Trust tracks capability, not comfort

One pattern that came up repeatedly was how much trust in agents is really a capability question in disguise. Mukta pointed to research showing that the length of task an agent can complete autonomously has been roughly doubling every four months. That exponential curve, more than any comfort-building exercise, is what's letting teams hand agents longer-running, less closely supervised work.

It's worth being precise about what's actually changing. Models are getting better at verifying their own work, not just producing more of it. Behaviors that used to live in the surrounding harness, like checking outputs before returning them, are increasingly built into the model itself. That shift lets teams simplify the scaffolding around an agent over time rather than adding more of it, which runs counter to a common assumption that a more capable model needs a heavier harness.

The practical implication for teams building agentic systems: build for where the model is headed, not where it is today. A harness designed around today's limitations will need constant rework as those limitations disappear.

Permissioning is the part nobody wants to build

The feature that seemed to require the most deliberate design work wasn't the conversational layer. It was permissioning. Claude Tag introduces the concept of agent identity: rather than assuming an individual's credentials the way Claude Code or Cowork typically do, Claude Tag operates with its own permissions and its own keys, scoped per channel.

This solves a specific enterprise problem. A single-player tool that impersonates whoever invoked it is straightforward to reason about but hard to scale to a team, because access effectively expands to the union of everyone who might use it. An agent with its own identity, audited separately from any individual, is easier to constrain and easier to review. Mukta described this as one of the harder architectural changes needed to enable multiplayer behavior at all, and it's a useful reminder that the visible feature (an agent you can tag in Slack) often rests on a much less visible piece of infrastructure (a permission model built for a non-human team member).

Dogfooding as a filter, not a rubber stamp

The origin story here is a good check against over-indexing on early signal. When Claude Code was first shared internally as a side project, the initial Slack post got six reactions. Mukta was candid that this is a reminder that "data isn't perfect" and that there's no clean process for spotting a good product early. It took continued interest from a small number of people before adoption compounded into something like half the company using it weekly.

The lesson isn't that dogfooding doesn't work. It's that dogfooding is a filter applied over time, not a single measurement. Anthropic's internal culture of working publicly in Slack appears to be a meaningful part of why that filter functions at all: agents (and people) can connect context across teams specifically because so much work happens in visible channels rather than private threads.

Where this shows up beyond engineering

Context engineering isn't just a coding concern. Mukta described a marketing team member who started a day by searching for what a terminal even was, and by the end of it had automated a workflow that used to take 30 minutes down to 30 seconds. Anthropic has also built weekly sales briefings and incident-response triage on the same underlying agent infrastructure. In each case, the pattern is the same: someone with a well-defined outcome and a well-scoped set of tools, but not necessarily deep technical skill, was able to delegate real work to an agent.

The next layer: memory that improves itself

One forward-looking piece worth flagging is a feature Anthropic calls dreaming, part of its managed agents offering. As agents run for longer and accumulate memory, that memory can become stale, missing, or actively misleading. Dreaming runs a review pass over session transcripts and memory stores, surfacing hypotheses for what should change and pointing to the specific evidence behind each one, leaving a human to decide which changes to apply.

It's an early example of a broader idea: context engineering for AI agents doesn't stop at initial setup. It's closer to an ongoing maintenance discipline, similar to how teams treat technical debt, except the debt lives in what an agent remembers rather than in its code.

Worth a listen if you're thinking about where agentic tools fit into your own team, well beyond just the engineering org.