From Feedback to Organizational Learning: How AI Systems Should Improve Their Own Workflows

A workflow can finish successfully every week and remain bad at its job. The process ran, the agent returned an answer, and every step reached its terminal state. None of that establishes whether the result was useful, whether the workflow wasted money, or whether the same exception keeps returning because the organization never changed.

Teams often call the next step “self-improvement” and let an agent rewrite the prompt after a failure. That shortcut collapses evidence, diagnosis, authorization, and deployment into one opaque action. A mistaken judgment becomes active structure before anybody can inspect the reasoning or compare later outcomes.

Organizational learning needs a slower and more explicit loop. Execution produces evidence. An independent review interprets it with uncertainty. Repeated evidence supports a proposed structural change. A human authorizes the proposal. A new immutable version becomes active. Later executions test whether the change helped.

What is organizational learning for AI systems?

Organizational learning for AI systems is the governed process by which evidence from completed work can change future policies, workflows, roles, tools, or knowledge.

The learning object is the organization, not only the model. A better model response may fix one task. Organizational learning changes the conditions under which similar work runs later.

execution -> quality evidence -> pattern review -> change proposal
    ^                                               |
    |                                               v
post-change evaluation <- new version <- human authorization

Every transition should leave a durable record. Without that history, the organization cannot tell whether a later result came from the approved change, a provider update, a different input, or chance.

Why is completion status insufficient?

Execution status is deterministic evidence about process state. Quality is a judgment about the result relative to purpose and criteria.

A task may be done because the deliverable was submitted. It may still contain a weak analysis. A workflow may succeed because every node completed. The customer may still reject the outcome. A verifier may pass a schema while missing whether the recommendation is sensible.

Each genuine completion should therefore be eligible for a separate quality assessment. That assessment should be:

• asynchronous so it does not delay the completed work
• non-blocking so it does not reopen or rewrite history
• attributable to a reviewer and model version
• budgeted independently from execution
• explicit about criteria, evidence, uncertainty, and limitations
• append-only when work is completed again

An LLM can provide useful judgment where deterministic checks cannot. Its judgment is neither objective nor final. Keep it distinct from approval, verifier results, human review, and autonomy decisions so disagreement remains visible.

What are single-loop and double-loop learning?

Chris Argyris and Donald Schön distinguished between single-loop and double-loop learning.

Single-loop learning adjusts an action while preserving the governing rule. An outreach workflow changes the research query after low-quality prospects appear.

Double-loop learning questions the governing rule itself. The team asks whether prospect volume should be the controlled variable, whether the target segment is wrong, or whether the workflow should exist in its current form.

Learning loop	Question	Example change
Single loop	How can this operation meet its current target?	Add a source check before drafting
Double loop	Is this target, policy, or structure still appropriate?	Replace volume with qualified-conversation criteria

Agents can surface evidence for both loops. Changes to goals, authority, policy, budgets, or organizational structure require stronger authorization because they redefine success rather than improving execution within an accepted definition.

What is ultrastability?

Ashby used ultrastability to describe systems that can change the parameters of their own regulators when essential variables leave acceptable bounds. The concept is useful for AI operations if the second-order change remains governed.

An ordinary loop changes an action. An ultrastable loop can propose changing the workflow that selects actions. That ability increases adaptive capacity and the potential blast radius.

Safe ultrastability needs constitutional limits:

• evidence may trigger review but cannot silently mutate active structure
• some boundaries cannot be changed by the learning agent
• budget increases require separate authority
• active runs keep their snapshotted configuration
• failed experiments can be reversed through a new version
• the proposal and rejection history remain available

A system that rewrites itself after every noisy signal is unstable, not adaptive.

How should evidence become a structural proposal?

One poor result rarely justifies a new workflow version. The review process should aggregate bounded evidence and distinguish recurrence from coincidence.

A structural proposal should contain:

