When I look at what Google is addressing with its knowledge approach, and what AWS is now adding with Context Intelligence and Continuum, one thing is clear to me: what’s emerging here isn’t just a handful of new features. The focus of entire agent architectures is shifting. It moves away from the question of how cleverly a model answers, and toward the much less comfortable question of how reliably a system acts in real enterprise operations.

Picture the whole thing for a moment as a workshop. For a long time, we talked about AI as if what mattered most was the best tool, meaning the most powerful model, the sharpest drill, the most expensive cordless screwdriver. Then came the next wave with RAG, and suddenly it was about putting the right material into the tool’s hands: context from documents and enterprise data. After that, we started trusting the tool to decide for itself what to do next, and that was the agent wave. And it’s exactly here that it becomes obvious a well-organized workshop needs more than the best tool and a pile of material.

The bottleneck is no longer primarily in the model

In many discussions about AI agents, people still act as if the model itself were the central lever, as if everything else would simply follow once it’s powerful enough. I now consider that the wrong focus.

An agent is only as good as the context it can reason over. AWS itself now states this very clearly, and if you look honestly at enterprise reality, it’s immediately obvious why this matters so much. Enterprise knowledge doesn’t sit neatly in one place. It’s spread across data lakes, lakehouses, warehouses, operational systems, wikis, ticketing systems, emails, documents, and people’s heads. Part of it is structured, part unstructured; part current, part long outdated; part officially approved, part only informally known. And usually exactly the things that would be decisive for sound decisions are missing, namely relationships, responsibilities, validities, provenance, trust levels, and rules.

To stay with the image: you can dump an entire container full of material in front of a capable craftsman, but if he doesn’t know which board is load-bearing, which is rotten, which has already been used, and which is even approved for this purpose, then sheer quantity won’t help him. More context is not automatically better context, and unstructured context is not the same as reliable knowledge.

Why RAG mattered, and why it isn’t the end state

RAG was, and is, an important step, because it was the pragmatic answer to a real problem: models know too little about the specific enterprise context, so you give them the relevant information at runtime. That works surprisingly well in many scenarios and will remain useful. I don’t want to diminish that at all.

But RAG has limits, because it primarily delivers text fragments, meaning excerpts from documents. That can be enough for question-answering scenarios, summaries, or simple assistance. But as soon as a system is supposed to prepare decisions, understand dependencies, or even trigger actions, it often isn’t enough anymore, because that requires more than the matching passages from a document. It requires modeled context: knowledge about how things relate, who is responsible for what, which rule applies in which case, which data source is trustworthy, which approval is required, and which action is permitted, forbidden, or allowed only under certain conditions.

So the craftsman with the material container doesn’t just need more boards. He needs a blueprint, a bill of materials with properties, and a clear specification of what’s structurally permitted and what isn’t. That’s exactly why, from my perspective, it’s no coincidence that hyperscalers are now leaning more heavily on knowledge graphs, context intelligence, and policies. This isn’t a cosmetic extension of RAG. It’s the realization that productive agent systems need a robust knowledge layer.

The Knowledge Layer becomes the actual key component

I believe that over the last two years we’ve looked too much at the agent itself, at its capabilities, its autonomy, its tool use, its planning. And that’s understandable, because that’s exactly what becomes visible in demos and impresses people. In production systems, though, the real lever often lies elsewhere.

It isn’t the agent alone that becomes the platform. The Knowledge Layer, the policies, and the controlled execution become the actual platform.

For me, that’s the central observation behind the current developments at Google and AWS, because an agent can only act reliably when the workshop around it is cleanly built. That involves, first, a knowledge layer that doesn’t just provide content but makes relationships, roles, rules, and validities explicit; second, an orchestration that prepares decisions in a traceable way rather than letting them emerge randomly out of the prompt; and third, a control layer that checks whether an action is permissible, safe, and even sensible in the given context. Only when these layers work together does an impressive demo agent become a robust system.

Why hyperscalers are moving in this direction right now

