How it works
An adaptation surface is the place where experience becomes a behavioral change. An agent may observe a failure, receive operator feedback, or detect a new operating condition. Nothing adapts until the system writes that information somewhere that will influence a later run.
A typical adaptation loop has four parts:
- Capture a signal, such as a failed verification, corrected output, or operator preference.
- Decide whether that signal should change future behavior.
- Write the change to a named surface: memory, a prompt, a skill, tool configuration, routing policy, or model weights.
- Evaluate subsequent behavior against the intended improvement and existing invariants.
Each surface has different semantics. A session-memory update may disappear after one run. A cross-session memory can affect many future tasks. A changed tool description can alter when the model invokes a capability. Training changes behavior more broadly and is harder to inspect or reverse.
The engineering task is therefore not merely to let the system learn. It is to define where learning may occur, who may authorize it, what scope it reaches, and how the resulting behavior can be attributed to that change.
Why it matters in an agent harness
An unnamed adaptation surface turns behavioral change into ambient drift. When prompts, retrieved memories, tool definitions, and routing rules can all change at once, an operator may see an improved or degraded result without knowing which mechanism caused it. That weakens evaluation because the system under test is no longer stable enough to compare across runs.
Explicit surfaces create control. The harness can record the proposed change, its source, its authorizing policy, and the runs it may affect. It can also assign different permissions by consequence. Writing a temporary task note is not equivalent to modifying durable memory. Updating a skill used by one workflow is not equivalent to changing a shared system prompt. Broad and persistent surfaces deserve tighter approval, stronger evaluation, and a clearer rollback path.
Adaptation also needs failure containment. An incorrect operator inference, poisoned memory, or misleading task result should not silently propagate into unrelated work. Scope boundaries limit how far a bad update travels. Provenance makes the update inspectable. Versioning lets the harness restore the previous state. Regression checks detect when a local improvement breaks a behavioral invariant elsewhere.
I find it useful to review an agent system as a map of adaptation surfaces rather than as a single adaptive entity. For every component that can change future behavior, ask what writes to it, what validates the write, how long it persists, and which tasks consume it. This exposes hidden coupling. It also prevents a common design mistake: granting the agent permission to alter the very instructions, memories, or evaluators used to judge its work.
Not every response to feedback should become adaptation. Some signals are noisy, task-specific, or adversarial. A harness may retain them in an audit trail without promoting them into future context. The promotion decision is itself a control point and should be evaluated separately from the agent behavior it eventually changes.
Adaptation Surface vs Control Surface
The two surfaces can overlap, but they answer different engineering questions. An adaptation surface determines where future behavior changes. A control surface determines where an operator or policy can constrain execution.
| Concern | Adaptation surface | Control surface |
|---|---|---|
| Primary purpose | Change future behavior | Direct or limit current execution |
| Typical examples | Memory, prompts, skills, training, routing configuration | Approval gates, interrupts, budgets, permission policies |
| Main risk | Unattributed or over-broad behavioral drift | Insufficient authority or failure to stop unsafe work |
| Core evidence | Change history and before-and-after evaluations | Decisions, enforcement events, and execution state |
A memory editor can be both: it changes future behavior and gives an operator direct control over what persists. The distinction still matters because adaptation requires regression and rollback checks, while operational control requires reliable enforcement at execution time.
The Rifty take
We optimize for the smallest explicit adaptation surface that can produce the required improvement. We accept some friction in promotion, evaluation, and versioning because durable behavioral changes should be attributable and reversible. An agent should not quietly rewrite the policies or evaluators that define whether its own work is acceptable.
Implementation checks
- Inventory every component that can change behavior across steps, runs, or sessions.
- Record who or what may write to each surface and under which policy.
- Separate proposed adaptations from active ones so validation can occur before promotion.
- Attach provenance, scope, version, and expiry information to every persistent change.
- Evaluate the intended improvement and relevant behavioral invariants before broad rollout.
- Prevent task content from directly modifying privileged prompts, tools, policies, or evaluators.
- Provide a tested rollback path for every durable adaptation surface.
- Trace each run to the exact versions of the adaptive components it consumed.
- Treat unexplained behavioral change as a reliability fault, not as evidence that the agent learned.
Frequently asked questions
How do I identify an adaptation surface in an existing agent harness?
Trace every path by which one run can affect a later decision. Prompts, durable memories, retrieved records, skill files, tool descriptions, routing policies, and model versions are common candidates. A component is an adaptation surface when changing its state can systematically change subsequent agent behavior.
Should an agent be allowed to modify its own adaptation surfaces?
Only within a narrow scope and under an independent promotion policy. The agent may propose a memory, skill revision, or configuration change, but the harness should validate provenance, permissions, regressions, and blast radius before activation. Self-modification becomes unsafe when proposal, approval, and evaluation share the same authority.
Is memory always an adaptation surface?
Memory is an adaptation surface when later runs consume it in a way that can change behavior. A transcript retained only for auditing is not adaptive. A summary inserted into future context is. The distinction depends on the read path and behavioral effect, not merely on whether information persists.
How should adaptation-surface changes be evaluated?
Compare behavior before and after the exact versioned change, using tasks that test both the intended improvement and protected invariants. Keep model, tools, and surrounding configuration stable where possible. If multiple surfaces change together, attribution becomes weak and rollback decisions become harder to justify.
What is the main risk of having several adaptation surfaces?
The main risk is interaction without attribution. A prompt revision may conflict with durable memory, while a tool-description change alters which path the agent selects. Version each surface independently, trace the combination used by every run, and avoid simultaneous changes unless the combined behavior is the object being evaluated.