Designing agentic loops
simonwillison.net
simonwillison.net
exec bwrap \
--ro-bind /usr /usr \
--ro-bind /etc /etc \
--ro-bind /run /run \
--ro-bind "$NODE_PATH" /node \
--proc /proc \
--dev /dev \
--symlink usr/lib64 /lib64 \
--tmpfs /tmp \
--unshare-all \
--share-net \
--die-with-parent \
--new-session \
--bind "$HOME/claude" /claude \
--bind "$HOME/.claude.json" /claude/.claude.json \
--bind "$HOME/.claude" /claude/.claude \
--setenv HOME /claude \
--setenv PATH "/node:/claude/bin:/usr/bin" \
--bind "$(pwd)" /work \
--chdir /work \
/claude/bin/claude "$@"The trouble with sandbox-exec is that it’s control over network access is not fine grain enough, and I found its file system controls insufficient.
Also, I recently had some bad experiences which lead me to believe the tool MUST be run with strict CPU and memory resource limits, which is tricky on macOS.
It looks like linux vms, which apple's container-cli (among others) covers at a basic level.
I'd like apple to start providing macOS images that weren't the whole OS.. unless sandbox-exec/libsandbox have affordance for something close enough?
You can basically ask claude/chatgpt to write its jail (dockerfile) and then run that via `container` without installing anything on macos outside the container it builds (IIRC). Even the container-cli will use a container to build your container..
The main issue I had is that most dev tools aren't sandbox compatible out of the box and it's Apple specific tech. You can add SBPL exceptions to make more stuff work but why bother. Containers/Linux VMs work everywhere.
It's a very far cry from bwrap.
My agent has a few other tricks up its sleeve and it's very new, so I'm still experimenting with lots of different ideas, but there are a few things I noticed.
One is that GPT-5 is extremely willing to speculate. This is partly because of how I prompt it, but it's willing to write scripts that try five or six things at once in a single script, including things like reading files that might not exist. This level of speculative execution speeds things up dramatically especially as GPT-5 is otherwise a very slow model that likes to think about things a lot.
Another is that you can give it very complex "missions" and it will drive things to completion using tactics that I've not seen from other agents. For example, if it needs to check something that's buried in a library dependency, it'll just clone the upstream repository into its home directory and explore that to find what it needs before going back to working on the user's project.
None of this triggers any user interaction due to running in the container. In fact, no user interaction is possible. You set it going and do something else until it finishes. The model is very much to queue up "missions" that can then run in parallel and you merge them together at the end. The agent also has a mode where it takes the mission, writes a spec, reviews the spec, updates the spec given the review, codes, reviews the code, etc.
Even though it's early days I've set this agent missions that it spent 20 minutes of continuous uninterrupted inferencing time on, and succeeded excellently. I think this UI paradigm is the way to go. You can't scale up AI assisted coding if you're constantly needing to interact with the agent. Getting the most out of models requires maximally exploiting parallelism, so sandboxing is a must.
I'm working on my own dumb agent for my own dumb problems (engineering, but not software development) and I'd love to hear more about the tricks you're spotting.
What are your thoughts on checkpointing as a refinement of sandboxing? For tight human/llm loops I find automatic checkpoints (of both model context and file system state) and easy rolling back to any checkpoint to the most important tool. It's just so much faster to roll back on major mistakes and try again with the proper context, than to try to get the LLM to fix a mistake, since now the broken code and invalid assumptions are contaminating the context.
But that relies on the human in the loop deciding when to undo. Are you giving some layer of your system the power of resetting sub-agents to previous checkpoints, do you do a full mind-wipe of the sub-agents if they get stuck and try again, or is the context rot just not a problem in practice?
At the moment my agent is pretty basic. It doesn't detect endless loops. The model is allowed to bail at any time when it feels it's done or is stuck, so it doesn't seem to need to. It doesn't checkpoint currently. If it does the wrong thing you just roll it all back and improve the AGENTS.md or the mission text. That way you're less likely to encounter problems next time.
The downside is that it's an expensive way to do things but for various reasons that's not a concern for this agent. One of the things I'm experimenting with is how very large token budgets affect agent design.
I wouldn't worry. There's so much attention focused on this space right now that any ideas I have are being had simultaneously by hundreds of other people. I just discovered a tool called Sculptor that's got a pretty UI of the type I wanted for the container management; they are probably the ones to watch for this kind of agentic approach.
Something I have been struggling with is that for "go and look and find this and join it and then see" kind of exercises really seem to go way way off the rails and Claude in particular likes to "mock" anything that gets a little bit hard even if I scream "NEVER MOCK DATA" in my agents file.
I would be curious if there are tricks in these long running loops like constantly injecting new "DO NOT MOCK" shouts at it every n cycles or something.
I haven't tried data analysis tasks.
> Update: It turns out Anthropic have their own documentation on Safe YOLO mode for Claude Code which says:
> Letting Claude run arbitrary commands is risky and can result in data loss, system corruption, or even data exfiltration (e.g., via prompt injection attacks). To minimize these risks, use --dangerously-skip-permissions in a container without internet access. You can follow this reference implementation using Docker Dev Containers. [https://github.com/anthropics/claude-code/tree/main/.devcont...]
And… that link goes to a devcontainer that firewalls itself from inside using, effectively, sudo iptables. If Claude Code can’t break that all by itself in a single try, I’d be a bit surprised.
Some principles I learned: 1. You don't really wanna use any kind of framework that wraps around openai or claude sdks. You end up fighting them 2. Small number of tools with more functions are better than large number of tools with small number of functions inside 3. Function definitions you put inside the tools are actually very important and need to be very clear 4. Integrating another agent as a tool to the main agent can relieve your context window by 5x 5. RAG via only vector search is mostly unnecessary. Claude Code itself leverages iterative search which works way better with code repos as well as most documents
And for more context on Efrit this is a fun watch: "When Steve Gives Claude Full Access To 50 Years of Emacs Capabilities" https://www.youtube.com/watch?v=ZJUyVVFOXOc
On the other hand we have cursed language [0] which was fully driven by AI and seems to be functional. Btw, how much did that cost?
I feel like I've been hugely successful tools like Claude Code, aider, open code. Especially when I can define custom tools. "You" have to be a part of the loop, in some capacity. To provide guidance and/or direction. I'm puzzled by the fact that people are surprised by this. When I'm working with other entities (people) who are not artificially intelligent, the majority of the time is spent clarifying requirements and aligning on goals. Why would it be different with LLMs?
$30k+
Not sure how functional though!
There was an interval where the notion of "context engineering" came into fashion, and we quickly dunked all over it (I don't blame anybody for that; "prompt engineering" seemed pretty cringe-y to me), but there's definitely something to the engineering problems of managing a fixed-size context window while iterating indefinitely through a complex problem, and there's all sorts of tricks for handling it.
—
You are going to create a summary of the important changes for a PR created by dependabot:
1. Read the body of PR $ARGUMENTS with the `gh` cmdline tool. 2. Create a todo list for yourself for each package in PLAN.md. 3. For each todo, read the releases page(s) (add /releases to the github repo url) to cover the update range. 4. Summarize breaking changes and CVE updates, see template at the end. Grouped into Dev Dependencies and Production Dependencies. 5. For production dependencies, find code usages (with `rg`/`grep`) and determine if breaking changes will affect us. Add a list of all found usages, linking to the direct line on github (like https://github.com/solarmonkey/app/blob/master/frontend/some...). Finish each with a verdict: unsure/likely OK/*may break*/*SURELY BREAKING*! 6. Fill the table up top with the verdicts 7. Write the filled out template to `deps_update_analysis.md`. Don't add a final summary or conclusive thoughts. The template is all we need.
[snip template to fill]
I’ve been working on a weekend project building one of these and the tools you provide are what makes the agent suitable for the task.
Even small models and non tool models can use MCP with correct prompting, but you have to edit what tools they can use.
Context is the big bottleneck to manage. Programming agents benefit from knowing shell commands, but generic agents you have to teach/trick into the right interactions, which burns context. Then out of the box an agent will want to read everything, so I have to comment which commands are expensive or cheap context wise.
My project is almost ready to explore context management methods: things like removing old files from memory, warning the agent about limits, using a second agent that does compaction.
It would be cool to eventually RLHF the agents too, but that’s unlikely with my weekend project budget.
[1] https://huggingface.co/learn/mcp-course/en/unit2/tiny-agents
Regarding sandboxing, VMs are the way. Prompt injected agents WILL be able to escape containers 100%.
Do not take the security impact of agents lightly!
I had assumed you were saying something more like "any attacker that prompt-injects you probably has a container escape in their back pocket they'll just stage through the prompt injection vector", but you apparently meant something way further out.
Right now you can prompt inject an obfuscated payload that can trick claude into trying to root a system under the premise that you're trying to identify an attack vector on a test system to understand how you were compromised. It's not good enough to do much, but with the right prompts, better models and if you could smuggle extra code in, you could get quite far.
AWS and Azure both use VM-level isolation. Cloudflare uses V8 isolates which are neither container nor VM. Fly uses firecracker, right?
This topic is kind of unnecessary for the type of developer workflows being discussed that the majority of readers of this article are doing, though. The primary concern here is “oops the agent tried to run ‘rm -rf /‘“, not the agent trying to exploit a container escape. And for anyone who is building something that requires a better security model, I’d hope they have better resources to guide them than the two sentences in this article about prompt injection.
So is the concern here purely around zero-days?
A good heuristic would be that unless you have reason to think you're a target, containers are a safe bet. A motivated attacker probably can pop most container configurations. Also, it can be counterintuitive what makes you a target:
* Large-scale cotenant work? Your target quotient is the sum of those of all your clients.
* Sharing infrastructure (including code supply chains) with people who are targeted? Similar story.
But for people just using Claude in YOLO mode, "security" is not really a top-of-mind concern for me, so much as "wrecking my dev machine".
Any reason why you want to rename it?
Edit: to say more about my opinions, "agentic loop" could mean a few things -- it could mean the thing you say, or it could mean calling multiple individual agents in a loop ... whereas "agentic harness" evokes a sort of interface between the LLM and the digital outside world which mediates how the LLM embodies itself in that world. That latter thing is exactly what you're describing, as far as I can tell.
"Designing agentic loops" describes a skill people need to develop. "Designing agentic harnesses" sounds more to me like you're designing a tool like Claude Code from scratch.
Plus "designing agentic loops" includes a reference to my preferred definition of the term "agent" itself - a thing that runs tools in a loop to achieve a goal.
Context engineering is about making sure you've stuffed the context with all of the necessary information - relevant library documentation and examples and suchlike.
Design the agentic loop is about picking the right tools to be provided to the model. The tool descriptions may go in the context but you also need to provide the right implementations of them.
Those decisions feel to me like problems for the agent harness to solve - Anthropic released a new cookbook about that yesterday: https://github.com/anthropics/claude-cookbooks/blob/main/too...
Or you just give loads of information without thinking much about it, assuming models will have to do frequent compaction and memory organization and hope its not super lossy.
Eg linear MCP is notorious for giving large JSONs which quickly fill up context and hard for model to understand. So tools need to be designed slightly differently for agents keeping context engineering in mind compared to how you design them for humans.
Context engineering feels like more central and first-principle approach of designing tools, agent loops.
My post is more about how sometimes you still need to make environment design decisions yourself. My favorite example is the Fly.io one, where I created a brand new Fly organization with a $5 spending limit and issue an API token that could create resources in that organization purely so the coding agent could try experiments to optimize cold start times without messing with my production Fly environment.
An agent might be able to suggest that pattern itself, but it would need a root Fly credential in order to create itself the organization and restricted credentials and given how unsafe agents with root credentials are I'd rather keep that step to myself!
I suppose you could never be sure that an agent would explicitly follow your instruction "Don't spend more than $5".
But maybe one could build a tool that provides payment credentials, and you get to move further up the chain. E.g., what if an MCP tool could spin up virtual credit cards with spending caps, and then the agent could create accounts and provide payment details that it received from the tool?
All "designing agentic loops" is context engineering, but not all context engineering is designing agentic loops. He's specifically talking about instructing the model to run and iterate against an evaluation step. Sure, that instruction will end up in the context, but he's describing creating a context for a specific behavior that allows an agent to be more effective working on its own.
Of course, it'll be interesting to see if future models are taught to create their own agentic loops with evaluation steps/tests, much as models were taught to do their own chain of thought.
Create a group for you and the `claude` user, and have it do `umask 002` on login.
The shellagent use case has much more parallels with 1980s TTY+mainframes dealing with multiple users than it has with containers.
I.e. Docker's USP was reproducibility; not access controls.
After reading the article a bit, I realized this isn't about "loops" at all. What it is about is "bypassing the yes/no human check on each step the LLM wants to take in completing some multi-step task". You can already to this with, for example, claude code. However, one of the points of having a human approve LLM actions is to prevent it doing something stupid or destructive. So now you have a second problem: how to prevent the LLM from poking holes in spacetime?
Answer: sandbox it.
And that's what the article is about.
On it, I run Ubuntu 24.04 as my host, and my guest is Lubuntu with 16GB ram and 80GB ssd for my KVM.
I almost always have 2 instances of PHPstorm open in both Host and and Guest with multiple terminal tabs running various agentic tasks.
I lived with 16GB until last year and upgraded to 32 only this year, which I thought was a huge improvement. I suspect a lot of people are around this ballpark, especially if they have bought Macs. Mine is Linux, still. So containers are the “simpler” versions.
[0]: https://github.com/dagger/container-use
[1]: I would like it better if the entire agent process were sandboxed but I suppose that would make it difficult to use with IDE/GUI-based agents.
In this particular thread, other has commented about lightweight sandboxing solution. I think I will integrate this next in my agent for safe code execution. [1]
" For our "high compute" numbers we adopt additional complexity and parallel test-time compute as follows:
- We sample multiple parallel attempts.
- We discard patches that break the visible regression tests in the repository, similar to the rejection sampling approach adopted by Agentless (Xia et al. 2024); note no hidden test information is used.
- We then use an internal scoring model to select the best candidate from the remaining attempts.
- This results in a score of 82.0% for Sonnet 4.5.But running in parallel means you use more compute, meaning that the cost is higher. Good results are worth paying for, but if a super recursive approach costs more and takes longer than a human...
Claude Code plan mode is the washing machine of agentic loops. It lets you see a detailed plan and if you approve you can let it rip with trust that it’ll do what it says, and go do something else while it’s at work.
Adding tests and other ways to validate its work help it go further & run longer off a single plan.
Isn't that risking getting banned from Azure? The compromised agent might not accomplish anything useful, but its attempts might get (correctly!) flagged by the cloud provider.
[0]: https://blog.toolkami.com/openai-codex-tools/#coding-agents
My problem is I often give it too much to do. I'm usually overly optimistic about how effective it can be.
I have found Sonnet 4.5 to be quite the improvement over Sonnet 4 however.
All of these things look helpful for humans too!
You may not want them to ingest README.md if it's long and contains irrelevant information as that might be a waste of valuable tokens.
where do i sign up?
Clearly it’s not just a good system prompt and hoping for the best. Obviously they’ve both got fairly good algorithms for working toward whatever the user asked for incrementally, handling expectable errors, changing course if necessary, etc.
I mean ultimately it’s gotta be a really big flow chart that results in the LLM getting prompted various ways in all kinds of directions before ultimately converging on the final response, right? Or am I way off-base?
Has anyone seen such a post explaining this architecture / state machine / algorithm?
And here's the markdown file it produced with an attempt at an answer: https://github.com/simonw/codex-scratchpad/blob/codex/analyz...
Is it just me ?
In this case I do think the term is justified - "agentic loop" is a good way of describing a loop with a bunch of tool calls driven by an LLM.
This doesn't need stating but if it does I am not saying you are a grifter, obviously, because you substantiate your positions. Just another classic signal v. noise.
Yes, it means something "vague" and vibes oriented. It's when you can run things in a terminal or async or something maybe.