Inside the loop: how an AI agent actually works

What the Claude Code source leak tells us about building AI agents that work in production
01.04.2026 — Liquid Team — 6 min read

On March 31, someone discovered that the full source code of Claude Code was sitting right there in the npm registry, waiting for anyone to look. No exploit needed: someone forgot to add *.map to the .npmignore, and the bundle's sourcemaps included the original, untouched code. 785KB of TypeScript. System prompts, internal feature flags, codenames for unannounced models, the entire architecture of one of the most widely used code agents today. All in plain sight.

What makes the leak interesting isn't the gossip (though there's that too), but what it reveals about how you build an agent that actually works. Because Claude Code isn't a pretty wrapper over an API. It's a system with over forty tools, multi-agent orchestration, persistent memory across sessions, and different operating modes depending on context. Worth popping the hood.

The model doesn't act. The loop does.

A language model does one thing: given an input, it generates text. Useful, sometimes surprisingly so, but it has a limit that no amount of parameters can dodge: everything it can do fits in a single response. If the task is to run code, read the error, fix it, run again, and verify, the model can only describe how it would do it. It can't actually do it.

Agents break that limitation with an idea that's almost disappointingly simple: put the model in a loop. Instead of one response, the model receives the current context, decides what to do, executes an action on the real world, observes the result, and starts over. Repeat until the task is done (or until something breaks in an interesting way).

This gives the model something it doesn't have in question-answer mode: the ability to react. It can fail, read the error, adjust. It can explore a codebase it's never seen before touching it. It can maintain a coherent thread across dozens of intermediate steps. The pattern is old — programmers will recognise it as a REPL on steroids — but applied to an LLM it radically changes what's achievable.

And how does it act on the world? Through tools: functions the model can invoke by generating a structured call with the parameters it wants to use. The model never executes code itself. It decides what to execute and with what arguments, and the runtime does the dirty work. The selection of available tools defines what kinds of problems the agent can tackle, and this is where Claude Code gets interesting. It has the obvious ones — run shell commands, read and write files, search the codebase — but also tools for analysing a project's semantic structure or launching sub-agents and delegating work to them. And they're not all active at once: they're filtered by context, permissions, and user configuration.

Memory is the hard problem

Here's a detail that tends to get overlooked: the model remembers nothing between calls. Zero. Every time the loop turns, the model receives the entire context from scratch: the original instruction, the action history, the results obtained. It's like a brilliant surgeon with anterograde amnesia who needs the entire patient file re-read every time they look up.

For short tasks this doesn't matter. For long ones, the text pile grows until it saturates the context window, and then you have to choose: what can you afford to forget?

The practical solutions are two: periodically compress the history (summarise what happened, discard details that no longer matter) or externalise memory to files the agent can consult when needed. Claude Code does both, but the more curious one is the second. For inter-session memory it has a subsystem called Dream: a secondary agent that runs in the background after each session, consolidates what was relevant, removes information that was contradicted during work, and maintains the index in Markdown files under a maximum size. No vector database. No embeddings. Plain Markdown with an agent tending it. It's a deliberately simple solution, and probably works precisely because of that.

The problem with delegation

Some tasks are better solved by working their parts in parallel rather than in sequence. That's where the multi-agent pattern appears: a coordinator that decomposes the problem, launches workers in parallel, and synthesises the results when they return.

Sounds clean. In practice, the most common trap is vague delegation. The coordinator passes the problem to the worker saying something like "analyse this and decide what to do", trusting that the worker will figure it out. The result: loops that spin without converging, agents passing the problem back and forth like a hot potato, and tokens burned while nobody makes progress.

Claude Code addresses this head-on: in the coordinator mode's system prompt, it's explicitly forbidden to say "based on your findings, decide what to do". The coordinator must read each worker's actual results and specify exactly the next step. No lazy delegation. It's a constraint that seems minor but marks the difference between a multi-agent system that converges and one that burns.

How much rope do you give it?

The last piece, and the most delicate, is autonomy. An agent that asks for confirmation at every step is as useful as an intern who interrupts you every thirty seconds. One with no controls at all can delete your production database while you're getting coffee.

The reasonable solution is to classify each action by risk level. Read a file: automatic. Run a test: automatic. Write to protected files or execute something destructive: ask permission. Claude Code has protected files by default, risk classification by action type, and a classifier that learns from the session's history to handle the grey areas.

The internal name for that classifier is YOLO. No comment on the team's sense of humour, but the mechanism is the piece that lets you trust real tasks to something with bash access without ending up with your heart in your throat.

What matters isn't the model

What the leak shows — beyond the codenames and the juicy details — is something that should be obvious but that the hype makes easy to forget: a production agent is not, primarily, a more powerful model. It's an engineering system around the model. What tools it has. How it manages context as it grows. How granularly permissions are controlled. How precisely instructions between agents are formulated.

The loop itself is trivial. What's hard, and what's interesting, is everything around it.

Typescript

💬 Let's talk about your project. Book an initial call