The six functions of a working AI system

The way an experienced practitioner thinks about their work is a useful place to start when designing an AI system that needs to hold together over time.

A senior valuer doesn’t make valuation decisions by guessing. There’s a body of reference material she’s trained on, a schema by which she organises the properties and engagements she handles, a practice of capturing what happens on each inspection, a memory that builds across years of comparable sales and edge cases, a set of professional standards that govern what gets stated in a written report and signed off, and the reports and advisories that compound into a practice’s accumulated authority.

Six functions, each with a specific role. None of them sufficient on their own. All of them required for the practitioner to do work that holds up to scrutiny.

An AI system that works the same way looks structurally identical, and that isn’t coincidence. The six functions are not specific to human cognition. They’re the structure of any thinking system that has to produce reliable output in a domain where mistakes are expensive.

We build AI systems this way because it’s the architecture that actually holds together once a client puts real work through it.

1. Knowledge: the body of reference

The first function is the body of reference material the system can draw on. For a practitioner this is everything they were trained on plus the professional standards their work has to meet. For an AI system it’s the curated knowledge base the system retrieves from when producing output.

The discipline that makes this function load-bearing rather than decorative is curation. A pile of documents in a vector database is not a knowledge layer; it’s storage. A knowledge layer is a maintained, current, scoped corpus of material that the system has been told to trust, with explicit rules about which sources outrank which when they conflict.

For a clinical practice it’s the relevant clinical literature, the practice’s protocols, the local regulatory standards. For a legal practice it’s the case law, the firm’s precedents, the practice notes. For a valuation practice it’s the standards, the recent comparable sales, the firm’s prior reports. The shape of the knowledge layer is industry-specific. The discipline that makes it work isn’t.

2. Entity model: the schema

The second function is the structure by which the system organises the things the business actually cares about.

For a clinical practice the entities are patients, episodes of care, treatment plans, prescriptions, claims. For a property services business they’re properties, owners, tenants, jobs, trades. For a coaching practice they’re clients, sessions, goals, commitments, progress markers.

The entity model is the system’s understanding of what kind of business it’s in. Without it, the system treats every input as a generic blob. With it, the system knows that a new email from a particular client refers to the existing matter with that client, who has an open file, whose last interaction was three weeks ago, and whose specific situation governs how this email should be classified, routed, and responded to.

A well-designed entity model is what lets the system answer the question “who is this about and what’s already known” before generating any output.

3. Capture: perception

The third function is the practice of capturing what happens with each entity.

A practitioner takes notes. The notes go into the file. The file accumulates over months and years. By the time the practitioner sits down to make a decision, the file holds the history of everything that has happened with this matter.

An AI system that mirrors this captures the inputs that arrive (emails, calls, transcripts, documents, photos, decisions), tags them against the entity model so they’re attached to the right entity, and stores them in a way that the memory layer can later consolidate and retrieve.

The discipline that makes capture work is doing it at the point of interaction rather than as a retrospective batch. Transcribing a meeting that ended yesterday is harder than transcribing it as it happens. Recording a decision at the moment it was made is more accurate than reconstructing it from memory a week later. A working capture layer is real-time or near-real-time, attached to specific entities, and consistent across input types.

4. Memory: consolidation

The fourth function is the working memory of the system: what gets retained, indexed, and consolidated across all the captured interactions.

This is where most AI systems quietly fail. Capture without consolidation produces a haystack that’s harder to search than the email inbox it replaced. The memory function isn’t a vector database; it’s the deliberate organisation of captured material into something that can be retrieved at the right level of detail when the system needs it.

A working memory function does three things. It consolidates raw interactions into summarised facts the system can reason over. It indexes those facts against the entity model so retrieval is anchored to “what do we know about this client” rather than “what documents mention this client”. And it tracks recency so the most current information takes precedence when older information has been superseded.

The result is that when the system is asked to produce an output, the relevant context is available, accurate, and appropriately scoped. Not the entire history. Not nothing. The right slice.

5. Safety and egress: judgement

The fifth function is the layer that governs what gets externalised. In a human practitioner this is professional judgement: what gets stated in a report, what gets said to a client, what gets escalated, what gets withheld pending more information. In a regulated practice the same judgement is shaped by ethical standards, confidentiality obligations, and the rules of the profession.

In an AI system the equivalent function is a deliberate safety and egress layer. Personal-information masking before any data leaves the system. Confidential compute routing for sensitive payloads. Audit logging of every interaction. Source attribution on outputs. Verification of outputs against the captured material before they reach a customer, a regulator, or a system of record.

This is the function that protects the system from itself. Without it, the system might generate technically sensible output that is nonetheless unsafe to externalise because it includes information that shouldn’t leave, or makes claims that haven’t been verified, or fails to attribute statements to their sources.

