What is a Process Intelligence Operating System?

A Process Intelligence Operating System is a software layer that models organizational work itself, not just the data about work, as a set of primitives: Actor, WorkItem, Artifact, Event, ContextSnapshot, Policy, Decision, Action, and Outcome. It sits beneath the applications an organization already runs and makes work visible, explainable, executable, and continuously improvable.

How is Fluidly different from a CRM or ERP?

A CRM stores customer records and an ERP stores transactions, but neither understands how work actually moves between people, policies, and systems. Fluidly is not another application competing with your CRM or ERP. It is an operating system layer underneath them, so every app can share one live model of work instead of each one reimplementing its own process logic.

What is a decision trace?

A decision trace is the immutable, timestamped record Fluidly writes for every consequential decision: the event that triggered it, the context and evidence considered, the policy applied, the confidence score, and the resulting outcome, linked together in one continuous, auditable sequence.

What is Fluidly's flagship use case?

Fluidly's first production use case is US outpatient medication-refill operations. A patient's SMS or voice request becomes a WorkItem, is evaluated against clinical context and safety policy, produces an AI-assisted decision with a confidence score, triggers an action, and logs an auditable outcome.

Does a human stay in control of AI decisions?

Yes. Agents in Fluidly observe state, query the digital twin, and recommend or make decisions inside policy guardrails, with human-in-the-loop review for consequential actions. Every agent action is logged with its rationale.

← All posts

August 16, 2026

Every organization runs on work. Almost none of them can see it.

CRMs store customers. ERPs store transactions. EHRs store records. None of them understand how work actually moves. That gap is where delays and risk live, and it is what Fluidly exists to fix.

Walk into any organization and ask a simple question: show me how this one piece of work moved from request to outcome. Not the record of it. The movement. Who touched it, what they decided, which policy applied, where it waited, why it went the way it did.

Nobody can answer that. Not because people are careless, but because no system is built to hold it. The CRM has the customer. The ERP has the transaction. The EHR has the record. Each tool sees its own slice and nothing else. The work that crosses between them, the part that actually determines whether a customer waits two hours or two weeks, lives in inboxes, spreadsheets, side channels, and people's heads.

This is not a software problem

The instinct is to buy another application. A better ticketing tool, a new workflow product, one more integration. But every one of those apps reimplements its own version of the process, its own rules, its own hidden logic, and then guards it. Add five apps and you have five partial models of the same work, none of which agree, none of which can explain a decision after the fact.

The missing thing is not another interface. It is a shared model of the work itself, sitting underneath the apps a team already runs. That is the bet behind Fluidly. We call it a Process Intelligence Operating System, and the name is deliberate. An operating system does not compete with your applications. It is the layer they all stand on.

Nine primitives, everything else built from them

Under the hood, Fluidly models all organizational work as a small set of durable primitives: an Actor who can act, a Work Item with a lifecycle, an Artifact as evidence, an Event that records what happened, a Context snapshot of the facts at decision time, a Policy that constrains what is allowed, a Decision with its rationale and confidence, an Action taken as a result, and an Outcome that closes the loop. Model those nine things honestly and something changes. Work stops being a rumor. It becomes visible state, explicit decisions, executable policy, and traceable outcomes.

The part I care about most is the trace. Every consequential decision leaves a permanent record of the context it saw, the evidence it weighed, the policy it applied, its confidence, and what happened next. It is closer to how git tracks code history than to how most enterprise software tracks anything. You can read back exactly why the system did what it did, months later, without asking anyone to remember.

Why we started in healthcare

Our first production use case is US outpatient medication-refill operations. A patient sends a request by text or voice. It becomes a Work Item, gets evaluated against clinical context and safety policy, produces an AI-assisted decision with a confidence score, triggers an action, and logs an auditable outcome. Every step end to end.

We chose it because it is hard in all the ways that matter. Work is fragmented across clinical and administrative systems. It is regulated, so the audit trail is not optional. And the stakes are real, so supervised autonomy with a human in the loop is the only responsible way to automate anything. If the model holds up here, it holds up in the places where coordination is merely expensive rather than dangerous.

What this blog is for

This is where we write about what we learn building it. The design decisions, the things that broke, the patterns that held up in production, and the occasional strong opinion about where enterprise software is going. If any of this is a problem you recognize, come talk to us. We are looking for the organizations that feel the invisibility of their own work most sharply, because those are the ones this was built for.