A self-improving agent sounds like the obvious goal.
It does the work. It sees the result. It learns what performed better. It updates its own instructions and becomes more effective every time it runs.
No waiting for a quarterly process review. No stale rulebook. No manager slowing it down.
In a controlled experiment, that can sound ideal.
Inside a real organisation, it raises a more important question:
What exactly is the agent allowed to learn?
Suppose a proposal agent notices that larger discounts are associated with more signed contracts. Should it lower the default price?
Perhaps.
But what if those contracts are less profitable? What if delivery is absorbing extra scope? What if the pattern comes from one salesperson’s strongest quarter, a temporary market condition or a handful of strategic exceptions?
The agent has found a signal.
It has not necessarily found a new rule for the business.
Learning and changing are not the same thing
We use the word “learning” to describe several different activities.
An agent can observe what happened. It can find a pattern, produce a dashboard and suggest an explanation. It can compare outcomes and recommend an experiment.
Those are valuable capabilities.
Changing the organisation’s specification is different.
A specification expresses the current commitment people and agents are expected to work from. Changing it may alter what sales promises, what delivery accepts, what customers experience and what managers are accountable for.
That is not simply a data update.
It is a management decision.
Agents surface what the organisation might learn. Accountable people decide what the organisation has learned.
This does not put a person in front of every observation. It puts ownership around the moment an observation becomes organisational behaviour.
An exception is not automatically a new rule
This distinction matters most when an agent is involved in real decisions.
Imagine the standard commercial specification protects a particular margin. A large customer asks for an exception. The sales manager reviews the strategic value, delivery capacity and likely follow-on work, then approves it.
The agent should record what happened and why.
It should not conclude that the protected margin has changed for every future proposal.
The approval may be:
- a one-off exception for this customer;
- permission for a defined class of similar customers;
- an experiment the business wants to observe;
- evidence that the standard pricing model needs review; or
- a genuine change to the organisation’s commercial rules.
Those possibilities can look identical in the final transaction. They mean very different things for the next one.
An approved exception is not automatically a new rule.
If agents learn only from what was allowed to happen, informal workarounds can quietly become official policy.
The business does not become smarter. It automates its drift.
Signals, experiments and specifications move at different speeds
A useful operating model separates three layers.
1. Signals can move quickly
The agent observes outcomes, finds patterns and surfaces anomalies.
Proposal acceptance has fallen. Candidates from one source stay longer. A particular customer question appears before more successful sales. One kind of exception produces more delivery overruns.
These observations can update continuously.
They are evidence, not instructions.
2. Experiments can move quickly too
The organisation decides to test a variation within a defined area.
It may try a different proposal structure, a narrower qualification rule or a new handoff. The experiment has an owner, an intended learning and a boundary around who or what it affects.
During the experiment, the standard specification still matters. The organisation knows it is testing something rather than silently changing the default.
3. Specifications should change deliberately
When the evidence, experience and consequences are understood, an accountable person may decide the organisation has learned something durable.
The specification changes. The rationale is recorded. Connected work is updated. People know when the new commitment takes effect.
The speeds may be closer together early on while a new Loop is being tuned. As more people and systems depend on it, the change bar should rise.
Fast to observe. Fast to experiment. Deliberate about what the organisation treats as true.
Most business decisions do not have laboratory-quality data
It is tempting to imagine every specification improving through continuous A/B tests.
Some high-volume digital environments can support that.
Much ordinary business work cannot.
A company may make a modest number of senior hires each year. It may issue complex proposals where no two opportunities are truly alike. A legal exception may be rare by definition. A marketing campaign may run in a different market, season and competitive context from the one before it.
The data still matters. It just does not remove the need for judgement.
This is why businesses employ capable people with experience, context and responsibility for an outcome. Their job is not to compete with the dashboard. It is to combine the available evidence with things the data cannot settle by itself.
An agent can make that job much better.
It can collect the evidence, find relevant precedents, trace which teams are affected and present options with their trade-offs. It can show what it does not know.
The person still owns the choice.
Automatic learning can become management drift
If every new pattern immediately changes the specification, the business can become highly responsive and poorly directed at the same time.
A metric moves. The AI suggests a change. A leader accepts it. Another metric moves the following week and the organisation changes again. Each action has evidence behind it, but nobody maintains a coherent view of why the business now works this way.
That wider leadership failure is what I call vibe management. The risk here is specific: an agent's ability to update instructions can turn short-term observations into operating rules before people have understood or owned the consequences.
A dashboard can explain what just happened. It cannot take responsibility for what the organisation becomes.
Every change carries a tax
A change to the specification rarely stays inside the document.
People need to understand it. Agents need the new version. Connected workflows may need updating. Measures may need to change. Customers may already have expectations based on the old rule. Another team may have built its work around the previous handoff.
That is the change tax.
AI can reduce it.
An agent can identify dependencies, update supporting material, notify affected people and explain what changed in language relevant to their role.
It cannot make the tax disappear.
Someone still has to absorb the new expectation. A manager still has to reconcile it with the strategy. A team may need to change behaviour. Work already underway may need a transition rule.
The larger the organisation and the more agents acting from the specification, the more important this becomes.
A small edit can change thousands of future actions.
The ability to change faster does not remove the need to change deliberately.
What should an agent be allowed to do?
The right answer is not to freeze every specification until a committee meets.
A learning agent should be active in the process. Its authority should be clearer than “improve yourself.”
It can usually:
- collect outcomes and supporting evidence;
- surface patterns, conflicts and anomalies;
- identify when a rule appears to produce the wrong result;
- find previous exceptions and their stated reasons;
- propose an experiment;
- draft a change to the specification;
- trace likely effects on connected work; and
- route the proposal to the person who owns the outcome.
It should not quietly:
- convert an exception into a default;
- optimise one team’s metric at the expense of the whole business;
- treat correlation as a settled business decision;
- erase the reason an existing rule was introduced;
- change authority or accountability; or
- leave affected people working from different versions of the truth.
The important boundary is not “AI may never edit a document.”
An agent can prepare the edit. It can maintain references and make approved changes across connected materials.
The important boundary is who decides that the proposed edit now represents the organisation’s commitment.
What should a proposed change contain?
Do not send the owner a vague message saying, “Performance may improve if we change the rule.”
A useful proposal should include:
What has been observed?
Show the result, pattern or conflict, including the period and work it covers.
What might explain it?
Separate evidence from interpretation. Include plausible alternative explanations and missing information.
What is being proposed?
State the exact change in plain language. Show the current rule and the proposed rule side by side.
Is this a test or a durable change?
If it is an experiment, define the scope, duration, intended learning and conditions for stopping.
What else will it affect?
Identify people, agents, measures, customer commitments and connected Loops that depend on the current specification.
Who owns the decision?
Send it to the person accountable for the outcome, not simply the person most available to approve it.
When does it take effect?
Clarify whether current work stays on the old rule, moves to the new one or needs individual review.
This turns “the agent wants to change something” into a management decision a capable person can actually make.
A simple change ladder
Not every learning needs the same level of control.
Use a change ladder that reflects how widely the specification is trusted and how consequential the decision is.
Observe
The agent records a signal. No operating rule changes.
Suggest
The agent proposes an explanation or improvement for an owner to consider.
Experiment
A named owner approves a limited test with clear boundaries.
Adopt
An accountable person changes the specification and coordinates its effect on connected work.
Stabilise
Once a rule is well established and widely depended upon, changes require stronger evidence and more deliberate communication.
The purpose is not to slow every improvement.
It is to let evidence move quickly without allowing organisational commitments to move accidentally.
How this fits a spec-driven organisation
In a spec-driven organisation, specifications are living because the work can improve them.
They are owned because improvement is not the same as automatic mutation.
Agents carry out work from the current specification. Results flow back as evidence. Agents can identify gaps and propose updates. Accountable people combine that evidence with strategy, experience and consequences, then decide whether the organisation has learned a new rule.
The updated specification guides the next round of work.
That creates a real learning loop without separating people from the outcomes they own.
Bottom line
AI agents should help specifications improve, but they should not quietly rewrite the rules the organisation depends on. Agents surface evidence, suggest experiments and prepare changes. Accountable people decide when a result becomes a durable organisational commitment.
Keep signals fast. Keep experiments easy. Change trusted specifications deliberately.
That is not a brake on learning.
It is how the organisation learns without losing the ability to explain, coordinate and own what it has become.
BusyWork Dispatch is designed around living Workbooks: agents can use current organisational context and propose updates when completed work changes what is true, while people retain ownership of durable decisions. See how BusyWork works or book a call with Ben.
