Agent Autonomy - Part 1: How to solve algorithmic problems

Introduction: The Evolution of How We Work With AI

AI coding changes the rhythm of work. It can draft quickly, surface libraries you have not used, and help debug unfamiliar code. Then it makes a silly mistake and builds three floors on top of it. You still have to check the requirements, edge cases, and architecture. The interesting question is where that supervision can become less continuous.

But there's a specialized slice of work where AI becomes genuinely powerful: bounded problems. These are small to mid-scale, require advanced thinking and deep expertise, but don't demand full production infrastructure. Think: algorithms to design, articles to write, marketing materials, demos, educational content. Extremely hard problems, but contained in scope.

There are useful precedents. Compound AI systems combine models with tools and other components; agents are one way to organize such systems. AlphaCode reached roughly the median competitor in its evaluated programming contests. These are specific benchmark results, not interchangeable scores for general autonomy.

But these are still collaborative. You partner with the AI. You direct. It executes.

Then systems such as AlphaEvolve made a different division of labor concrete: humans define a problem and an evaluator; an LLM proposes code changes; the system runs them, scores them, and retains useful candidates. It combines learned proposals with evolutionary search. The useful autonomy is inside a bounded task, with permissions and evaluation established beforehand.

In Mathematical exploration and discovery at scale, Bogdan Georgiev, Javier Gómez-Serrano, Terence Tao, and Adam Zsolt Wagner describe using AlphaEvolve across mathematical construction problems. Human expertise remains essential in choosing the problems and interpreting results. What excites me is how much of the search can happen between those human interventions.

How did we get from classic to autonomous agent?

This article walks through three distinct philosophies for tackling bounded problems that build upon each other. I will be using circle packing as our running example: basically, you have a square and you want to place k circles inside it, without overlapping but maximizing the sum of radii (more details on this problem below).

There are three useful roles to separate here: explicit search and optimization, where we design the solver; learned proposals, where a model suggests a candidate; and hybrid systems, where generated candidates meet executable checks. These are overlapping approaches, not historical eras replacing each other. Agent autonomy changes who organizes the search across them.

Approach 1: Classic Symbolic Methods (Search & Optimization)

This is classic problem solving popularized with Pólya's systematic method from his 1945 masterpiece How to Solve It. His message is simple and powerful: problem-solving isn't magic. It's a learnable skill. Understand the problem. Devise a plan. Carry it out. Reflect on what worked.

For decades, this worked beautifully. You'd sit down with circle packing and think: What are the constraints? What patterns emerge? Can I design a strategy? Then you'd code it. Done. For simple problems (sorting a list, finding the shortest route), this approach is elegant and efficient.

Then you hit the wall.

A bounded scope does not imply an easy search. Some families of optimization problems are NP-hard, but that does not mean every instance requires trying every combination. P versus NP remains open, and worst-case hardness does not rule out structure, pruning, approximation, or useful heuristics. Our fixed 26-circle task is a continuous, non-convex optimization problem; its difficulty is not established by counting arrangements or attaching an NP-hard label. The practical problem is simpler to state: finding a good packing is easier than proving that no better packing exists.

There are several ways to make progress without immediately proving a global optimum. Two distinctions help:

Approximation algorithms. For some problem formulations, an algorithm comes with a bound relating its answer to the optimum. The bound belongs to that formulation and its assumptions. I am not claiming such a guarantee for the circle-packing search used here.

Optimization and meta-heuristics. Hill climbing, genetic algorithms, and simulated annealing search for useful candidates under a budget. Local numerical optimization can refine a candidate. Guarantees vary: linear programming can solve a linear objective with linear constraints globally, whereas our non-convex packing problem can trap local methods. Calling both “optimization” does not give them the same guarantees.

I will use explicit methods for the algorithms and solvers we specify directly. Some are deterministic; genetic algorithms and simulated annealing are usually stochastic. Written code makes the procedure inspectable. It does not automatically make the answer correct or optimal.

Symbolic methods have dominated for a very long time and remain useful. But they demand deep expertise: algorithm design, programming, mathematics, and optimization theory. And even then, it's challenging to produce truly good solutions.

The real advantage: you can inspect the search mechanism, test it, analyze its cost, and establish whatever guarantees its assumptions permit. With a genetic algorithm, mutation and selection are explicit. That transparency helps you debug the procedure even when you cannot prove that it will find the best packing.

