What is operating intelligence?

Operating intelligence is our term for the work of making an organisation understandable while it is operating.

That means knowing what work is active, what has changed, what is blocked, what evidence supports the current position, which commitments have been made, and where human judgment is needed next. It is not just reporting. It is not just automation. It is the live context that lets people, systems, and eventually agents understand the state of work well enough to act responsibly.

This matters because most organisations already have a lot of software, but the organisation itself is still hard to read. Important context is spread across documents, inboxes, calendars, meetings, finance tools, task boards, case systems, spreadsheets, and people's memory. Each system may hold a useful record, but the operating state of the organisation lives between those records.

Operating Intelligence As A Working Definition

Operating intelligence is the current, structured understanding of how work moves through an organisation.

It is related to operational intelligence, a term used in IT, manufacturing, logistics, security, and service operations to describe real-time visibility into events, systems, and performance. The older real-time business intelligence literature makes a similar move: Azvine, Cui, Nauck, and Majeed^{7B. Azvine et al., Real Time Business Intelligence for the Adaptive Enterprise} described real-time BI as analysing information about business operations as events occur.

Our use is narrower and more practice-oriented. In professional and knowledge work, the most important operational signals are often not machine events. They are commitments, exceptions, approvals, evidence, handovers, deadlines, relationships, and decisions.

A client commitment made in a meeting is operational data. So is a missing document in a matter file, an unresolved approval, a vendor renewal linked to a budget decision, a case note that changes a follow-up plan, or a project status that depends on judgment rather than a narrow task state.

Operating intelligence is the layer that turns those signals into a usable model of reality. It connects records of work to action on work.

From records to an operating model

Most organisational software is good at storing records. CRMs store accounts and contacts. Document systems store files. Finance systems store transactions. Project tools store tasks. Case systems store matters. Calendars store commitments.

But a record is not the same as an operating model.

An operating model explains how those records relate to each other. It says which matter a document belongs to, which decision it supports, who owns the next step, which approval boundary applies, what changed since the last review, and which actions can be prepared safely.

This is why operating intelligence is different from adding another dashboard. A dashboard summarises information. Operating intelligence maintains context. It is concerned with the relationships between work, evidence, people, cadence, resources, and boundaries.

IBM describes business intelligence as processes for collecting, managing, and analysing organisational data to inform strategies and operations. That remains useful. Business intelligence often explains what happened and how performance is trending. Operating intelligence is more concerned with what is true now and what needs attention next.

Digital Twins As The Practical Structure

We believe the practical way to achieve operating intelligence is through digital twins.

A digital twin is a living model of something real. IBM defines a digital twin as a virtual representation of a physical object or system that uses real-time data to reflect its counterpart's behaviour, performance, and condition. The important point is not that the model is digital. The important point is that the model stays connected to changing reality.

Historically, the pattern comes from engineering and aerospace. IBM traces the practical lineage to NASA's 1960s spacecraft replicas and the Apollo 13 rescue effort, then to Michael Grieves' 2002 product lifecycle management framework and John Vickers' use of the term "digital twin" in a 2010 NASA roadmap. Grieves and Vickers later described the digital twin as a way to mitigate unpredictable behaviour in complex systems by linking physical products, virtual products, and the data connections between them. The concept began as a way to reason about complex systems when direct experimentation was risky, slow, or impossible.

The same pattern applies to organisations. A professional practice, client portfolio, care pathway, finance operation, project environment, or legal matter is also a complex system. It has state. It changes over time. It depends on evidence, people, tools, commitments, and constraints.

For professional work, the twin is not a 3D model. It is a structured model of the operating area.

It can include:

• Work: matters, projects, cases, clients, tasks, deliverables, and deadlines.
• Evidence: documents, notes, decisions, approvals, source material, and audit trails.
• People: owners, reviewers, clients, partners, vendors, and handover points.
• Cadence: weekly reviews, monthly reporting, renewal cycles, escalation paths, and recurring commitments.
• Resources: tools, subscriptions, budgets, vendors, access, and spend.
• Boundaries: permissions, data rules, approval requirements, and human-in-the-loop controls.

The distinction between a digital model, digital shadow, and digital twin is useful here. Kritzinger, Karner, Traar, Henjes, and Sihn's 2018 manufacturing review classifies them by data integration: a digital model is manually updated, a digital shadow receives automated data from the physical system, and a digital twin has a more reciprocal flow between the physical and digital sides. A 2022 review by Thelen and co-authors makes a related distinction between physical-to-virtual and virtual-to-physical data flows.

For operating intelligence, this progression matters. A static map of the organisation is helpful, but limited. A shadow that receives live data is better. A twin becomes more useful when the model can support reviewed action back into the organisation.

Organisational Legibility For Agents

The strongest reason to build operating intelligence now is AI.

Large language models and agents are becoming more capable, but capability is not the same as organisational usefulness. An agent cannot reliably help with work it cannot understand. It needs access to the current state of the organisation: the work, evidence, permissions, owners, definitions, tools, and review boundaries that make an action appropriate.

