An agent that can edit its own prompts, skills, memory, or sub-agent setup has crossed into a different kind of engineering problem.
The question is no longer only what the agent can do during this task. It is also what it is allowed to change about the conditions of every task that follows.
Prime Intellect’s recently announced Prime Agent makes that distinction visible. Its Continual Harness treats prompts, skills, memory, and sub-agents as state an agent can create, read, update, and delete during its own trajectory.
That is an interesting capability. It also means that a harness update deserves the same care as any other consequential workflow change.
01
The harness is now a control surface
A tool call has a familiar shape. An agent reads a file, queries a service, drafts a response, or prepares a report. You can define its permissions, validate the result, then decide what happens next.
Harness changes are different because they alter future behaviour.
A new skill can change how work is carried out. A memory update can alter which context gets retrieved later. A prompt edit can change a decision pattern that nobody is watching in the current moment. A persistent sub-agent can retain a role, instructions, and assumptions beyond the task that created it.
None of that is automatically unsafe. It is simply a larger surface to govern.
The mistake would be to treat every self-generated update as harmless housekeeping. If a change can affect a later decision, access pattern, or external action, it needs a defined path into the system.
02
A proposed change needs a policy
I would begin with a narrow question: what category of state is changing?
A scratch note written for one task is different from a shared memory entry. A local prompt experiment is different from a skill that other agents will use. A temporary helper is different from a persistent sub-agent with access to tools or sensitive context.
The policy does not need to be complicated. It does need to be explicit.
For each category, define four things:
- Allowed scope. Which agent can propose the change, where can it write, and who or what can use the updated state afterwards?
- Required evidence. What should accompany the proposal: a task reference, a failure it addresses, a test result, or a reviewer’s note?
- Validation path. Which checks are deterministic, and which changes require a person to inspect the proposal?
- Recovery path. Can the prior state be restored, and can someone reconstruct why the change happened?
That gives a team a useful answer when an agent decides it has found a better way to work: perhaps. Show the change, show its scope, and show how it will be checked.
03
Keep the decision path deterministic
A model can be useful in this loop. It can identify repeated friction, suggest a revised instruction, write a candidate skill, or explain why an earlier attempt failed.
It should not silently decide every boundary around those changes.
Deterministic code is well suited to the parts that need predictable treatment: permitted write locations, schema checks, version creation, approval requirements, retry limits, and rollback rules. A model can propose a change in natural language. The system should decide whether the change belongs in a draft area, can be applied within a narrow policy, or must wait for review.
This is the same split that matters in document workflows. Models can interpret an ambiguous document, classify a request, or prepare a recommendation. The surrounding workflow handles permissions, state transitions, validation, approval, and recovery.
04
A small control path is enough to start
A useful first design does not require a large governance program. It can be a short, inspectable route:
proposed change → policy check → validation → automatic update or human review → versioned state and rollback record
The important detail is that each stage has a real condition.
For example, an agent might be permitted to write a task-local note after passing a schema check. It may propose a new reusable skill, yet that proposal stays in review until a person confirms its scope and wording. A change to a shared memory source may require a source reference and a named approval record before it becomes retrievable by other agents.
The workflow is then able to say more than “the agent learned something.” It can show what changed, where it came from, who could use it, and how to reverse it.
05
Review should follow risk and reach
Human review does not need to sit in front of every write. That would turn the harness into a queue of small edits and make the system harder to use.
It belongs where a change has meaningful reach.
A practical rule is to look at two dimensions:
- Scope: Does the update affect one task, one project, or many future tasks?
- Authority: Could it change access, influence an external action, modify a shared decision rule, or affect client-facing work?
The further a change travels, and the more authority it carries, the stronger the review and recovery requirements should be.
That keeps the small things small. It also prevents a convenient local improvement from quietly becoming an organisation-wide behaviour change.
06
Evaluation has to include the harness state
Most agent evaluation focuses on immediate outputs: did the model extract the right field, use the right tool, or route the case to the right person?
Those tests still matter. A system that can update its own harness adds another question: did the update make the next task better, worse, or harder to inspect?
This calls for a few extra cases in an evaluation library. Test an update that should be accepted. Test one that should remain task-local. Test a proposal that lacks evidence. Test an attempted write outside the allowed scope. Test a rollback after a bad change. Test whether a reviewer can recover the relevant context without reading a transcript dump.
The aim is to make adaptation legible enough that a team can decide when to trust it, correct it, or stop it.
07
The capability is only the beginning
Self-modifying harnesses will make many systems more capable over time. The useful engineering response is precision about the change surface: what may evolve, what must be checked, who retains authority, and how the system gets back to a known state when a change is wrong.
That is where agent reliability starts to look less like a model-selection problem and more like workflow design.
If you are giving an agent the ability to change its own working environment, what is the first change you would require it to explain and justify?