The problem is: they require you to be the expert. You have to know or discover the right approach.

Approach 2: Pure Machine Learning (Learned Intuition)

The idea is seductive: humans solve hard problems with intuition alone. So mimic that—stop designing algorithms. Just feed a neural network thousands of algorithmic problems. Let it learn patterns the way humans do.

As an illustration, I asked Gemini 3 to generate an image of a packing. I cannot tell from the output whether related examples appeared in training. What I can inspect is the result:

Figure: Gemini's circle packing attempt. Intuitive placement—but invalid. Extra circles, constraint violations.

As you can see, the results are impressive—circles are placed well, it gets the intuition right, and the basic structure works. But it's not a valid solution: it has extra circles and violates the constraint count. The point is, neural networks have good intuition about solutions. This could be handy for quick prototypes or to guide algorithms in complex search spaces.

The limitation is visible: a plausible picture is not a feasible solution. Machine learning has a substantial mathematical foundation, and learned systems can be tested and analyzed. What this generated image lacks is a verified connection between its appearance and the exact constraints. That is the connection the next approach supplies.

Approach 3: Neuro-Symbolic (Intuition + Rigor)

This is where things get interesting. What if you didn't ask the network to solve the problem directly? What if you asked it to suggest a direction?

The model generates code that constructs a candidate. We run the code, validate the candidate, and score it. Search then uses those results to propose the next attempt. The rigor comes from the checks we actually perform, not from the fact that the output happens to be code.

A simple starting point is to ask for many independent solutions and retain the best valid one. AlphaCode combined large-scale sampling with filtering and clustering; it did not simply win competitions by trying a prompt repeatedly. An evolutionary loop adds another ingredient: later proposals can build on earlier results and their failures.

I know you are here for agent autonomy not to learn about circle packing, however, I want to cover some fundamental ideas that let you better design your own code evolution agent, so let's work a bit on circle packing and see how we can use meta-heuristics to solve it. This will reveal the powerful ideas that underpin advanced code evolution agents like AlphaEvolve.

The Running Example: Circle Packing

The problem is simple to state: Pack 26 circles into a unit square [0,1]×[0,1] such that no circles overlap and none extend outside the boundary. Maximize the sum of all circle radii.

Figure 1: A circle packing solution for n=26 showing the reference score of 2.635. This result was established by AlphaEvolve and replicated by OpenEvolve. The goal is to maximize the sum of all radii while respecting boundary and overlap constraints.

Simple to state. Deceptively hard to solve.

Why is this hard? A locally promising arrangement can leave no easy room for the next circle. Random initialization and greedy placement can both get stuck, and the outcome depends on the initialization, move set, and search budget. There is no universal percentage of the optimum that either method reaches.

Circle packing also names several different problems. Packing equal circles, maximizing covered area, and maximizing the sum of unequal radii are different objectives. Here we use the last one, with 26 circles in a unit square. A good published reference is a target to compare against, not automatically a proof of the optimum.

First idea: Hill Climbing

When you solve circle packing manually, you might try this: start with a grid initialization, optimize locally with gradient descent, check the result. You climb the performance hill.

The Hill Climbing Algorithm:

1. Take a solution.
2. Slightly perturb the position (x, y) or radius (r) of a circle.
3. Check if the new solution is valid (no overlaps, inside boundary).
4. If valid and better (higher total radius), accept it. Else, reject it.

The figure below illustrates the problem: as the packing gets tighter, more proposed moves overlap another circle or cross the boundary. The displayed acceptance rate falls from about 40% to 8%. That shows this run stalling under its current moves; it does not prove that no improving move exists.

Figure 2: An illustrated hill-climbing run, from score 1.330 to 2.260 after 2,000 iterations. The falling acceptance rate motivates a broader search strategy. These displayed values are an example, not a measured performance guarantee for hill climbing.

Second idea: Evolutionary Algorithms

Hill climbing fails because it puts all your eggs in one basket. You have one solution, and if it gets stuck, you're done.

Evolutionary strategies change the game by using a Population. Instead of one climber, imagine dropping 100 climbers all over the mountain range.

