Let an agent extend its own code inside a Docker sandbox

Hi HN, I built Miguel, an AI agent (Claude + Agno framework) that reads, modifies, and extends its own source code autonomously, sandboxed inside Docker.I gave it 10 seed capabilities (answer questions, read own code, create tools, handle errors, etc). Task: Hi HN, I built Miguel, an AI agent (Claude + Agno framework) that reads, modifies, and extends its own source code autonomously, sandboxed inside Docker.I gave it 10 seed capabilities (answer questions, read own code, create tools, handle errors, etc). It completed all 10, then generated its own capability checklist and started implementing those too. It's now at 21+ self-implemented capabilities, including web search, persistent memory, task planning, file analysis, API integrations, and sub-agent delegation. Every change is a real git commit you can browse: https://github.com/soulfir/miguel/commits/mainHOW IT WORKS The system splits into two sides with a hard trust boundary. The host side is protected: it runs the CLI, the improvement runner, git operations, and validation checks. The agent can never see or modify these files. The container side is sandboxed: the agent, its tools, and all execution live inside Docker with the project mounted read-only. The agent can only write to its own code directory. The improvement loop goes like this. The runner takes a git snapshot, then sends the agent its own source code along with the next capability to implement. The agent modifies its own files inside the container. The runner validates the changes with AST syntax checks, JSON schema checks, and import checks. If everything passes, it commits and pushes. If anything fails, it automatically rolls back to the last working state.WHAT I LEARNED The agent kept creating thin wrapper tools. For example, an api_get() that just calls http_request(method="GET"). It was optimizing for convenience without understanding that every tool costs context tokens. I ended up writing immutable "10 Commandments of Self-Improvement" into the protected runner — principles the agent sees every batch but can never modify. One of them: "Your tool count is a tax on cognition, not a score." After the commandments, the agent ran a consolidation batch on its own. It cut its codebase by 10% and its system prompt by 63%, while keeping all functionality. It understood the principle and acted on it. The agent also evolved itself from a single agent into a team architecture with specialized sub-agents (Coder, Researcher, Analyst), using the framework's native team/delegation API. I didn't touch any agent code for that. The most dangerous failure mode isn't bad code — it's context exhaustion. The agent would read six or more of its own files to "understand" itself, then have no context left to actually write code. Managing the agent's cognitive budget turned out to be the core design challenge.LIMITATIONS It uses the Claude API, so it costs money to run. Each improvement batch is roughly a few euros in API calls, which is the main bottleneck on how fast it evolves. It's early stage — the architecture works well but the agent still makes questionable decisions sometimes. Licensed under CC BY-NC 4.0. Code is on GitHub. Star it and check back in a week. The code will be different, because Miguel will have changed it.Happy to answer questions about the architecture, the safety model, or the weirdness of watching an AI rewrite its own brain.; tools: Claude. Human role: The original post does not say how a person stayed involved.; limitations: Running the agent incurs API costs, with each improvement batch costing a few euros. The primary technical constraint is managing the agent's cognitive budget to prevent context exhaustion. The system relies on strict sandboxing and validation checks to prevent harmful code execution, but the agent's autonomous decision-making remains unpredictable..

Tools

Claude

Published on Agent Work Atlas: 2026-11-03

Overview

Workflow

