Why Every Business Needs a Digital Twin

01What a digital twin actually is

The term is usually traced to Michael Grieves, who described the concept in 2002 as part of product lifecycle management, and it entered wide use after NASA put it in its 2010 technology roadmap. The underlying practice is older than the name. When Apollo 13 lost an oxygen tank, the reason engineers in Houston could work the problem at all was that they had ground-based replicas of the spacecraft — mirrored systems they could push, break, and rehearse against while the real vehicle was 200,000 miles away and running out of air.

That is the whole idea. A digital twin is a model of a real system that is fed by live data from that system, and is therefore useful for three things you cannot do with the system itself: you can query it (what is the state of this thing right now, and how did it get here?), you can simulate against it (what happens if I change this?), and you can learn from it (what patterns does its history reveal?).

Note what a digital twin is not. It is not a diagram. It is not a CAD file, a wiki, or a process map. Those are all static representations — they describe the system as someone once understood it, and they begin decaying the moment they are saved. The defining property of a twin is the live feed. A model that no longer receives data from the thing it models is not a twin; it is a historical document.

This is not theoretical for us. Aeroxis built the anomaly-detection model inside NOAA's Earth Observation Digital Twin — a system that ingests every incoming Level-1b file from the GOES and JPSS satellite constellations and flags scene-level anomalies in production. The physical system is a fleet of satellites in orbit. The twin is the model on the ground that knows, continuously, what those satellites are seeing and when something is wrong with it. (The full case study is here.)

02From physical assets to the business itself

Satellites, jet engines, wind farms, and factory lines all got twins first, for an obvious reason: they are already instrumented. Sensors were bolted to them because the physics demanded it, so the data exhaust existed and someone eventually asked what else could be done with it.

A business is also a system — arguably a more complex one, since its components have opinions. And a business also has an operating model: how a deal actually gets closed here, what the deployment really requires, which client will escalate if you miss a Friday, why the team abandoned the obvious approach in 2023. Every functioning company runs on that model. The problem is where it lives.

It lives in people's heads, in Slack threads that scroll away, in email nobody can search across, in a wiki that was accurate for one quarter, in a folder of documents whose authors have left. This substrate has three properties that should alarm you:

• It is not queryable. The only retrieval interface is asking a colleague, which does not scale, does not work at 2am, and fails entirely when the colleague is on leave.
• It is lossy. Knowledge leaves when people leave. Most companies discover the true depth of a departing employee's undocumented knowledge in the two weeks after they are gone.
• It is inconsistent. Ten people asked the same question give six different answers, and there is no mechanism to notice, let alone reconcile.

A business digital twin is the alternative: a living, queryable model of how the company knows and operates, fed continuously by the work itself. Not a knowledge base someone is supposed to update. A model that updates because the work updates it.

What was missing until recently was the interface. Capturing organizational knowledge as structured data has been possible for decades — the reason it kept failing is that structuring it was manual labor with no immediate payoff to the person doing it, and retrieving it required knowing precisely what to search for. Large language models change both ends of that: they can read unstructured work product without a schema, and they can answer a vague question against it. The capture problem became tractable at roughly the same moment the retrieval problem did.

03How it works: capture, memory, interface

A business twin is three layers. Skip any one and you have a demo, not a system.

Capture — instrument the work

The twin's live feed is the work itself: tickets, commits, deal notes, meeting transcripts, support threads, decision records, the outputs of the tools people already use. The design constraint here is brutal and non-negotiable: capture must be a byproduct of doing the job, not an additional job. Every knowledge-management initiative in corporate history has died on this hill. If an engineer has to write a summary for the system, they will do it for three weeks and then stop, and you will be left with a graveyard that is worse than nothing because people still half-trust it.

Memory — retrieval over the substrate

Raw exhaust is not memory. The memory layer is what makes it retrievable, and in practice today that means retrieval-augmented generation (RAG) — an architecture described by Lewis et al. in 2020 that pairs a language model with a searchable corpus. Stated plainly: instead of hoping a model has memorized your company (it has not, and cannot), you retrieve the handful of documents that are actually relevant to the question being asked, hand them to the model as context, and have it answer from them. The model supplies language and reasoning. Your corpus supplies truth.

