The Self-Improving Stack: How AI Agents Get Better

Suppose a coding agent finishes a ticket and reports that the tests pass. On the next similar ticket, it repeats the mistake, uses more model calls, and leaves no record of why it stopped.

The team asks for an agent that improves itself. That sentence sounds like a plan until someone asks what is allowed to change, what counts as better, and who can approve the change.

The self-improving stack names the mutable layers around an agent, together with the evidence and release rules that decide which changes persist.

An agent is software that uses a model, tools, and a control loop to complete a task. An agent runtime is the software that starts that loop, supplies tools, enforces budgets, and decides when execution ends. An agent profile is the configuration that makes one agent run identifiable, including its model, instructions, tools, skills, permissions, and resource limits. A trace is the record of one run, including the task, model calls, tool actions, observations, artifacts, costs, and outcome. An evaluation is a structured assessment of those outcomes against tasks, checks, costs, or policies. A baseline is the version already in use, and a candidate is a proposed replacement. A promotion rule is the explicit rule that decides whether the candidate may replace the baseline. A checker is a repeatable check that tests an artifact or action against an explicit condition. An holdout set is a protected group of tasks kept out of candidate search until the release decision. Integration code connects an agent to its tools, evaluators, storage, and release controls. Governance sets authority limits, approvals, ownership, and incident-response rules around changes.

The rest of this series asks one question at every layer:

What changed, what evidence says it helped, and what prevents the change from making the system worse?

“Self-improving” describes a loop, not a magic property

A system improves when a later run behaves differently because an earlier run produced an admissible lesson. That lesson might be a better prompt, a reusable procedure, a new checker, a different execution shape, a model update, or a policy change.

The smallest honest loop looks like this:

run the current version
capture what happened
diagnose the failure
propose one candidate change
compare candidate with baseline
keep the candidate only if the release rule passes

The verbs need concrete owners. The runtime executes the task. The trace store preserves the path. The evaluator turns outputs and events into evidence. The candidate generator proposes a change. The promotion rule protects the comparison and decides whether the change ships.

This is a useful model for a support agent that must answer refund questions. The first version gives fluent answers but forgets to cite the order policy. The team can try several fixes, but each fix makes a different claim:

Observed failure	Candidate change	Evidence required
The instruction is ambiguous	Rewrite the prompt	Same model, tools, tasks, and evaluator with a protected holdout
The agent forgets a recurring procedure	Add or revise a skill	Repeated-task lift plus tests for unwanted activation
The agent cannot check its own answer	Add a checker or tool	A real tool call and a deterministic check in the trace
One attempt is unreliable	Add retries, refinement, or fanout	Quality and cost at the same budget
The judge rewards polished but unsupported answers	Repair the evaluation	Calibration against trusted labels and deterministic checks
The behavior must transfer across many contexts	Post-train a model or adapter	Data lineage, contamination checks, rollback, and broad regression tests

The right fix follows the failure mechanism. A prompt cannot create a missing tool, and a skill cannot create a missing worker pool. More samples can raise the chance that a good answer appears without making the system better at selecting it.

The state transition has to be observable

Let s_t be the current agent state and c_t a candidate state. The loop is:

s_{t+1} = c_t  when ReleaseRule(Evaluate(c_t), Evaluate(s_t)) passes
s_{t+1} = s_t  otherwise

That equation is intentionally plain. It says the system does not improve because a model produced a confident reflection. It improves when a measured candidate earns the right to persist.

The comparison should identify the state being changed:

profile = {
  model,
  promptVersion,
  skills,
  tools,
  runtimePolicy,
  budget,
  evaluatorVersion,
}

Changing any of those fields creates a different experimental cell. If the model changes while the prompt changes, the result is a system comparison, not a prompt comparison. If the runtime silently doubles the turn limit, the candidate bought extra work. If the evaluator changes its rubric, the score no longer has the same meaning.

The Tangle agent-eval repository describes this discipline in public terms: run the same cases, score every result, compare a candidate with a baseline using paired statistics, and keep final test cases away from the optimizer. The Tangle agent-runtime repository supplies the execution side for one-shot tasks, chat turns, teams, bounded rounds, and improvement experiments.

The stack is a map of mutable surfaces

The layers are easier to understand when each one has a different object to change.