For me there are several reasons why this development is becoming visible precisely now, and the first is reliability. As long as AI mainly generates answers, errors are unpleasant. But as soon as AI prepares decisions or executes actions, errors become operationally relevant, because then it’s no longer just a hallucination in a chat window, but real consequences in processes, systems, and security contexts.

The second reason is scaling, because a single agent with loose document context may work in a limited scenario, but as soon as many use cases, data sources, role models, and security requirements come together, improvised context no longer holds, and you need systematic knowledge provisioning. The third reason is governance, because in many companies rules today still exist as PDFs, guidelines, or implicit experiential knowledge, and for agentic systems that simply isn’t enough, because governance has to become machine-readable and effective at runtime: who is allowed to see what, what may an agent do, when is approval required, which actions are categorically blocked. These are no longer edge questions. They are architecture questions.

And yes, efficiency plays a role too, because structured context is often more targeted and cheaper than ever-larger amounts of unstructured prompt content. But I see that more as a welcome side effect. The actual driver, from my perspective, isn’t token optimization. It’s reliability.

From an answer system to an action system

What I find especially interesting about the AWS signals is that they aren’t only talking about better context, but also about the transition from observation to action, and that’s an important point. Many classic systems still follow a familiar pattern: collect data, store it, query it, visualize it, and then a human decides what to do. That model works, but it’s slow and heavily dependent on manual interpretation.

The new direction looks different, because data isn’t just collected but contextualized; context isn’t just displayed but made usable for inference; and decisions don’t remain mere recommendations but can transition into controlled actions. This is exactly where guardrails, safety checks, and policies become indispensable, because the closer a system gets to real action, the less it can rely on mere trust in the model, and the more it must itself ensure that decisions stay within defined boundaries. For me, that’s the real difference between an agent that appears intelligent and a production-grade agent system.

What this means concretely for companies

Many companies still treat knowledge management as a documentation topic, as a question of where information is stored, searched for, or maintained, and for agentic systems that understanding is no longer sufficient. Knowledge management is becoming an operational component of system architecture.

That’s a substantial shift, because suddenly it’s no longer just about making knowledge findable, but about structuring knowledge so that systems can work with it: relationships have to become explicit, terms consistent, responsibilities modeled, rules machine-readable, provenance and trust levels traceable. With that, metadata gains enormous importance, not as technical decoration, but as the foundation that allows agents to handle enterprise context reliably at all.

This is also exactly where I see a strong connection to classic data and analytics topics, because anyone who has spent years learning to cleanly structure data models, semantics, historization, provenance, and rule sets suddenly brings capabilities that become central to agent systems. That’s not a sideshow. That’s core architecture.

Why I consider this more than a short-term trend

You could of course dismiss this development as just the next marketing wave from the hyperscalers, and yes, as always, there will be plenty of packaging involved. Still, I believe something substantial is happening here, because when several large platform providers start, almost simultaneously, to build out the Knowledge Layer and the control mechanisms of agent systems, that’s rarely a coincidence. It’s usually a reaction to a structural problem that has become visible in real environments.

And that problem, from my point of view, is clear: model intelligence alone doesn’t scale in enterprise reality, not because the models are too weak, but because enterprise context is complex, distributed, contradictory, and rule-bound. That’s exactly why the focus is shifting now, away from the question of how intelligent an agent appears, toward the question of how reliably it works in an enterprise context. And that’s a much more mature question to ask.

My conclusion

I believe that in many places we’re still building the wrong things intelligently, because we invest a lot of energy in agents that look impressive, but too little in the systems that make them reliable. That’s exactly what the hyperscalers are correcting right now.

The next level of maturity for AI agents doesn’t emerge primarily in the model, but in the interplay of a structured knowledge layer, clear policies, controlled execution, and traceable decision logic. Or, put even more directly: it isn’t the agent alone that becomes the actual product. The Knowledge Layer and the guardrails do.

For companies, that’s an important message, because anyone who seriously wants to deploy agentic systems in production shouldn’t only talk about models, prompts, and tools, but about knowledge structures, metadata, governance, and runtime control, because that’s exactly where it’s decided whether AI becomes a nice assistant or a reliable system.