The safety and egress layer is what makes the architecture viable for regulated and quality-sensitive contexts. In those contexts, output that hasn’t passed through this layer isn’t useful. It’s a liability.

6. Compounding outputs: action

The sixth function is the actions and outputs the system produces from everything above it.

For a practitioner the outputs are reports, advisories, decisions, recommendations, treatment plans, drafted correspondence. The practice’s accumulated output is what compounds into authority over years.

For an AI system the outputs are the same shape: drafted documents, structured responses, scheduled actions, summaries, advisories. What makes them compounding rather than disposable is that each output is captured back into the memory layer (function 4), available to inform the next output. A report drafted this month becomes part of the context for the next report next month. A decision made in this matter is available when a similar matter arises.

Outputs that don’t compound are tools. Outputs that compound are the building blocks of an institutional memory the business owns.

How this addresses hallucination

Hallucination, the generation of content not supported by the underlying material, is the single most common failure mode of AI systems in production. The six-function architecture addresses it at every layer.

The knowledge layer provides a curated body of reference material the system can verify claims against. The entity model anchors every statement to a specific entity, so claims about a particular client’s matter can be checked against what’s actually been captured about that matter. The capture layer provides the factual evidence base. The memory layer ensures the system retrieves the relevant context rather than guessing. The safety and egress layer runs verification on outputs before they leave, flagging anything unsupported. And the compounding outputs feed back into the memory, so verified outputs strengthen the system’s accuracy on similar tasks.

The result is that hallucinations are caught at multiple points before they reach a human. Some are caught during retrieval (the system doesn’t have evidence for the claim, so it doesn’t make it). Some are caught during draft generation (the system flags low-confidence statements). Some are caught during verification (the safety layer compares the output to the captured material and surfaces gaps). The defence is layered, which is the only kind of defence that holds against a failure mode this stubborn.

How this gives stability of outputs

Two outputs from the same system on the same task should look substantively the same. Stability is what makes the system trustworthy.

The six-function architecture is deterministic about which context goes to the model. The knowledge layer, entity model, capture, and memory together produce a stable retrieval result for a stable input. The model’s job is to generate output from a context that has already been narrowed and structured.

This matters because language models themselves have inherent variability. The same model asked the same question twice will produce slightly different output each time. The architecture above absorbs that variability by tightly controlling what the model sees, so the variation that does occur is in the language rather than in the substance.

When a client says “the system produced inconsistent results last week,” the answer is almost never the model. It’s almost always that the context being supplied wasn’t stable. Fix the context layer and the model’s variation disappears into normal style differences.

Why this is model-agnostic

The six functions describe roles. They don’t prescribe which model fills the generation role at the top.

A capable language model can be swapped in for another without changing the architecture beneath it. Claude can be replaced by GPT can be replaced by Gemini can be replaced by a domain-specialised open-source model, and the system continues to work. The knowledge layer doesn’t care. The entity model doesn’t care. The memory layer doesn’t care. The verification step doesn’t care. Only the language generation step changes, and that step is the most commoditised part of the stack.

This matters commercially because the model market is moving faster than anything else in the AI landscape. A system built around a specific model gets harder to maintain as the model changes, gets deprecated, or gets superseded by a better one. A system built around an architecture stays useful as models change underneath it.

It also matters for cost. Different models have different cost profiles. A six-function architecture lets a business use the right model for the right job: a cheap fast model for routine drafting, a larger model for sensitive verification, a specialised model for domain-specific tasks. The architecture doesn’t care which is doing what.

How this compounds

The compounding behaviour of a working AI system comes from feedback between the capture, memory, and compounding-outputs layers.

Every interaction the system handles enters the capture layer. Every captured interaction is consolidated into memory. Every output the system produces is itself an input to memory, available to inform the next output. Every human correction becomes a signal that adjusts the next response. Every novel pattern that emerges in the data becomes available to the next inference.

The system gets stronger the longer it runs, because the memory it has to work with is more comprehensive, more current, and more validated. Six months in, the system knows the business better than a senior new hire would after a year. Two years in, it knows the business better than anyone except the founders.

This is the part most people miss when they think of AI as a tool. A tool stays the same. A six-function system gets better at its job specifically because the architecture is designed for that.

The architecture is the asset

The interesting part of an AI system isn’t the model. The model is commoditised, replaceable, and changing every six months. The interesting part is the six-function architecture beneath it.

A business that wants AI infrastructure that will still be useful in three years invests in the architecture, not the model. The architecture is what holds the institutional memory, governs what gets externalised, catches the hallucinations, stabilises the outputs, and compounds over time. The model is a swappable component at the top of the stack.

That’s the work we do with clients. Not selecting the cleverest model, but building the six functions that turn whatever model is at the top into a system the business can rely on.