The map your AI needs is already inside your systems.

Every enterprise is trying to put AI to work. Most of these projects quietly hit the same wall: the AI doesn't actually understand how your business runs.

To act inside your company, an AI needs a map of how the place actually works: your systems, the data in them, the actions they allow, and the rules around each one.

That map is what people now call an ontology, and everyone is suddenly selling one. Palantir put the word on every enterprise roadmap. The Big 4 are running workshops. So are Microsoft and Google.

They're right that it matters. But the way it's being built is backwards.

Most enterprises build it the slow way. They pull architects, data teams, and subject-matter experts into a room.

Then they spend weeks, sometimes months, asking those people to reconstruct how the company works from memory and stale process maps.

I sat through plenty of these at Bain. The map was usually stale before the workshop even finished.

Here's the part everyone misses: most of that map already lives inside your own software. You're paying people to redraw from memory what your systems already encode.

The workshop map is stale before the workshop ends

The trouble starts with a gap the models don't advertise. A frontier model shows up fluent in how businesses work in general, and blank on how yours works in particular.

For example, take an invoice. The model knows what an invoice is, but not whether the authoritative version in your company lives in SAP, NetSuite, the billing platform, or a spreadsheet the finance team keeps.

Same with "customer." It knows the word, but not whether that means the CRM account, the legal contracting entity, the billing account, or the person actually using the product.

Without a shared map, every agent fills that gap in for itself. Three agents can each sound intelligent while acting on three different definitions of "customer."

That's fine when AI is answering a low-stakes question. It gets dangerous the moment AI takes action. Even McKinsey is saying it now: without a shared definition of what your data means, every agent acts on its own version, and the errors pile up as you scale.

But the map a workshop produces can't carry that weight. You're asking a handful of people to squeeze thousands of applications, fields, relationships, rules, and permissions into a set of diagrams, from memory.

It's incomplete the moment it's done. People describe the processes they know and the fields they use, and leave out the edge cases, the obscure capabilities, and the endpoints nobody on the call happens to touch.

And it's stale on arrival. The diagram captures what someone believed the architecture looked like the day they drew it, and the software has changed since.

One 2025 architecture survey caught this: keeping documentation current was the respondents' biggest challenge, and 19% reported no single source of architectural truth at all.

The people aren't the problem. The method is: you start with an abstraction of an incomplete recollection, then act surprised when the AI doesn't understand the business.

The action surface is already in the software

Every application already encodes what it can do. It's in the APIs and schemas, but also in the private endpoints, UI-only actions, and permissions that never made it into a doc.

Getting at the undocumented parts is work, but it's discoverable work, because the system is running on it right now.

The software doesn't forget an endpoint because nobody used it in the workshop, or leave out a field an architect never knew existed. It isn't a memory of the enterprise that drifts out of date. It's the enterprise itself.

Your CRM says one person owns the account. Your billing system says another.

Discovery catches that. It reads both systems and sees they don't match.

A workshop doesn't. Someone says "go with billing," the room agrees, and the meeting moves on. The systems still disagree, and nobody looked.

Discovery has a blind spot of its own. It shows you what a system can do, not what a field means, which copy is authoritative, or why a control exists.

It can't pick the real source of truth for you. What it can do is put every system that claims the customer in front of you, so a person makes that call.

That call is quick, because discovery already did the digging. Your experts sign off on which system wins, instead of spending a month reconstructing the map by hand.

Your software estate is the executable record of what the enterprise can do. Start there, then bring people to the parts it can't answer.

Discovery shows you what the business could actually do

Here's what changes once you discover the map instead of drawing it.

A workshop only shows how the business runs today. Discover it from the software and you also get everything it could do, including capabilities nobody has even turned on yet.

That's the part I actually care about. It can ask the questions nobody has time to:

• Why do employees pull from twelve systems when one already has the answer?
• Why is an approval manual when the policy and evidence could be checked automatically?
• Why does a workflow stop at a recommendation when the system exposes the action that would finish it?

At that point the map isn't just documentation. It's the start of a redesign.

Take a blocked supplier payment. It looks like a finance task.

But doing it properly means finding the invoice in the ERP, matching it to a purchase order, checking the contract terms, and confirming the goods were received. Then finding the approver, releasing the payment, and confirming the payment system accepted it.

That work spans the ERP, procurement, contract, identity, and payment systems.

A data catalog tells the AI where the invoice table lives. The executable map shows it the systems, actions, and identities the job actually touches.

Set the approval policy once, and the AI can run the job to the point of action. It pauses for a person on the calls that carry real consequence.

And you get there fast. The workshop way, you're mapping for weeks or months before anyone can test a single thing. Discover it instead and you've got a rough map in days. Your experts can argue with it, fix it, and build on it, so the real work starts almost immediately.

Discover it first, then put your experts on judgment

The better sequence is almost the reverse of the workshop:

• Deploy agents to discover each system: its objects, actions, permissions, and interfaces.
• Connect identities, objects, and actions across the estate, letting AI propose the mappings and people resolve the ambiguous ones.
• Show what becomes possible across systems, and test real workflows against the map.
• Ask the experts to add what the software can't: policy, edge cases, risk tolerances, governance, and ambition.
• Keep it current agentically, as the software changes.

Microsoft already lets you generate an ontology from an existing Power BI model instead of hand-building every entity. That's a step in the right direction. An operating ontology has to go further and discover the live action surface of the applications themselves: what they can actually do, not just the data they hold.

None of this sidelines your people. It aims them at the work that actually needs judgment.

An operator shouldn't spend hours reciting every screen and field, because the software reveals that directly. An architect shouldn't reconstruct hundreds of integrations from old diagrams, because the interfaces can be discovered.

Hand people the discovered map instead of a blank page, and the questions change: what are we missing, which company policies change this, where does this need governance, which identity mappings are ambiguous, and what should we do differently now.

Your experts stop being transcription machines and become reviewers and strategists, which is the job you hired them for.

The map has to stay alive

Software changes constantly. APIs get added, fields get renamed, permissions evolve, systems get replaced. A static ontology rots exactly like a static architecture diagram.

So discovery has to be continuous: re-run it, detect what changed, find every workflow that depends on it, propose and test a repair, ship the confident changes, and escalate the uncertain ones.

A map that has to be hand-repaired every time the software moves goes stale the same way the old diagrams did.

Monarch discovers your operating map from the software

This is the premise behind Monarch. We don't ask an enterprise to explain its whole software estate to us.

We deploy agents to discover the same surface for each application: its objects, actions, relationships, states, and permissions. We turn it into a Product Graph, a map of what can be understood and executed across the estate.

Applications get discovered in parallel, not one long project at a time.

From there, Monarch connects systems and tests workflows against the graph. Our forward-deployed engineers and your experts add what the software can't define on its own: policy, edge cases, identity corrections, governance, and objectives.

Once a workflow is tested, its known paths run as deterministic code, with inference kept only where judgment is actually required.

As applications change, Monarch is built to re-run discovery, find the affected workflows, propose repairs, and escalate the ambiguous ones, so the map keeps up with the software instead of falling behind it.

Stop asking employees to remember the enterprise. Stop treating stale diagrams as ground truth. Discover it from the systems that run it, connect them into an executable map, and use your people to sharpen it and decide what the business should do next.

The goal was never to document the enterprise better. It's to make it something AI can actually operate.

Maybe you think workshops are still the right place to start. I'd love to hear why.