Self-Modifying Agents: Code vs Config

The Modification Layer Is the Whole Argument

When you build a system where agents improve themselves, the first design decision is also the most consequential: what exactly are they allowed to modify?

Two answers exist. Agents modify code directly, altering Python, JavaScript, or whatever runtime they operate in. Or agents modify configuration, writing to YAML files, JSON schemas, or similar declarative artifacts that the code then interprets.

Code Versus Config Is Not a Minor Distinction

These are not two flavors of the same approach. They are architecturally distinct, with different failure modes, different security surfaces, and different operational ceilings. The community has not settled on this clearly enough, and practitioners are making the wrong choice for the wrong reasons.

Code Modification Is a Loaded Gun in Production

The appeal of code-modifying agents is obvious. Full expressiveness. No ceiling on what an agent can change. If the logic is wrong, rewrite the logic.

The problem is that code execution is an interpreter-level primitive. An agent that writes Python and then runs that Python has, by definition, escaped any behavioral guardrail you built above the execution layer. You cannot sandbox this cleanly without essentially rebuilding a VM inside your agent loop, and if you do that, you have added enormous operational complexity for a capability you probably do not need.

Code Agents Don't Fail Safely

The attack surface is not theoretical. Prompt injection into a code-writing agent does not produce a bad YAML file. It produces executable code that runs in your environment. The blast radius is your entire system, not a malformed config key.

Config Modification Is Boring, Which Is the Point

The config-driven approach constrains agents to writing YAML. The code that interprets YAML does not change. This means your validation logic, your type checks, your range constraints on parameters, all of that stays static and auditable. An agent proposing a change to a worker's behavior is proposing a diff against a known schema. You can review it. You can reject it. You can roll it back with a one-line git revert.

The system described in the sources is a concrete implementation of this: a CEO agent reads KPIs every night, an auditor layer proposes config changes per worker, and the CEO reviews those proposals before anything gets applied. The modification surface is YAML files. The Python codebase does not change autonomously. That constraint is load-bearing.

Where Config-Driven Systems Hit Their Ceiling

This is where intellectual honesty matters. Config-driven architectures have a real ceiling, and pretending otherwise would be wrong.

The ceiling is expressive power. A YAML file can change parameters, toggle features, adjust thresholds, modify prompts. It cannot change the fundamental logic of how a worker processes input. If an agent determines that a worker needs a structurally different algorithm, a config change cannot deliver that. You need a human to ship new code.

Config Cannot Rewire Its Own Brain

This is not a small limitation for research systems or highly experimental pipelines. If you are building agents that need to discover genuinely novel strategies, config-driven self-improvement will plateau. The agent will optimize within the parameter space it has been given, but it cannot expand that space.

The Plateau Is Actually a Feature for Production Systems

Here is the editorial position: for production systems, the config ceiling is not a bug. It is a feature.

Production agents do not need unlimited self-modification. They need reliable self-optimization within a known envelope. A customer support agent that tunes its retrieval threshold based on satisfaction KPIs is more valuable in practice than a research system that occasionally discovers something brilliant but is mostly unauditable.

Cheap Hardware Forces Better Architectural Discipline

The architecture described in the sources runs on a single e2-small VM, 2 GB RAM, 2 shared vCPUs, 20 GB disk, costing approximately 13 euros per month. That is not a constraint to apologize for. That is a signal that the system is doing targeted, bounded work rather than expensive, unconstrained exploration. Free tier Gemini Flash-Lite handles routine worker tasks. Gemini Pro handles the CEO-level synthesis. OpenRouter provides fallback. The cost envelope is controlled because the modification envelope is controlled.

The Hierarchy Question Nobody Asks Early Enough

Multi-agent self-improving systems need a hierarchy, and most teams design it too flat or too late.

The CEO-auditor-worker pattern in the described system is a specific and defensible architecture. Workers execute tasks and emit metrics into SQLite. Auditors inspect individual workers and propose config changes. The CEO reads aggregated KPIs, reviews auditor proposals, and writes strategic reports. No single layer has both execution authority and unrestricted modification authority.

Flat Hierarchies Let Agents Cheat Their Metrics

This separation matters because self-improvement loops have a known failure mode: the optimizer overfits to its own metric. A worker agent given direct self-modification capability will optimize for whatever it can measure, not necessarily for what you care about. The auditor layer creates an evaluation distance between the worker and its own improvement signal. The CEO layer creates a second evaluation distance between tactical proposals and strategic approval.

The config-vs-code distinction is not a technical detail. It is the line between a system you can explain to a regulator and one you cannot.

Memory Architecture Determines What the CEO Actually Knows

ChromaDB handles memory in the described system. This is a specific choice with specific implications for a self-improving architecture.

The CEO agent's ability to write useful strategic reports depends entirely on what context it can retrieve. If ChromaDB stores only recent operational metrics, the CEO is optimizing myopically. If it stores historical config changes alongside their downstream KPI effects, the CEO can reason about which interventions actually worked. The difference between these two retrieval strategies is the difference between a system that improves and a system that oscillates.

The KPI-to-Config Linkage Is the Hard Part

Building the linkage between a config change, the timestamp of that change, and the subsequent metric trajectory is non-trivial. Most implementations store metrics and configs in separate locations with no explicit foreign key between them. The self-improvement loop then has no way to attribute outcomes to interventions.

This is the implementation detail that breaks most config-driven self-improving systems before they reach their theoretical ceiling. The architecture is sound. The data plumbing that makes the CEO's context actually causal is where teams under-invest.

The Verdict

Code-modifying agents are more powerful in theory. Config-modifying agents are more deployable in practice. For any system that needs to run in production, serve real users, and be debuggable by a human engineer under pressure, the config-driven approach wins.

The open-source system described here makes the right call, and the cost profile proves it. Thirteen euros per month for an autonomous multi-agent system with nightly CEO-level reporting is not a toy. It is a correctly bounded production system that will outlast most over-engineered alternatives.

Config Wins; Budget Your Ceiling From Day One

Choose config-driven self-improvement. Add rigorous KPI-to-change attribution from day one. Budget your modification ceiling explicitly, so you know when you have hit it and need human intervention. That is the operational discipline the code-modification advocates never talk about.

Sources: DEV.to (May 5, 2026)