The Times Are Changing. Memory Has Never Mattered More.

When AI does the work, “done” needs evidence, a date and a memory.

Six weeks ago, an AI agent completed a task. The result passed its checks. Someone approved it. The organisation moved on.

Today, a requirement changes.

The output has not changed. The reassuring green tick is still there. But the conditions that made it acceptable may no longer hold.

Was the original decision wrong? Is the result still safe to use? Which other jobs depended on it? And can anyone explain what “approved” actually meant at the time?

These are becoming practical questions about how we organise work. As we delegate more to AI, our ability to remember why a decision was justified becomes more valuable.

The faster things change, the more carefully we need to preserve the reasoning, evidence and circumstances behind what we accepted.

Effort is not an outcome

We are getting better at measuring AI activity. We can count tokens, tool calls, processing time and completed runs. We can put a price against much of it.

But activity tells us surprisingly little about attainment.

An agent can work hard, consume very few resources and produce an accurate answer that fails to solve the problem. It can also produce something useful through an expensive sequence of retries, corrections and human intervention.

A more costly model may deliver the cheaper successful outcome. A cheap model may leave a substantial checking bill.

I think we need to distinguish four measures.

Effort is the work performed by people and machines. Cost is what that work consumes. Accuracy concerns whether particular claims and actions are correct. Outcome concerns whether the intended purpose has been achieved.

These measures are connected, but none is a substitute for the others.

A training document might be factually accurate and inexpensive to produce. If a new starter cannot use it without repeatedly asking an experienced colleague for help, how much work have we really saved?

The difficult little word: done

“Done” sounds wonderfully decisive. In practice, it often conceals several different states.

The agent has finished. The output has passed its checks. An authorised person has accepted it. Using it has produced the intended benefit.

Those things may happen days or months apart.

A course can be delivered today. Its content can pass review tomorrow. Whether it changes practice may take much longer to establish.

We should record those distinctions rather than compress them into a single completion flag. Otherwise, a system designed to count finished tasks can quietly become a system that overstates achieved outcomes.

“Good enough” also needs a purpose. A rough internal draft and an instruction that authorises a consequential action should have different acceptance conditions. The tolerance for error depends on what happens next.

An agreement people and machines can understand

My starting point would be an outcome agreement established before execution.

In plain language, it should explain what we want to attain, who will use the result, what must be true, what failures are unacceptable, what evidence is required and who can accept it.

The same agreement should have a structured form that software can check.

For a procedure intended for new starters, that might mean:

• Every mandatory step references the current approved source.
• No critical step is missing.
• A representative user can complete the task within agreed limits on assistance.
• Exceptions and unresolved questions are visible.
• The process owner records acceptance against the evidence.

Examples matter too. Show an acceptable result, a borderline result and a failure—and explain why each falls into that category.

This gives people and machines something more useful than “produce a high-quality answer”.

It does not make every judgement machine-solvable. A system may verify that a user trial took place without being able to judge whether the trial was representative. Human judgement belongs in the agreement wherever it is needed, with its basis recorded.

Who audits the auditor?

Adding another AI to check the first does not settle the question.

Two systems can agree because they share the same assumptions, misleading source or blind spot. Human approval can be equally weak when the reviewer lacks the time, expertise or authority to challenge the result.

An endless chain of reviewers would simply move the problem.

Instead, the evaluator needs its own evidence of fitness for the task: known failures it should catch, examples it should accept, recorded disagreements and checks against what happens when outputs are used.

The evaluation method needs a version too. We should know which rules and sources the auditor applied, what it could assess and what lay outside its scope.

And somebody must remain accountable for reopening an accepted decision when contrary evidence appears.

Yesterday’s acceptance, today’s requirements

This is where memory becomes essential.

We need to answer two questions separately: was this acceptable when the work was performed, and is it still acceptable for use now?

A requirement therefore needs more than a line of text. It needs an owner, scope, version and effective date. Where relevant, we also need to distinguish when the organisation learned about a change from when that change took effect.

An accepted outcome should retain the requirements, evidence and evaluation method used to approve it.

When a requirement changes, the system should identify dependent outcomes and assess what follows. Some may remain valid. Others may need review, correction or withdrawal.

The historical record should survive that reassessment:

Accepted against version 3 on 18 August. A relevant requirement changed on 29 September. Review is pending before further use.

That is an illustrative record, but it captures something important. We preserve the justification for the earlier decision while making its present limitations visible.

Memory as part of the work

These questions are shaping how I think about Agent Control and its experimental Digital Labour Exchange.

A job budget, model choice and transaction record help us examine the cost of an accepted outcome. The next question is how that acceptance remains connected to changing requirements and subsequent evidence.

That is a direction to develop and test, not a claim that every part has been solved.

It also connects with my long-standing belief in wirearchy: knowledge and influence flowing through relationships, with clear accountability. The person using an output may discover its limitations before the person who commissioned or approved it. Their challenge needs a route back into the system.

Useful organisational memory preserves those challenges, alongside decisions and reasons. Keeping every log forever would not achieve that; we need records that are relevant, retrievable and appropriately protected.

The economics change as well. The cost of digital labour includes maintaining confidence in an outcome for as long as we rely on it.

We are learning to make machines produce work faster. We must also learn to preserve what made that work worth accepting.

The times will keep changing. Our memory should help us recognise when yesterday’s good answer has become today’s unfinished business.

Also published on Medium ↗.

This article reflects the evidence and development status at its original publication date.