Field	Purpose
Observed pattern	Describe what recurred without hiding contrary evidence
Evidence window	Identify executions, versions, and dates reviewed
Proposed diff	Show exactly which instruction, relationship, role, or workflow changes
Expected effect	State which controlled variable should move and in which direction
Evaluation plan	Define evidence, timing, confounders, and rollback conditions
Cost	Expose expected model, worker, and human attention cost
Authority	Identify who must approve and why

The proposal should appear where the person can decide it with full context. Sending a notification that opens another surface leaves the control loop incomplete.

Semantic detection is useful for finding potentially related evidence. It should not silently impose a universal similarity threshold. A bounded reviewing agent can inspect authorized records and explain why it considers cases related. The proposal remains a judgment open to rejection.

Why must structural changes use immutable versions?

Learning changes the regulator. Immutable versions preserve which regulator governed each execution.

Stable identities let relationships continue to point to the same skill, agent, connector, team, project, goal, workflow, or schedule. Immutable versions own configurable fields and relationships. Publication advances the stable resource from one accepted version to another.

This model supports four critical properties:

• active runs continue under exact snapshotted versions
• competing proposals can be detected as stale
• rollback publishes a new version instead of erasing history
• post-change evaluation can compare executions from known evidence epochs

A coordinated change may involve several resources. Validate every base version before publishing any part. Partial publication creates an organizational state that nobody approved as a whole.

What should human authorization decide?

A reviewer should decide more than whether the proposal sounds reasonable. The decision should cover the proposed diff, evidence quality, authority boundary, cost, expected effect, and evaluation plan.

Approval does not prove the change will work. It authorizes a bounded experiment or policy revision. The system should preserve uncertainty and keep the proposal available if it becomes stale before approval. Staleness is evidence that the organization changed, not a reason to delete the reasoning.

High-autonomy agents may create ordinary resources within delegated authority. Organizational-learning changes should still require human approval. A system should not infer authority to redesign itself from authority to execute today's work.

How should a change be evaluated afterward?

Evaluation closes the learning loop. Without it, proposal approval becomes a ritual and every structural change is assumed to be an improvement.

The evaluation plan should specify:

• which future executions belong to the new version
• the minimum and maximum evidence window
• quality, cost, latency, exception, and human-attention measures
• known confounders such as new inputs or model changes
• conditions for keeping, revising, or reversing the change

Do not combine these signals into a universal competence score. Approval rate, verifier success, human quality judgment, autonomy, and cost answer different questions. Preserving them separately makes tradeoffs visible.

The first successful use is meaningful because it shows the version can produce the intended result once. Repeated successful use provides different evidence. Neither establishes causality on its own.

How should the learning loop expose cost?

Learning consumes model calls, worker time, storage, and human attention. Per-execution assessment and periodic pattern review need their own budgets and bounds.

A practical system limits:

• how much evidence one review reads
• how many proposals one cycle can create
• how often similar evidence can trigger another review
• which models and tools the reviewer may use
• how much spend can occur before a human decision

Budget exhaustion should stop the learning operation without blocking the original task. Hidden learning cost is still operational cost.

Which parts can Task Machine enforce today?

Task Machine records executions, routes proposals to the Inbox with their decision context, and publishes approved configuration as immutable versions. Active structure changes only after approval, and runs retain the versions they started with. Completed work can also open a prepared Chat for designing a repeatable approach without starting another agent run until a person sends the message.

Independent per-execution quality judgment and periodic structural review remain organizational practices a team must supply rather than capabilities to assume from the product. The current controls make proposed mutations authorized and version history comparable. They do not make an LLM reviewer correct or establish that one change caused a later outcome.

For a shorter account of why the gate matters, read A Self-Improving Company Is a Loop You Can Trust.

The complete cybernetics for AI operations series

Use this series as an audit sequence. Define the feedback loop, match regulatory variety to disturbances, inspect the internal model, map the organizational functions, and then decide which evidence is strong enough to justify a versioned change.