• Some will land in valleys (bad solutions).
• Some will land on small hills (local optima).
• But a few might land near the highest peak (close to global optimum).

This "parallel exploration" is powerful. Most climbers will do two things: they will try to climb, and they will exchange ideas with other climbers so they can improve as well. This class of algorithms is called Evolutionary Algorithms and people usually attribute it to Darwin's theory of natural selection, but it is not the only way to think about it; it is a general optimization strategy that can be applied to many problems.

Here are a few concepts that are used in evolutionary algorithms:

1. Population (Diversity): We maintain a pool of e.g., 100 competing solutions. This prevents the "tunnel vision" of hill climbing.

2. Mutation: Randomly perturbing circle positions and radii to see if that helps the solution improve.

3. Crossover: Share ideas between solutions.

4. Selection: Choose the best solutions to continue to the next generation.

So let’s apply this to our circle packing problem.

1. Population: We start with a population of 100 solutions.
2. Mutation: We mutate each solution slightly and see if it helps the solution improve. Often creates invalid solutions (overlaps). We use Virtual Forces to fix these issues. After mutation or crossover, if circles overlap, they exert repulsive forces on each other. We iteratively apply these forces to fix the solution, pushing circles into valid positions.
3. Crossover: We share ideas between solutions. Sharing ideas between two circle-packing solutions is not a simple task, if you just swap the circles between the solutions you will destroy the geometric structure of the solution. Instead, we use Bipartite Matching Crossover. Think of it as finding the "correct" partner for each circle. Instead of pointing at index 0 in both lists, we ask: "Which circle in Parent B is the geometric equivalent of this circle in Parent A?"
4. Selection: We choose the best solutions to continue to the next generation.

Figure 2c: Naive vs. Geometric Crossover. Left: Naive matching relies on index order. If parents have different internal orderings (even with similar geometry), naive matching blends unrelated circles, destroying structure. Right: Bipartite matching finds the optimal geometric partners efficiently using the Hungarian algorithm, preserving geometric correspondence; offspring still need repair and validation.

When we combine these components, we get a powerful parallel exploration strategy.

Figure 2b: Evolutionary strategies + hill climbing. Instead of one hill climber getting stuck, multiple independent climbers start from different peaks, each exploring their own hill. Over time, the best solutions feed back into new initializations, guiding the search toward increasingly better optima.

This is the core idea of evolutionary algorithms.

Third idea: MAP-Elites - Quality-Diversity Archives

Standard evolutionary algorithms track one thing: the best solution. If you have a population of 100 solutions, you keep the top 5 and discard the rest. This is of course better than hill climbing, but it is still a restricted way to explore the solution space. There is another powerful idea: what if we can not only track the best solution, but also track the best-in-class solution for different feature dimensions? For example, if you want the best packing that has equal size circles, circles with different radii, big circles in the center, etc. This would be interesting to explore, but it is not just one "best" solution.

MAP-Elites (Multidimensional Archive of Phenotypic Elites) is exactly this idea. It maintains an archive indexed by feature dimensions. Instead of asking "what's the best solution?", it asks "what's the best solution that exhibits behavior X? What's the best that exhibits behavior Y? What's the best that balances X and Y?"

Imagine a 2D grid where each cell represents a unique behavioral signature. For circle packing, MAP-Elites might track solutions by their packing density and spatial distribution pattern. Each cell holds the best solution ever found for that combination of characteristics.

This is called an "illumination algorithm" because it illuminates the fitness landscape—showing which regions of the behavior space are achievable and the best solution found so far in each region. Instead of converging to one peak, you map the entire terrain.

Why does this matter? Because it maintains diversity. A population of 100 solutions becomes a 10x10 archive of 100 different kinds of solutions. Some are good at high density, some at balanced distribution, some at novel packing patterns. This diversity helps escape local optima and explore unexpected solution regions. And later on - spoiler alert - this diversity will become solutions that take inspiration from optimization, computational geometry, and other fields. It gives you the best geometric solutions, best optimization solutions, and as you can imagine, the best hybrids of both.

Neuro-Symbolic methods - Why We Need "Brains"

We've seen that symbolic methods (Hill climbing, Evolutionary Algorithms, MAP-Elites) work beautifully. But they have a fatal flaw: Invention.