Layer	What can change	What the layer cannot provide by itself
Prompt optimization	Instructions, examples, tool descriptions, schemas, and rubrics	New tools, parallel workers, or a better evaluator
Skill optimization	Reusable procedures and their activation rules	New capabilities or permission to perform an action
Runtime execution	Ordering, fanout, refinement, delegation, budgets, and stopping	Evidence that the new flow improved the product
Test-time compute	Samples, branches, retries, verification, and search effort	A reliable selection rule when the checker is weak
Evaluation	Metrics, judges, task splits, reports, and promotion rules	Better behavior unless the measured result changes what ships
Trace systems	Run identity, spans, observations, artifacts, and replay	A correct diagnosis without analysis or review
Integration code evolution	Code that connects agents, tools, evaluators, and release controls	An independent release decision if it can edit its own release rule
Post-training	Model weights or learned adapters	Local rollback and easy attribution for every new behavior
Memory and knowledge	Facts, procedures, retrieval indexes, and persistent lessons	Truth from storage alone
Governance	Authority limits, approvals, ownership, and incident response	A quality lift without a useful product loop

The series follows these layers in the order a builder encounters them. Optimization theory for agent builders gives the language of objectives, search, and regret. Prompt optimization and skill optimization cover external text and procedure. Runtime execution and multi-agent coordination cover the actions and relationships the system can execute. Test-time compute asks whether a complex strategy beats a simpler way to spend the same budget. Evaluation rules and agent traces cover selection and evidence. Integration code evolution covers changes to the surrounding software. Post-training agents covers model-level changes. Memory flywheels covers persistent facts and lessons. Governance covers the authority outside the loop.

A compact worked example

Suppose the baseline support agent answers eight of ten refund cases correctly. Its traces show that it usually retrieves the policy, but it sometimes skips the order-status check when the user includes several dates.

There are at least three plausible candidates:

candidate A: add one sentence to the system prompt
candidate B: add a skill that checks order status before applying refund policy
candidate C: add a required order-status tool call and a deterministic validator

The traces determine which experiment comes first. If the tool already exists and the model skips it, candidate A or B may have causal control. If no order-status tool exists, candidate C is the only candidate that changes the available action. If the evaluator awards full credit without checking the order status, the promotion rule must be repaired before any candidate is promoted.

A promotion record should preserve more than a single accuracy number:

{
  "baseline": {"profile": "refund-v12", "correct": 8, "cases": 10},
  "candidate": {"profile": "refund-v13", "correct": 9, "cases": 10},
  "cost": {"baselineUsd": 0.18, "candidateUsd": 0.21},
  "hardChecks": {"policyCitation": true, "orderStatusCheck": true},
  "holdout": true,
  "decision": "review"
}

The review decision is deliberate. Ten cases are enough to find a likely failure, but not enough to support a general claim about a production distribution. The record makes the next decision visible instead of turning a small experiment into a headline.

Tangle makes the service boundary explicit

Tangle is a coordination layer for services that outside operators can run. Its terminology matters because an agent workflow is often deployed as a service rather than as a process on one developer’s laptop.

A Blueprint is a reusable service template that defines runnable artifacts, jobs, inputs, outputs, metadata, and optional protocol rules. A service instance is a live deployment created from that template. An operator is the node or organization that registers to run the service instance, accepts work, and returns results. A job is a callable unit of work against the service instance.

The Tangle Blueprint introduction distinguishes those objects and explains that application logic usually runs off-chain while the protocol tracks coordination, payments, lifecycle, and optional verification.

A router in a Tangle Blueprint Runner is a traffic director for jobs. It validates a job call, sends it to the handler registered for that job identifier, and returns the handler’s result. It is not automatically a model chooser, and it does not make a weak agent evaluator strong.

x402 is an optional web payment path for a job. The caller sends a payment that the gateway verifies and settles before the paid request becomes a job call. Payment authorization answers “may this paid request enter the service?” and does not answer “was the agent’s result correct?” The x402 gateway documentation describes that boundary, including paid endpoints, replay protection, and restricted caller policies.

An attestation is evidence from a confidential-computing setup that a required execution environment and policy were present. That environment is often called a trusted execution environment, or TEE, because it isolates code and exposes evidence about its launch state. It can help establish where code ran and whether a TEE requirement was met. It does not prove that an agent chose the right tool or produced a correct answer. Tangle’s confidential-compute documentation treats required TEE execution and cryptographic attestation as deployment conditions, with fail-closed behavior when those conditions are not met.