Hi HN, I built Miguel, an AI agent (Claude + Agno framework) that reads, modifies, and extends its own source code autonomously, sandboxed inside Docker.I gave it 10 seed capabilities (answer questions, read own code, create tools, handle errors, etc). It completed all 10, then generated its own capability checklist and started implementing those too. It's now at 21+ self-implemented capabilities, including web search, persistent memory, task planning, file analysis, API integrations, and sub-agent delegation. Every change is a real git commit you can browse: https://github.com/soulfir/miguel/commits/mainHOW IT WORKS The system splits into two sides with a hard trust boundary. The host side is protected: it runs the CLI, the improvement runner, git operations, and validation checks. The agent can never see or modify these files. The container side is sandboxed: the agent, its tools, and all execution live inside Docker with the project mounted read-only. The agent can only write to its own code directory. The improvement loop goes like this. The runner takes a git snapshot, then sends the agent its own source code along with the next capability to implement. The agent modifies its own files inside the container. The runner validates the changes with AST syntax checks, JSON schema checks, and import checks. If everything passes, it commits and pushes. If anything fails, it automatically rolls back to the last working state.WHAT I LEARNED The agent kept creating thin wrapper tools. For example, an api_get() that just calls http_request(method="GET"). It was optimizing for convenience without understanding that every tool costs context tokens. I ended up writing immutable "10 Commandments of Self-Improvement" into the protected runner — principles the agent sees every batch but can never modify. One of them: "Your tool count is a tax on cognition, not a score." After the commandments, the agent ran a consolidation batch on its own. It cut its codebase by 10% and its system prompt by 63%, while keeping all functionality. It understood the principle and acted on it. The agent also evolved itself from a single agent into a team architecture with specialized sub-agents (Coder, Researcher, Analyst), using the framework's native team/delegation API. I didn't touch any agent code for that. The most dangerous failure mode isn't bad code — it's context exhaustion. The agent would read six or more of its own files to "understand" itself, then have no context left to actually write code. Managing the agent's cognitive budget turned out to be the core design challenge.LIMITATIONS It uses the Claude API, so it costs money to run. Each improvement batch is roughly a few euros in API calls, which is the main bottleneck on how fast it evolves. It's early stage — the architecture works well but the agent still makes questionable decisions sometimes. Licensed under CC BY-NC 4.0. Code is on GitHub. Star it and check back in a week. The code will be different, because Miguel will have changed it.Happy to answer questions about the architecture, the safety model, or the weirdness of watching an AI rewrite its own brain.

Reported result

The agent successfully implemented 21+ capabilities, including web search and sub-agent delegation. It reduced its codebase by 10% and system prompt by 63% after being instructed to minimize tool count. However, the author notes the agent still makes questionable decisions and faces context exhaustion issues, indicating the system is early-stage and not fully reliable.

Human role

The original post does not say how a person stayed involved.

Limitations

Running the agent incurs API costs, with each improvement batch costing a few euros. The primary technical constraint is managing the agent's cognitive budget to prevent context exhaustion. The system relies on strict sandboxing and validation checks to prevent harmful code execution, but the agent's autonomous decision-making remains unpredictable.

Try it

I want to build a self-improving AI agent prototype using Claude and the Agno framework, sandboxed in Docker. My goal is to have the agent modify its own code to add new capabilities while maintaining stability. Inputs: - Initial codebase: [replaceable input: path to local git repo] - Seed capabilities: [replaceable input: list of 5 basic functions like 'read_file', 'write_file'] - Validation rules: [replaceable input: AST checks, JSON schema validation] Steps: 1. Set up a Docker container with the code mounted read-only, allowing writes only to a specific 'agent_code' directory. 2. Create a host-side runner script that takes a Git snapshot, sends the current code and next capability request to the agent, and waits for changes. 3. Implement validation logic in the runner: check syntax, imports, and schema. If valid, commit; if invalid, rollback. 4. Inject a system prompt constraint: 'Minimize tool count to save context tokens.' 5. Run one sample improvement cycle for a simple capability (e.g., 'add error handling'). Deliverables: - A working Docker setup with the runner script. - A Git log showing one successful commit and one rollback example. - A report on token usage and validation results. Quality Check: - Ensure the agent cannot modify the runner or host files. - Verify that the rollback mechanism works when invalid code is generated. - Confirm the agent respects the tool count constraint. Human Confirmation: - Do not push to remote or spend significant API credits without my approval after the first sample run.

Original source

Source reports are not independently verified. Publication date is the catalog publication date, not the original article date.