An Agent Can't Act on What It Can't Name

Ask an agent "which of our servers are at risk?" and watch what it has to do.

It has to figure out what "our servers" means, across an inventory, a cloud console, and a spreadsheet somebody maintains. It has to decide whether the host called web-03 in one system is the same machine as web03.prod in another. It has to guess which source is authoritative when they disagree. Then, having improvised all of that, it answers with total confidence.

That's where agent inaccuracy actually comes from. Not from the model reasoning badly — from the model being handed a vague world and asked to make it precise on the fly, differently every time. You can't prompt your way out of it. A better instruction doesn't tell the model which of two records is the real host.

And identity is the easy half. Everyone already knows a model can't tell which web-03 you meant.

The harder half is that pointing at a thing means pointing at everything attached to it. Ask whether this server is at risk and you are not asking about a row. You are asking about the service running on it, the database it talks to, the load balancer in front of it, the team on call for it, and the three systems that go down with it. Name an asset and you have named its children, its dependencies, and whatever sits downstream — or you have named almost nothing.

That's why the definition is never just entities and properties. It's entities, properties, and links. The links are where the real question lives: not what is this thing, but what does this thing drag with it.

What an ontology actually buys you

Strip away the philosophy-department associations and an ontology, in the enterprise sense, is simple: a declared set of entities, their properties, and the links between them, mapped onto whatever scattered systems actually hold the data.

Not f_name in table fourteen. A Customer, with a first name. Not "the endpoint data." A Host, with an owner, running a Package, with a known Vulnerability, linked to an open Ticket.

Three things change the moment that exists:

Resolution happens once, not per request. Deduping, linking, deciding which source wins — that gets done deliberately, by people who know the domain, and every agent inherits it. Otherwise each run re-derives it, and re-derives it differently.

The agent's vocabulary matches the business's. The model reasons in the same nouns your operators use, so its output is checkable by a human who never sees the schema.

Scope becomes expressible. "Every service that depends on this host" or "all open orders linked to a shipment that missed its SLA" is a traversal — a walk along declared links, not a fishing expedition across a data lake.

That's the precision argument, and it's really a data engineering argument wearing an AI hat. The substrate does the work that the prompt was never able to do. It's the same conclusion we reached coming at it from the knowledge side: what's true belongs in an engineered layer, not in prose.

How a very big system does it

The reference implementation is Palantir's Foundry Ontology, and it's worth looking at because they arrived here a decade before LLMs — they had to fuse dozens of source systems for humans first.

Their framing is unusually honest about the goal. From their platform documentation:

The Ontology is designed to represent the decisions in an enterprise, not simply the data.

So it has two halves. The first is the nouns — the parts that "describe your organization: the entities, their properties, and the relationships between them," built by "mapping existing datasources into objects, properties, and links."

The second half is the one most people skip, and it's the important one for agents: the verbs. Palantir calls these the kinetic elements — "the governed operations people and systems perform on those entities," expressed as action types and functions, explicitly framed as "enabling change while complying with organizational controls and governance."

That is not a bag of API calls. It's a set of named, typed, permissioned operations with preconditions and side effects that write back to the systems of record. The guardrail is attached to the action, not to a paragraph of please-be-careful in a system prompt. And it extends to agents on the same terms as people: in AIP, "every operation made by humans and agents abides by rigorous role-, marking-, and purpose-based controls."

Two things are true about this at once. It is right — entities before agents, governed verbs before autonomy. And it is something most companies buy, at enterprise scale, with a modeling team and a services engagement attached. The idea is portable. The delivery model isn't.

(One note on sourcing: the quotes above are Palantir's own. The tidy "semantic / kinetic / dynamic layer" framing you'll see in explainers around the web is largely the ecosystem's re-telling — in Palantir's docs "dynamic" appears as a security qualifier, and the what-if capability is called Scenarios. Worth knowing before you repeat the diagram.)

How we implement the same idea

The difference isn't the shape. It's what the layer is made of — and when the arrangement happens.

Palantir's ontology is modeled: datasources get mapped into objects ahead of time, and the object layer exists whether or not anyone is asking. That's exactly what makes it reusable across an enterprise. It's also what makes it a project.

In FloMorphic, the substrate is the flow. A Plugin node is a live external process holding a real connection to a real system — the asset inventory, the cloud API, the ticket queue, the database of record — and a query-node is a node that is a read. So the entities aren't looked up in a snapshot somebody synced last night. They are arranged in real time, out of the systems that actually hold them, at the moment a decision needs them. The graph is the ontology, assembled live.

That matters most for the links. Properties age slowly; dependencies age fast — what talks to what, what sits behind which load balancer, who owns this service since the reorg. A nightly snapshot of the dependency graph is wrong by lunchtime, and an agent reasoning off it will be confidently wrong about blast radius. Arranged at decision time, through a plugin holding a live connection, it isn't.

That's the part worth being precise about, because it's easy to hear "flow" and think only of control. A flow is not just the path an agent walks after the data is in order.

The flow is what puts the data in order.

Two things follow from that.

What should persist, does. Not everything can be fetched per request — resolution rules, embeddings, accumulated history. Ingest, clean, extract, resolve, embed, tag, keep current: that's the organization brain, and it is itself a durable, long-running flow — a graph running on a schedule and on every event, surviving crashes, built from the same primitive that later runs on top of it. Live arrangement and standing memory are the same material, drawn twice.

The agent browses neither one. The "which sources do I consult" decision is drawn on a canvas before anything runs, instead of being improvised mid-conversation. What reaches the model is a scoped context, not a world to wander.

The verbs are nodes too. A plugin holds the connections and not the credentials — a sense declares what a connection needs, the platform stores the secrets and folds them into each call. An Extrinsic node calls your own backend. A Contract node is the decision primitive: its output selects which outgoing edges fire. Where an agent on an ontology picks a governed action out of a catalogue at runtime, here an action is a node with an edge coming into it. Permissions bound what the reasoning can reach; only a drawn path bounds where it can go.

The honest trade: a modeled ontology gives enterprise-wide reuse by construction, and we take freshness instead — arranged per frame, composed out of shared plugins and query-nodes rather than inherited from one global model.

An ontology declares what things are. A flow is the substrate that arranges them — live, through plugins into the systems that hold them — and then decides what happens next.

Where we're proving it

Venapce, the security governance segment of Inflowenger, is built this way end to end: every piece of its business logic is defined in FloMorphic workflows rather than compiled into the product. It gets its own write-up, so I'll leave it at the single property that matters here — because that property is what makes software progressive, with AI-native actions.

Progressive, because behavior is authored rather than compiled. A domain expert can extend a shipped, running product without a rebuild and without a deploy window, so it keeps getting more capable after it ships instead of slowly decaying. AI-native, because the model isn't a chat box bolted to the side — it's a node in the same graph as the queries, the checks, and the writes, with judgment applied exactly where it was drawn and nowhere else.

An agent's accuracy is decided before the agent runs — by whether anyone did the work of saying what things are. Palantir proved that at a scale most companies can't afford. The idea doesn't need that scale. It needs a substrate you can author, verbs you can govern, and a path you can read.