This is the piece that turns a pile of documents into company memory: a single retrieval surface across everything the company knows, that answers in the language of the question rather than the language of the archive. It should be one shared system, not one per department — a company with six disconnected memories has none, because the value is precisely in the joins that cross departmental lines.

Two honest caveats. RAG is only as good as the corpus: retrieval over stale, contradictory, or wrong documents produces confident, well-written, wrong answers. And every retrieved answer needs a citation back to its source document, so a human can check it. A memory system that cannot show its work is not a memory system; it is a rumor mill with good grammar.

Interface — agents that read and write

The third layer is how a person actually touches the twin. A search box is not enough — it puts the entire burden of knowing what to ask on the human. The interface layer is agents: software that can read the company memory, act with the company's tools, and — critically — write back what it learned.

04The Agentic Harness

Here is the proposal at the center of this paper. Every employee should have an Agentic Harness: a standard, company-issued agent environment on their desk, wired into the company memory and the company's tools, that works alongside them on their actual job.

The word harness is deliberate. It is not a chatbot in the corner of the screen, and it is not a per-team science project. A harness is standard equipment — the same rigging on every desk, so that skills, patterns, and improvements transfer between people instead of dying inside one team's clever setup. Concretely, a harness gives every employee:

• Read access to company memory, scoped to what that person is permitted to see (more on this below — it is the whole ballgame).
• Tool access — the systems they already work in: the repo, the CRM, the ticket tracker, the data warehouse, the deployment pipeline.
• A write path back into memory. This is the part everyone forgets, and it is the part that makes the twin a twin.

That write path is the mechanism that solves the capture problem. When an employee works through the harness — researching a client, debugging a deploy, drafting a proposal — the work naturally produces artifacts: what was asked, what was retrieved, what was decided, what happened. Those artifacts flow back into the memory as a byproduct. Nobody is asked to document anything for the system's benefit; the system is simply where the work happened.

The compounding is the point. Every task both consumes memory and contributes to it. The tenth person to hit a given problem retrieves the first person's answer. The onboarding engineer asks the harness why the architecture is shaped this way and gets the real answer, with the decision record attached, instead of an approximation from whoever happens to be free. The twin gets sharper every day the company operates, because operating is what feeds it.

This works only if you are clear-eyed about what each participant is good for. Agents are fast, tireless, and fundamentally untrustworthy — they will produce a fluent, plausible, wrong answer without any change in tone to warn you. Humans are slow and expensive and trustworthy — a competent one will notice that an answer smells wrong. A harness designed around that asymmetry puts agents on breadth, speed, and first drafts, and puts humans at the checkpoints where being wrong is expensive: what gets promoted into memory as authoritative, what ships to a client, what touches production. The harness should make that review cheap and mandatory, not optional and annoying.

05Why every business — and every employee — needs one

The case for the business is straightforward once the twin exists:

• Knowledge compounds instead of evaporating. Today, most of what your company learns is written on water. A twin makes learning cumulative — the default state of an organization's knowledge becomes growing rather than decaying.
• Onboarding collapses. The bottleneck for a new hire is rarely skill; it is context, and context is currently transferred by interrupting senior people. A twin transfers it on demand.
• Turnover stops being a catastrophe. You cannot prevent people from leaving. You can prevent their departure from deleting a domain.
• Answers get consistent. One retrieval surface means the same question returns the same sourced answer, whoever asks it.
• Decisions get auditable. "Why did we do it that way?" becomes a query with a citation rather than an argument between two people's recollections.

The case for every employee having a harness — rather than a central AI team, or a pilot in one department — is less obvious and more important. Three reasons.

First, the twin is only as complete as its coverage. If only engineering works through a harness, you build an engineering twin. The most valuable retrievals in a real company cross the lines: the support thread that explains the churn, the deal note that explains the architecture, the incident that explains the clause in the contract. Partial coverage does not give you a partial twin; it gives you a twin with the joins missing, which is where the value was.

Second, leverage lands where the work is. The person who knows which task is worth automating is the person doing the task, and they will never file a ticket about it. Give them a harness and they will automate it themselves, in an afternoon.

Third, a centralized AI team becomes a bottleneck the moment it succeeds. Demand outruns it immediately, and you are back to a request queue — the exact structure the technology was supposed to dissolve.

To be blunt about the cost of doing nothing: a company without a twin is not standing still. Its competitors are compounding their knowledge while it is losing its own to attrition and forgetting. The gap does not open linearly.

