There is a change-management problem coming for agentic work.
At the moment, a common pattern is to keep working in the same thread.
That makes sense. The thread understands you. It remembers the job. It has the working context, even if some of it has been compacted. It knows what you have been trying to do, which systems matter, which rules you have already set, and which mistakes you are trying not to repeat.
That is useful. Very useful.
But it also means the thread is no longer just a chat.
It is becoming a small operating environment.
If the agent has memory, context, rules, and history, then change needs to be managed.
The opening brief becomes policy
A good technique at the start of a long-lived agent thread is to tell it who it is.
This is what you do.
This is how you work.
These are the problems we are solving.
These are the guardrails.
These are the systems you can access.
These are the things you must never do.
That works well, especially inside harnesses like Codex, Claude Code, coworker tools, and other agentic workspaces. You get consistency. You get control. You get fewer weird leaps. You reduce the chance that the agent wanders off and starts solving a different problem with great confidence.
Good.
But over time, those instructions harden.
What started as a helpful opening brief becomes policy.
And then, one day, you ask the agent to change direction.
It says, quite reasonably:
"Hang on. You told me not to do that."
Or:
"That conflicts with the rule you gave me earlier."
Or:
"I cannot implement that without changing the safety boundary."
That is not necessarily a failure.
That may be the system working.
Agents will inherit yesterday's instructions
This is exactly what happens in organisations.
A team says, "We cannot do that because the regulator said no."
Or, "We cannot do that because you told us not to."
Or, "That process was changed two years ago after an incident."
Sometimes they are right.
Sometimes they are hiding behind an old rule because nobody wants to own the change.
Sometimes the rule was valid in the old environment and is now blocking useful work.
Sometimes the person asking for the change has forgotten why the rule existed in the first place.
Long-lived agents will have the same problem.
If a thread runs for a day, it probably does not matter much.
If it runs for weeks or months, it does.
The longer the thread lives, the more it accumulates: instructions, decisions, habits, exceptions, warnings, preferences, shortcuts, and scars from previous mistakes.
That accumulated context is valuable.
It is also friction.
The change note
I think we need to start treating changes to long-lived agents more deliberately.
Not with a huge ceremony. Not with some grand enterprise framework. Just enough structure that the agent can understand what is changing and why.
A useful change note might say:
- what is changing
- why it is changing
- what previous instruction it replaces
- what must stay true
- which systems, projects, or decisions it affects
- whether the change is permanent, experimental, or temporary
- what the agent should challenge before accepting it
That is not bureaucracy. That is context hygiene.
Instead of saying, "Do this now," you say:
"This is a change to how we work. It replaces the previous rule about X. The reason is Y. Keep A and B unchanged. Before you implement it, tell me what conflicts you see."
That last sentence matters.
You want the agent to challenge the change.
Not because it is in charge.
Because it may remember something you have forgotten.
The agent's refusal may be useful
When an agent says no, the question is not simply, "How do I override it?"
The question is:
Is this a valid refusal?
Is it applying an old instruction correctly?
Is it applying an old instruction too broadly?
Is the old instruction still true?
Does the new instruction quietly weaken a guardrail that should remain in place?
That is judgement work.
We should not train ourselves to treat every agent objection as friction to be crushed. Sometimes the objection is the reason we wanted a long-lived context in the first place.
The agent can say, "I can do that, but it changes this boundary."
Or, "I can do that for this project, but not globally."
Or, "This conflicts with a previous safety rule. Do you want to supersede it?"
That is useful.
Good change and bad change
A good change is explicit.
It has a reason.
It says what it replaces.
It preserves the important constraints.
It gives the agent a way to ask questions.
It is recorded somewhere the next agent, the next thread, or the next compacted context can see.
A bad change is vague.
"Just do it differently now."
"Ignore that."
"Don't worry about the old rule."
"You know what I mean."
Maybe the agent does know what you mean.
Maybe it does not.
Maybe it knows exactly what you mean and also knows it conflicts with the boundary you set last week.
That is where the danger lives: not in the model suddenly becoming dramatic, but in silent permission drift.
Make the history visible
The answer is not to code a massive system before doing useful work.
Start simpler.
Keep a change history.
When you change how a long-lived agent works, record the change in plain language.
Ask the agent to restate the new operating rule.
Ask it what the change conflicts with.
Ask it what it will still refuse to do.
Ask it what should be moved into a more durable instruction, policy file, MCP, memory layer, or team operating note.
This is not just about making the agent obedient.
It is about making the agent legible.
A practical starting point
When you next change direction in a long-running agentic thread, try this:
"This is a change to your operating instructions. Before applying it, identify any conflicts with earlier instructions, tell me what remains unchanged, and suggest the smallest safe way to implement it."
That small habit changes the relationship.
You stop treating the thread like a scratchpad.
You start treating it like a working system with history.
And if that is what long-lived agents are becoming, then change management is not a corporate add-on.
It is part of how we keep them useful.