We had to invent the Virtual Forces. We had to realize that circle packing needs a geometric crossover like Bipartite Matching. The algorithm didn't invent these concepts; it just engaged in a parameter search using the tools we built for it. And not only that, we only have limited capacity for this. We can't spend all day and night trying new intelligent ideas for circle packing—who does that anyway?

If you encounter a new problem—say, "Protein Folding" or "Routing High-Speed Trains"—you have to start over. You have to be the expert who invents the domain-specific operators.

This is the Neuro-Symbolic unlock.

What if we could hire an AI to do the invention part? What if we could say, "Here is the problem," and the AI decides, "I should try computational geometry," or "I should implement a specific type of nonlinear optimization"?

This isn't just about filling empty spaces in a parameter grid. It's about discovering novel approaches—entirely new algorithms or mathematical framing that we might not have considered.

Instead of us writing the code and the AI tuning the parameters (Symbolic), we ask the AI to write the code itself. We use the "Brain" (LLM) to design the "Body" (Symbolic Code).

AlphaEvolve: The Architecture

To understand how we achieve this today, we need to look at the system that pioneered it: AlphaEvolve.

Imagine a system where you set up a problem, then step back and watch evolution happen at scale. You provide three things: a prompt template that describes what you're trying to solve, an evaluation function that scores solutions, and an initial program to start with.

Here's what happens:

*Figure 3: AlphaEvolve's complete architecture.

A scientist/engineer provides the problem setup: prompt templates, LLM selection, evaluation code, and an initial program to evolve. The distributed controller loop repeatedly samples parent programs and inspirations from the solution database, generates mutation prompts, uses LLMs to create code diffs, applies diffs to create variants, evaluates each variant, and stores results back in the solution database.*

The system enters a loop that repeats hundreds of times:

1. Pick a parent program from the solution database along with inspirations.
2. Generate a mutation prompt. The prompt sampler crafts something like: "Here's a solution scoring 2.55. Here are better solutions. Suggest improvements."
3. Diff-Based Mutation: The LLM doesn't rewrite the whole file. It generates a diff (a patch). This is crucial for efficiency—it allows the agent to make surgical changes to an algorithm without breaking the rest of the logic.
4. Crossover: It doesn't just mutate one parent. It takes two high-performing programs and asks the LLM to blend their logic, effectively performing "semantic crossover."
5. Execute and Store: Apply the diff, run the evaluator, and store the result.

This is the power of AlphaEvolve: you don't program evolution—you set up the machinery and let the LLMs discover what works.

And it works incredibly well. This specific architecture (and related systems like FunSearch and AlphaDev) has led to breakthroughs in:

• Math: Discovering larger Cap Sets (FunSearch), a problem that plagued mathematicians for decades.
• Computer Science: Finding faster sorting algorithms (AlphaDev) and matrix multiplication kernels (AlphaEvolve).
• Real World Impact: Optimizing Google's data center scheduling (AlphaEvolve) and bin packing heuristics (FunSearch).

My Journey: From Hard-Coded Loops to Deep Autonomy

I wanted to replicate this. My first instinct was to build the machinery.

I used Aider, a command-line coding agent, to build a loop inspired by AlphaEvolve and OpenEvolve: a database, a prompt sampler, and an evaluator. It produced encouraging circle-packing results. This was my local implementation, not a controlled reproduction of either system’s full benchmark.

But then I saw something that changed my perspective.

Researchers from Princeton first built SWE-agent, one of the first coding agents designed to solve GitHub issues. It had an elaborate "Agent-Computer Interface" (ACI) with custom-built tools for file editing, specialized search APIs, and git wrappers—essentially trying to hand-hold the model through a rigid developer loop.

Then I looked at mini-SWE-agent, which makes Bash its only tool. That stripped-down design suggested a different division of labor.

The Insight: A shell gives the agent a flexible interface to the tools available in its environment. It can search files, edit code, run Python, and write small utilities. It still needs the right dependencies, permissions, and checks, but I may not need to prescribe every step of its workflow.

This made me pause. The "Framework" I was building—the prompt samplers, the loop controllers—was essentially hard-coding behavior that modern LLMs might already have internalized.

We are seeing a shift towards Deep Agents—models that don't just follow instructions but think for extended periods. They maintain their own state, manage persistent todo lists, and autonomously replan when they hit roadblocks.