For agents, the profile still matters. Tangle’s AI documentation describes profiles as the controls for models, tools, budgets, and policies, and describes evaluation as the structured information used to refine prompts, policies, and workflows. Those are the same distinctions the self-improving loop needs whether the service runs locally or through an operator.

The public TypeScript packages document this installation path:

pnpm add @tangle-network/agent-runtime @tangle-network/agent-eval @tangle-network/sandbox

The most common layer mistakes

Layer confusion produces expensive experiments. The following fixes sound plausible and often target the wrong variable:

Symptom	First guess	Better diagnosis
The agent says it worked in parallel but one call ran	The prompt needs stronger wording	The runtime has no fanout and no child-run record
A saved skill helps one benchmark and harms normal work	The model is inconsistent	Activation is too broad or the skill contains a brittle shortcut
A new execution shape scores higher	Multi-agent coordination is smarter	The candidate may have spent more calls or used an easier selection rule
The judge score rises while users complain	Production feedback is noisy	The judge may reward style, verbosity, or rubric imitation
Memory fixes one task and causes another wrong answer	More retrieval is needed	The write lacks source, freshness, scope, or contradiction checks
A tuned model looks better on its training traces	Post-training worked	The model may have memorized the training distribution or its evaluator

The repair is to add the missing evidence before adding another optimizer. A trace with the actual tool arguments can show whether the next experiment belongs in the prompt, procedure, runtime, or evaluator. One held-out slice can prevent a team from shipping a benchmark-specific rule.

What the stack cannot promise

Self-improvement does not remove uncertainty. The task distribution can change after the promotion rule passes. Users can introduce cases absent from the evaluation set. Tools can change their schemas or return different data. Model providers can change behavior without changing your prompt. Persistent skills and memories can become stale. An evaluator can be systematically wrong even when its confidence is high. An operator can meet a deployment condition while the product still fails its user-level check.

The stack makes those risks explicit in the release record. It does not turn a proxy score into truth. It does not make an autonomous agent safe merely because every step has a log. It does not make decentralization a substitute for application-level validation.

Choose the next layer from the failure

Start with one real task and one trace. Name the failure in ordinary language. Then ask which mutable surface can cause that failure to change.

Use prompt optimization for ambiguous instructions, unstable output schemas, and missing examples. Use skill optimization for recurring procedures that should transfer across runs. Use runtime work for missing actions, fanout, cancellation, budgets, or durable state. Use test-time compute when extra attempts can be selected by a trustworthy checker. Repair evaluation before optimizing against a judge that does not match the product. Preserve traces before asking an optimizer to explain why a run failed. Choose post-training only when the behavior deserves to live in model parameters and the team can govern the resulting artifact. Put governance outside every surface that can change.

The practical test for a self-improving agent is short:

Can another engineer identify the changed surface,
replay or inspect the evidence,
see which baseline was beaten,
understand the cost and failure tradeoff,
and roll the change back?

If the answer is no, the system may still be learning in an informal sense. It is not yet running a controlled self-improvement loop.

Sources

What is the self-improving stack?

The self-improving stack is the set of agent layers that can change, from prompts and skills to runtime execution, test-time compute, evaluation, traces, memory, model weights, and governance. The defining feature is a measured candidate-and-baseline loop, not a model that merely writes a reflection.

Where should a builder start?

Start with one real trace and a small evaluation that can distinguish a good result from a bad one. Then identify the mutable surface that can cause the observed failure to change. Evaluation rules and agent traces are the best next reads before broadening the optimizer.

Does Tangle prove that an agent result is correct?

No. Tangle can coordinate a Blueprint service, operators, jobs, payments, and deployment evidence, while product-level correctness still needs application checks, traces, and evaluation. An attestation can support a claim about confidential execution, and x402 can authorize a paid request, but neither is a correctness certificate.

When should a team change the model itself?

Change model weights only when the behavior must generalize across many contexts, the training data has clear provenance, and the team can evaluate, govern, and roll back the resulting model or adapter. If a prompt, skill, tool, runtime change, or external knowledge update can solve the problem, that surface is usually easier to inspect.