The closed intelligence loop: how an organisation gets smarter through AI

What is the closed intelligence loop?

Most enterprise AI projects are a straight line. Someone picks a model, connects some data, builds an assistant, ships it, and moves on. The assistant answers questions the same way in month twelve as it did in month one, because nothing that happens after launch is wired back into what the system knows or what it is allowed to do. The line never becomes a circle.

The closed intelligence loop is the circle. It is the value chain of the Sovereign Intelligence Platform, read as a cycle rather than a pipeline: Control, then Intelligence, then Agency, then Execution, then Outcomes, and then the evidence from those outcomes flows back into data and context, so the next pass starts from a better place. The word 'closed' matters. An open loop produces outcomes that nobody feeds back. A closed loop treats every outcome, approval, correction and policy decision as raw material.

This page explains the mechanism: what each stage does, exactly what flows back, how to capture it, what must never flow back, and how to tell whether your loop is actually closing. For the category definition, start with the pillar page and what sovereign intelligence is. For the principle that makes the loop safe to run, see runtime governance.

What are the five stages of the loop?

The stages map onto the six layers of the platform. Two layers, data and models, share the Intelligence stage because both turn raw material into something useful. The table uses the platform's own wording for each stage.

Read the last row twice. Outcomes is not the end of the chain. It is the stage that closes it. The business result, together with the record of what the system did to produce it, goes back to Data & Context and to the evaluation sets that govern Intelligence & Models. The Control stage changes more slowly, but it is also informed: a pattern of denied actions or slow inference is evidence that a boundary needs to move.

What exactly flows back into data and context?

'Feedback' is too vague to build against. In a governed environment there are five concrete kinds of signal, and each has a different destination.

• Outcomes. Did the business result happen, and did it hold? A purchase recommendation that was accepted and delivered on time is a different signal from one that was accepted and later disputed. Outcomes go to the solution's measures and to evaluation sets.
• Approvals and rejections. Every time a person approves, edits or rejects an agent's proposal, they are labelling it. The pattern of edits shows where the agent is systematically wrong. These go to evaluation sets and to the agent's Trust Profile review.
• Corrections. A human fixing a wrong answer, a mislabelled document or an outdated supplier record has produced new knowledge. Corrections go to the knowledge base, with provenance, after review. They should not write themselves into context without a check.
• Evaluation results. Scores from regression suites, groundedness checks and cost and latency measures say whether a model, prompt or retrieval change made things better. They go to model selection and routing decisions.
• Policy decisions. Allow, deny, warn, filter, escalate and require-human-approval events show how policy behaves in practice. A policy that escalates nearly every request is a tuning problem, and one that never fires may be a coverage gap. These go to the policy owner.

Notice that none of these require training a model. The loop works at the level of context, evaluation and policy. That is deliberate. Improving what the organisation retrieves, how it evaluates and what it permits is faster, cheaper and far easier to audit than changing model weights. Teams that want to go further can tailor models, which is a model sovereignty decision, but the loop pays off long before that.

How do you capture the signals?

The loop depends on one capability that is easy to under-build: a trace that connects data, model, agent, decision, action and outcome. That chain is the platform's definition of traceability, and it is what makes feedback attributable. Without it you know an outcome was bad but not which retrieval, model version or policy produced it.

1. Give every run an identity and an ID. The agent, the user it acts for and the workflow instance should all be recorded, so a later outcome can be joined back to the run.
2. Record the inputs that shaped the answer. Which documents were retrieved, which model and version answered, which tools were called, which policy rules applied. This is the 'records' column of the AI Procurement Agent example below.
3. Capture human decisions as structured data. An approval button that stores approve, edit or reject plus a reason code is worth far more than a free-text comment nobody reads.
4. Attach outcomes later, by join. Many results arrive days after the action: a delivery, a payment dispute, a resolved ticket. Keep the run ID so the outcome can be attached when it lands.
5. Route each signal to a named owner. A signal with no owner is a log line. Knowledge corrections go to the knowledge owner, policy tuning to the policy owner, model regressions to the platform team.

If you use open tooling for traces, note that the OpenTelemetry conventions for agent and generative AI spans are still at Development status rather than Stable, so treat attribute names as subject to change. See the agent span conventions (opens in a new tab) for the current state. Step ten of the build guide covers operating this in practice.