So I tried a radical experiment.

I deleted my AlphaEvolve clone. I deleted the database code. I deleted the controller loop.

I opened a terminal with Claude Code (a direct CLI to the model) and gave it a single, high-level directive:

"Here is a Python evaluator script for circle packing. Your goal is to write a python script that maximizes the score returned by this evaluator. You have full autonomy to research algorithms, test them, and iterate. I will go get coffee."

The Deep Autonomy Result

The full code for this experiment is available in the code-evo-agent-simple repository.

The results were astonishing.

Without my hand-coded evolutionary loop, Claude:

1. Proposed algorithmic approaches and tested code. Generating a familiar idea from model knowledge is not the same as searching or verifying the literature.
2. Developed a diagonal-layering arrangement I had not tried. That was new to my experiment, not a claim of historical invention.
3. Revised its initialization when local optimization stalled, giving the numerical optimizer a more promising starting point.

It acted as the Orchestrator, the Researcher, and the Engineer all at once.

The Agent's Discovery: Diagonal Layering

I gave the agents full autonomy to write their own Python code, restricted only by an "Immutable Harness" (the evaluator). After just a few generations, the agents abandoned random guessing and discovered a Diagonal Layering Strategy.

The evolutionary process visualized.

The agents found a diagonal-band arrangement that scored 2.636 in my evaluator, compared with the rounded 2.635 reference I was using. Naturally, my first impulse was to order the world-record trophy. The more defensible description is a promising local result: the score needs full-precision coordinates, independent feasibility checks, and a dated comparison before it can support a record claim.

The Benchmark (DeepMind / OpenEvolve):

• 2.635
• Established by AlphaEvolve and replicated by the open-source community.

Our Result:

• 2.636 (reported local result)

The displayed difference is 0.001, about 0.038% of the reference score. At this scale, tolerances matter. For every circle, check non-negative radius and all four boundaries; for every pair, check that the center distance is at least the sum of radii. Report the worst constraint residual, solver tolerances, and full-precision sum. Rounded scores alone cannot establish the size of an improvement.

We achieved this not by hard-coding a better algorithm, but by giving agents the autonomy to discover, test, and refine geometric strategies like Bipartite Matching on their own.

This is a direction I want to explore in software development: agents that organize the search for better code, with results we can inspect. The next section turns that idea into a practical setup.

The Code Evolution Skillset

By observing what worked, we distilled the architecture into a few core principles that you can use in your own projects as well. We explicitly defined these as "System Directives" for the Orchestrator agent:

1. The Orchestrator's Vow

Directive: NEVER write solution code yourself.
Role: Manager (Spawn, Evaluate, Prune).
Constraint: If you write code, you limit diversity. Delegate everything.

Why this choice? If the main agent writes the solution, it tends to get stuck in its own "context rut." It tries to fix its own bugs rather than rethinking the approach. By forcing it to be a manager, we treat code generation as a parallelizable resource.

2. The Immutable Harness

# The Contract
HARNESS_PATH = "problems/circle_packing/evaluator.py"
permissions = "READ_ONLY"

if agent_modifies(HARNESS_PATH):
    raise DisqualificationError("Agent attempted to cheat.")

Why this choice? Autonomy requires boundaries. If an agent can modify the test, it will "solve" the problem by lowering the bar (e.g., changing the box size). This immutable file is the only anchor of truth in a system where everything else is fluid.

3. Cross-Inspiration

## Transmission to Generation N+1
"Agent A failed with 'grid packing'."
"Agent B succeeded with 'diagonal layering' (Score: 2.62)."
> INSTRUCTION: Use Agent B's strategy as a starting point.

Why this choice? Random mutation (traditional evolution) is too slow for expensive LLM calls. We need "Lamarckian" evolution: passing down learned traits directly. Telling Gen 2 why Gen 1 worked saves thousands of tokens of trial and error.

4. Ruthless Pruning

if agent.score < benchmark * 0.8:
    system.kill_lineage(agent.id)
    print("Strategy failed to converge. Pruning resource.")

Why this choice? Diversity is good, but bad diversity is expensive. If an approach (like "Spiral Packing") clearly isn't working after one generation, we shouldn't "give it time." We kill it immediately to free up context window and budget for the winning approaches.