06Need-to-know by default

Everything above should worry you, and if it does not, read this section twice.

A company memory is, by construction, a concentration of everything sensitive the company owns — salary discussions, client contracts, security findings, unreleased strategy, the incident nobody talks about — collected into a single surface whose entire purpose is to make information easy to find. You are building the most efficient retrieval system your company has ever had, and then pointing it at your secrets. Retrieval does not distinguish between a useful answer and a damaging one.

So the permission model is not a feature to add in phase two. It is a foundational property, and the correct default is need-to-know: an employee's harness can retrieve exactly what that employee is authorized to see, and nothing else. Concretely, that means four requirements, all of which have to be true on day one.

• Identity-scoped retrieval. The retrieval query executes as the person asking it, not as a service account with a god-mode key. If Dana cannot open the document, Dana's agent cannot retrieve it, and the model never sees a token of it. This is an architectural decision made before the first document is indexed, and it is expensive to retrofit — the tempting shortcut of ingesting everything under one privileged identity is how you end up with an agent that will cheerfully summarize the acquisition memo for an intern.
• Permissions travel with the document. When a file is indexed, its access control list comes with it and is enforced at retrieval time, not at ingestion time. Otherwise an embedding becomes a permanent, un-revocable copy of a document you later restricted.
• Least privilege for the agent. An agent inherits its operator's permissions and never exceeds them. An agent that can act — write to a repo, email a client, touch production — is a principal in your security model, and must be scoped, logged, and revocable like any other principal.
• Audit as a first-class citizen. Every retrieval is logged: who asked, what was returned, what the agent did next. If you cannot reconstruct why an agent said something, you cannot investigate an incident involving it — and you will eventually have one.

There is a real tension here, and it is worth naming rather than papering over. The value of a company memory rises with what it can see; the risk rises with exactly the same variable. Anyone selling you a company memory without a serious answer on permissions is selling you a breach with a nice interface. The resolution is not to index less — it is to index broadly and retrieve narrowly, so the memory is complete but each person's view of it is exactly the view they were already entitled to.

07How to start — and how to fail fast

The failure mode we see most often is a two-year enterprise program to build The Company Twin, which delivers a beautiful architecture diagram and no working retrieval. The failure mode we see second-most-often is fifty employees each quietly pasting confidential documents into a consumer chatbot, which is the same system with none of the controls. Both come from the same root cause: treating this as a strategy exercise rather than something you build, ship, and measure.

A pragmatic sequence:

• Pick one team with a real retrieval problem — one that loses hours a week to "who knows about X?" Not the most enthusiastic team; the most afflicted one.
• Get the permission model right before the corpus is interesting. Wire identity-scoped retrieval while the stakes are low and the index is small. This is the one step you cannot defer, because it is the one step that is genuinely painful to retrofit.
• Instrument the work they already do. If capture requires new habits, the design is wrong; go back.
• Give that team the harness and measure one number. Time-to-answer, onboarding ramp, rework rate — pick something that was already hurting and that a skeptic would accept as evidence.
• Decide on evidence. If the number moves, extend the harness to the next team and let the memory's coverage grow with it. If it does not move in a quarter, find out why — bad corpus, bad capture, wrong team — and be genuinely willing to kill it. A twin that nobody queries is a liability with a maintenance cost.

08The bottom line

Every company already has a model of itself. The question is not whether to have one — it is whether that model is legible. Right now, for almost every business, it is not: it is distributed across people who will eventually leave, in threads that will scroll away, in documents nobody will open again. The company cannot query its own operating model, so it re-derives it, badly, several times a week.

A digital twin makes that model explicit, live, and retrievable. An Agentic Harness on every desk is how it stays alive, because it makes the act of doing the work the same act as feeding the twin. And need-to-know access is what makes the whole thing safe enough to actually build, because a company memory without a permission model is not an asset — it is an incident waiting for a date.

None of the three pieces works alone. Capture without retrieval is a landfill. Retrieval without a permission model is a breach. And a twin nobody works through is a document that starts dying the day it ships.

The satellites got their twin because someone instrumented them. Your company is a system too. The instrumentation is finally cheap. The only real question left is whether you build the twin deliberately, with the permissions designed in — or whether your employees build a shadow one for you, one pasted document at a time.