What must not flow back?

A loop with no filter is a leak with a feedback label. The same sovereignty controls that govern the first pass govern the return path.

• Restricted or classified data. An outcome record can contain the very data the agent was not allowed to export. Data controls apply to traces, evaluation sets and knowledge bases exactly as they do to the source systems.
• Unreviewed changes to behaviour. A correction that silently alters what every agent believes is a change to production. It needs the same review as any other change, with an owner and a way back.
• Signals from outside the approved scope. An agent allowed to read supplier information should not have its stray reads of other records absorbed into its context.
• Anything that would let an agent widen its own authority. Level changes are made by the accountable owner and recorded, never inferred from the agent's own success rate. See controlled autonomy.
• Data crossing the organisation's boundary without a decision. Whether any aggregate signal leaves your environment is your decision. Swfte's current statements about data handling are on the trust page; where a policy statement is not yet confirmed there, it is shown as a placeholder rather than implied here.

How does the loop relate to adaptive AI?

The fifth level of the autonomy ladder is L5 Adaptive: AI improves within controlled boundaries. The closed loop is how that sentence becomes operational. Adaptation is not an agent rewriting itself. It is the organisation adjusting context, prompts, retrieval, thresholds and, where justified, models, based on evidence, with each change tested, versioned and reversible.

Three rules keep adaptation controlled. First, boundaries cannot be self-modified: the policy set, the permitted systems and the approval rules sit outside the thing being adapted. Second, every change is gated by evaluation: a candidate change must beat the current version on a fixed evaluation set before it goes live. Third, every change is attributable, so a regression can be traced to a specific change and rolled back. Most agents should never reach L5. Many should stay at L2 or L3 permanently, and the loop still makes them better, because improving context does not require raising autonomy.

What does one cycle look like? A procurement walk-through

The platform's worked example is the AI Procurement Agent. It can read approved supplier info, analyse contracts, compare pricing, prepare purchase recommendations and create draft POs. It cannot access unrelated employee data, approve its own high-value transaction, make payments or modify restricted records. Purchases above threshold, contractual changes and sensitive external comms require approval. It records identity, data accessed, model used, output, tools called, policy applied, decision, approval, action and outcome. Here is how one cycle of the loop runs through it. The scenario is illustrative, not a customer story.

The next cycle starts with better context and a sharper test. The approver is editing quantities less often, and the evidence for that is on record. That evidence is also what supports a later decision to raise the agent's autonomy from approving every draft to supervising within limits, or to keep it where it is.

How do you know the loop is working?

A loop that is closed in the diagram and open in practice is the usual state. Measure the loop itself, not only the solution it serves.

• Attribution coverage. What share of outcomes can be joined back to a run, with its data, model, agent and policy context? Low coverage means the loop cannot close.
• Feedback latency. How long from an outcome to a reviewed change in context or evaluation? Measure it in your own units and watch the trend.
• Correction reuse. Are reviewed corrections reaching the knowledge base, or do people fix the same mistake repeatedly?
• Approval-edit trend. For agents at L2 and L3, are edits and rejections falling for reasons you can name?
• Regression catch rate. How many changes were stopped by the evaluation gate before they reached production?

Do not set targets from someone else's benchmark. Take a baseline in your own environment, then look for direction. Numbers invented for a slide do not tell you whether your loop is closing.

How does the loop fail?

Loops fail in a small number of recognisable ways.

Why does the loop matter to the organisation?

The point of the loop is a simple customer benefit: the organisation gets smarter through AI. What it learns from running agents, from its people's corrections and from its measured results becomes context it owns. That is the practical meaning of intelligence sovereignty: proprietary knowledge, memory and derived insight stay assets the organisation can inspect, move and keep.

It also changes the economics of adoption. Each governed deployment leaves behind better context, a sharper evaluation set and a clearer record of what the AI may do. The next use case starts further along. That is why the platform is built as one environment with several entry points, rather than as isolated tools: the solutions layer produces the outcomes, and the loop carries what was learned back to where the next solution will draw on it. For how the loop appears at the architecture level, see the reference architecture, and for the thesis that sits behind it, capability plus control.