Three Layers, One Product: "Your Enterprise Needs a Knowledge Graph" Is Not an AI Strategy

Most enterprise AI proposals end the moment they say, "The enterprise needs a knowledge graph — a knowledge base, an ontology." None of that is wrong. But it's a concept, and a narrow slice of the requirement at that. The client nods and then asks the only question that matters: So what? How does this actually work in my business?

I've been reworking my own proposal lately, and the more I think about it, the clearer it is that this has to be understood in three layers. Our company is still sitting on the first one. What determines whether any of this is worth anything are the two layers underneath.

Layer One: The Concept — Right, but Far Too Shallow

The first layer goes like this: if an enterprise wants AI-driven business decisions, it first needs a knowledge graph, a knowledge base, an ontology.

True. A company's business logic, customer relationships, product structure, and project history already form a web; they are not a pile of unrelated tables. Skip that web, and the AI only gets fragments.

The problem is that this layer answers "what do we need" and never "how do we use it." It has become an industry slogan you see online every day. If the proposal stops here, we're selling a concept, not something we can deliver. No client has a reason to pay for a sentence that happens to be correct.

Layer Two: The Application Layer — Turning Business Logic into Knowledge You Can Judge With

The second layer translates the concept into IT application design: abstract the vague requirement and answer how the enterprise actually applies it.

The first job is to extract the company's own business logic and turn it into knowledge with relationships. This isn't dumping documents into a store and calling it done — it means working out what connects to what. An order, for instance: which customer, which product line, which delivery stage does it touch? A delay: which preconditions does it trace back to? Without those relationships, there is nothing to base a judgment on.

The second job is the human-AI interface. Input needs its own application: people have to be able to enter business information, edit it, and validate it. Output needs one too: show the extracted and judged results to a person, who confirms or corrects them. You can't skip this loop. Enterprise data is often dirty and inconsistently defined; go fully automatic on day one and you simply amplify the errors.

But if all we do is manual entry and manual judgment, the whole thing is pointless. People already do that. The value of AI is to judge as automatically as possible.

That calls for a new concept: AI judgment. Judgment can't be guesswork; it needs grounds. My current thinking is to build a judgment framework for the enterprise. A company's operations are cyclical and can be divided into five cycles. Each cycle calls for six capabilities, and each capability maps to a set of judgment factors. When a problem appears, place it in a coordinate system — the company's own data, plus which cycle it is in, plus which capability is involved — and combine that with the judgment factors to reach a conclusion.

Whether that framework holds up has to be validated together with the client. But one thing is certain: the data behind it matters enormously. Either you prepare it in advance or you accumulate it as you work with the company. Without it, AI judgment is just the model's generalized guess, never grounded in that company's actual situation.

And judgment isn't the end. Once you've judged that something is wrong, you have to act. That's where the tool layer comes in.

The tool layer solves a concrete problem: how does the AI actually operate the systems a company already has? There are two directions. One is converting existing IT assets and software into tools the AI can call. The other is designing new IT systems from the start on the assumption that AI will call them. Then there are the unglamorous realities — login, permissions. Before an AI can touch a system, it has to be able to get in.

I lean toward putting a layer in between, which I call modernization. The approach: leave the old system alone, don't change its business logic. Use its own code and database to extract the relationships, then wrap it in a service that can be accessed over MCP. The AI learns what the service does from the MCP description and decides when to use it through a skill. The MCP or skill then carries API calls that invoke the old system's existing functions, or query its database directly, and return the result.

In plain terms, you put a shell around the legacy system that lets it talk to AI. That shell grafts the old system onto the brain above and turns it into something the brain can execute. This is the core work of layer two: design the architecture, and actually build it. It cannot stop at a diagram.

Layer Three: The Cloud Infrastructure Layer — Intelligence Has to Come With Execution

The third layer is the underlying system architecture. Once you're operating at enterprise scale, you can't avoid the cloud. Without it, none of this runs.

This layer answers very concrete questions. Which cloud services do we connect to? Which service, from which provider, for which job? How should the overall architecture be designed?

Start by separating application scenarios. Some are interactive: they need a UI and a person in the loop. Others run autonomously in the background and return a result. The compute and scheduling requirements for those two are completely different.

Then data: how input enters, how it is transformed, where it is stored, how the layer above calls it. Google or somewhere else, or a direct connection to the tools — all of that gets decided in the architecture.

One more point that's easy to overlook: a system doesn't become valuable just by being smart. Intelligence has to be paired with execution. And execution needs a driver — a set of cloud applications that run tasks, invoke tools, and handle failure and retry. If that part of the architecture isn't designed, the judgments from the two layers above stay beautiful and useless.

It's Only a Product When All Three Layers Connect

Put the three layers together and the logic is straightforward. Layer one defines what knowledge looks like. Layer two makes that knowledge judgeable and executable. Layer three guarantees that judgment and execution actually run.

Stop at layer one and you're just spinning concepts. The internet is full of concepts; anyone can talk for five minutes. Clients hear enough of it and conclude you're all talk. Without implementation, trust drains away.

With all three layers connected, what we hand over is a real product — and the proposal has something behind it.

That's also why layer two can't stall. It's the stretch that turns "the right words" into "something that works," and it's the hardest and most frequently skipped stretch of all.