In human organisations, much of this context is implicit. People know where to look, who to ask, which document is authoritative, what tone is acceptable, and when a decision needs approval. Agents do not inherit that tacit knowledge automatically. The organisation has to become legible to them.

That legibility requires a pipeline: ingestion, processing, storage, then retrieval and tools. Each stage has a different role in turning scattered operational material into usable state.

Ingestion

Ingestion is the intake layer. It brings operational material into the system through APIs, webhooks, file imports, database syncs, email and calendar connectors, meeting transcripts, forms, manual updates, and batch uploads.

The point is not to collect everything indiscriminately. Important commitments, decisions, evidence, and status changes need to enter from the places where work happens: documents, emails, calendars, meetings, finance tools, case systems, task boards, and databases.

Processing

Processing is the interpretation layer. It turns raw intake into structured operating information by parsing content, extracting fields, resolving identities, matching records, applying permissions, detecting duplicates, and linking related objects.

Raw records have to be cleaned, structured, deduplicated, permissioned, linked, and normalised into stable concepts: matter, client, owner, approval, source, deadline, renewal, risk, task, review, and outcome.

Storage

Storage is the system of record for the processed operating state. It keeps the organisation's current state durable, queryable, permissioned, and auditable so people and agents can return to the same facts over time.

That may include relational databases, search indexes, document stores, knowledge graphs, vector stores, audit logs, and operational records.

Retrieval and tools

Retrieval and tools are the action layer. Retrieval lets people and agents find the right context; tools let them create, update, route, approve, or review work through controlled interfaces.

That can include search, retrieval APIs, editors, queues, review surfaces, workflow controls, and controlled write paths. Without tools, AI remains a text interface. With tools, it can participate in the operating system of the organisation.

Operating intelligence is the infrastructure that makes this possible. It makes the organisation legible not only to humans, but to software that can read, search, reason, prepare, and act within defined limits.

Why Saas and automation are not enough

Saas gives teams applications. Automation moves work through predefined steps. Operating intelligence maintains the context needed to understand work across applications and decide what should happen next.

Traditional Saas is usually built around a category: CRM, project management, document management, finance, HR, case management, analytics, support, or procurement. Those categories are useful, but real work often crosses them.

A client commitment might start in a meeting, continue in email, rely on a document, affect a budget, require a review, and create follow-up work in another system. No single Saas category owns that full chain.

Automation has a different limitation. IBM describes workflow automation as replacing manual tasks with software that executes all or part of a process. That is useful when the process is stable and the decision is obvious: send a reminder, copy a file, create a ticket, update a status, or route an approval.

But professional work often contains ambiguity. The hard part is not triggering an action. The hard part is knowing whether the action is appropriate.

Operating intelligence gives automation context, limits, and review points. It helps a system know when to act, when to prepare a recommendation, and when to stop for human judgment.

What this looks like in practice

Legal practice

Operating intelligence might connect matters, evidence gaps, client commitments, drafting state, partner review, filing dates, and approval boundaries. An agent can then prepare a client update or matter summary with source context, rather than generating from a prompt alone.

Finance-led teams

It might connect subscriptions, vendors, budgets, owners, usage, renewal dates, and approval history. An agent can identify a renewal risk or prepare a spend review because the resource is tied to the work it supports.

Care organisations

It might connect follow-up cadence, sensitive client context, practitioner notes, handover state, and governance boundaries. An agent can help prepare review material without treating sensitive action as automatically approved.

Built environment work

It might connect project status, site evidence, drawings, client decisions, contractor follow-ups, risk items, and approval flows. An agent can search the relevant record, prepare a next-step brief, and route it for review.

Across these examples, the pattern is the same: the organisation becomes more legible, and therefore more supportable with AI.

The Argument For Operating Intelligence

The case for operating intelligence is not that every organisation needs a more complex system. Some teams are small, stable, or contained enough that existing Saas tools and lightweight reporting are sufficient.

The case is that complex work now needs a more explicit operating layer. As AI and agents become part of work, implicit human context becomes a bottleneck. If the organisation is not legible to software, agents will either remain superficial or act without enough grounding.

Operating intelligence is a way to make that grounding real. Digital twins provide the structure. Ingestion, processing, storage, retrieval, and controlled interaction tools provide the mechanics. Human review and approval boundaries provide the governance.

The outcome is not automation for its own sake. It is a more understandable organisation: one where people and agents can see what is happening, understand what matters, and act with the right context.

Sources

1. IBM: What is a digital twin?
2. IBM: What is business intelligence?
3. IBM: What is workflow automation?
4. Michael Grieves and John Vickers, Digital Twin: Mitigating Unpredictable, Undesirable Emergent Behavior in Complex Systems
5. Werner Kritzinger et al., Digital Twin in manufacturing: A categorical literature review and classification
6. Adam Thelen et al., A Comprehensive Review of Digital Twin, Part 1
7. B. Azvine et al., Real Time Business Intelligence for the Adaptive Enterprise