Fluency

Work Ontology

Last updated

A work ontology is a living, continuously updating graph of how an enterprise actually operates, built by observing work at the point of execution. Its nodes are the actors, activities, and artifacts of work, and its edges are the handoffs between them, with intent inferred for every action.

What Work Ontology actually means

A work ontology connects the work being done, the people and agents who do it, and what they produce into one model. It has three layers. Activities are the work itself, a reconciliation task, an onboarding process, a deep work session, captured as it happens. Actors are who is doing it, resolved to one identity across every system, so the same person in email, in Slack, and in the CRM is understood as one actor. Artifacts are what the work produces or consumes, an invoice, a contract, a case record, tracked as it moves across screens, tools, and teams. The edges between them are the handoffs. Because the model mirrors reality, it is ground truth an AI strategy can run on.

The ontology does not log what someone clicked. It infers why they were doing it, where processes are repetitive, and where they break down. That correlation to business outcomes is what separates a work ontology from process mining or task mining, which produce disconnected observations with no clear pathway to automation. It is also what lets the ontology recognize two people reaching the same outcome through different tools and in a different order as doing the same work.

Everything built on the ontology reads from it and feeds back into it, in a loop of four steps. Work is observed at the point of execution and understood by intent towards business outcomes. Patterns resolve into processes, and the ontology surfaces the golden path for each. Agents are deployed from the ontology and work along that golden path. The agent work is then seen like any other work and feeds straight back in. The map gets richer with every cycle, and everything built on it gets better.

Because the ontology updates continuously, the agents built on it are not frozen to a hardcoded workflow. At the moment an agent needs to make a decision, it traverses the live ontology and works from what is true right now. When a product changes, a field moves, or a person leaves, the agent adapts with the business rather than shattering the way brittle RPA does.

The graph also becomes the company memory of how it operates. Tacit knowledge and the hidden steps that make work function usually leave when the people who hold them do. In the ontology they are captured as the work happens, and the graph stays complete as teams change and as new work enters and old work retires. Process mining and RPA are only as current as the day they shipped. A work ontology keeps learning as the work changes.

Examples

Same work, different paths

Across a finance team, ten people reconcile invoices ten different ways, through different tools and in a different order. Because the ontology models intent rather than screens, it recognizes all ten as the same process and represents them as one workflow with its variants, instead of ten unrelated recordings.

Reading the golden path

From the distribution of how a process actually runs, the ontology surfaces the variant associated with the best outcomes on time to completion, error rate, and rework. That golden path becomes the reference way of operating, and the automations worth building first are read directly from it.

An agent that adapts instead of breaking

An agent automating a claims workflow traverses the live ontology at the moment it needs to decide, working from what is true right now. When the upstream process changes or a field moves, it adapts with the business instead of shattering the way a hardcoded rule does.

Knowledge that outlives the people

A controller who has run the intercompany close for nine years retires. The hidden steps and judgment calls that made it work were captured in the ontology as the work happened, so the process does not leave with the person who held it.

Frequently asked questions

A process map is a static picture drawn at a point in time, usually to describe how work was intended to run. A work ontology is built from observed execution and updates continuously, so it describes how work actually runs today. A process inside a work ontology is a live path through the graph, not a diagram that goes stale the moment the business changes.

Process mining reconstructs how work ran from the event logs that systems recorded, so it only sees the work those systems captured. A work ontology observes work directly at the point of execution, including the manual, cross-application, and between-systems work that never reaches a log. It also infers why an action happened rather than logging what was clicked, which is the correlation to business outcomes that makes discovery useful at enterprise scale.

Activities are the work being done, from a reconciliation task to an onboarding process to a deep work session. Actors are who is doing it, resolved to one identity across every system, so the same person in email, Slack, and the CRM is understood as one actor. Artifacts are what the work produces or consumes, such as an invoice, a contract, or a case record, tracked as it moves across screens, tools, and teams. The edges between these nodes are the handoffs, and a business process is a recurring path through them.

It is built from continuous observation rather than a one-time capture, so new work is added to the graph as it appears and paths that stop being used fade out. No one hand-writes or maintains the model. Process mining and RPA are only as current as the day they shipped; a work ontology keeps learning as the work changes.

Agents tend to fail in production when they meet cases their hardcoded logic never anticipated. An agent grounded in a work ontology traverses the live graph at the moment it needs to decide and works from what is true right now, so when a product changes, a field moves, or a person leaves, it adapts with the business rather than shattering the way brittle RPA does.

Tacit knowledge and the hidden steps that make work function usually leave when the people who hold them do. In a work ontology they are captured as the work happens, so the graph becomes the company memory of how it operates and stays complete as teams change, as new work enters, and as old work retires.

They share the word but model different things. Palantir’s ontology maps the data and entities inside an organization’s systems. Fluency’s work ontology models how work is actually executed by people across those systems, built by observing work at the point of execution rather than by integrating data sources. One describes the data, the other describes the work.

Related terms

Work Intelligence

Work intelligence is the operational layer that provides a current, evidence-based picture of how work actually moves through an enterprise. It is used to target AI deployment, verify post-deployment outcomes, and continuously update the baseline as the business changes.

Enterprise AI

Enterprise AI is AI deployed inside large organizations under three constraints absent from consumer AI: integration into existing systems of record, governance against company and regulatory policy, and verification of outcomes against a hard-dollar baseline.

Ready to deploy AI across your enterprise?

Discover how Fluency can help you continuously deploy AI.