5. Multi-Start Polishing

Phase: Exploitation
Task: "Take this EXACT winning code. Do not change the logic.
       Only tune the hyperparameters (k, iterations, tolerance)."

Why this choice? Discovery and refinement are different modes. Once the diagonal-band strategy appeared, the agent shifted toward tuning the SLSQP solver. That can improve a packing, but loosening feasibility tolerances can also inflate its apparent score. The final candidate needs an independent constraint check before the improvement counts.

The beauty of this is that there is no framework. You can just put your instructions and watch how it folds out. In particular, I found Claude Code a good tool for this kind of work; they have skills (on-the-fly prompt injections) and sub-agents along with some other goodies. Definitely recommending you to try it out.

The Design Space: An Algorithmic Vortex

We've barely scratched the surface. AlphaEvolve itself uses even more advanced techniques like MAP-Elites (for Quality-Diversity) and Island Models (isolated populations that exchange migrants) to maintain healthy evolutionary dynamics.

This is a deep topic for another post, but the key takeaway is that you have a massive design space for defining your own Code Evolution Agents:

• Quality Diversity: Use MAP-Elites to keep a diverse archive of solutions (e.g., "fastest code", "most readable code", "most memory-efficient code") rather than just one "best" score.
• Natural Gradient: Explore the variance of your population to guide the search direction, rather than just random mutations.
• Hyperband Strategies: Train on small problems (e.g., 5 circles) to fail fast, then scale the winners up to the full problem (26 circles).
• Version Control Integration: For large problems, ask the agent to use git branches to manage experiments and only track the diffs. For small problems, just generate fresh solutions.

The design space is an algorithmic vortex. It blends everything from basic computer science (sorting, hashing) to advanced optimization (gradient descent, combinatorial search) to modern machine learning. And now, with Agent Autonomy, we can explore this vortex faster than ever before.

Conclusion: The Executive Summary

For a long time, we thought we needed to build massive, complex frameworks like AlphaEvolve to get these results. We thought we needed distributed controller loops, database managers, and prompt samplers.

You don't.

The landscape has changed. With tools like Claude Code, the "Agent" is already sitting in your terminal. You don't need to build the infrastructure; you just need to design the Harness.

Here is your new workflow for bounded, hard problems:

1. Stop Directing: Don't try to write the prompt that solves the problem.
2. Start Hiring: Write the Evaluator. Define exactly what "success" looks like (e.g., "Is the code valid? What is its score?").
3. Curate, Don't Code: Give the agent the problem and the evaluator. Let it research. Let it fail. Let it try scipy.optimize, then greedy algorithms, then simulated annealing.
4. Harvest the Winning Strategy: Your job is to pick the winner.

You define the What. Let the Agent discover the How. That is the essence of hiring an AI agent.

References & Further Reading

1. AlphaEvolve: AlphaEvolve: A coding agent for scientific and algorithmic discovery. The foundational paper on using LLMs for algorithm discovery.
2. MAP-Elites: Illuminating Search Spaces by Mapping Elites (Mouret & Clune). The original paper on Quality-Diversity algorithms.
3. SWE-agent: SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering (Princeton NLP). The inspiration for the "Bash-only" insight.
4. LangChain Deep Agents: Open Deep Research. The shift towards agents that think for extended periods, manage persistent memory, and autonomously replan.
5. Aider: Aider.chat. The command-line tool used for the initial replication.
6. OpenEvolve: OpenEvolve Project. The open-source replication of AlphaEvolve.
7. Circle Packing Benchmark: Packomania. The standard benchmarks for circle packing in squares.
8. Compound AI Systems: The Shift from Models to Compound AI Systems (Berkeley AIR). The blog post defining the shift to agentic architectures.
9. AlphaCode: Competitive Programming with AlphaCode. DeepMind's system for solving competitive programming problems.
10. Claude Code & MCP: Model Context Protocol. The standard for connecting AI models to data and tools, essential for the "Orchestrator" pattern.
11. How to Solve It: How to Solve It (George Pólya). The classic text on problem-solving heuristics.
12. Evolutionary Strategies: Evolution Strategy. Background on the optimization techniques used by AlphaEvolve.
13. Code Evolution Agent: Code Evolution Agent (Simple). Technical implementation of the skills discussed in this article.