Context engineering is often described as giving an AI system the right information at the right time.
Denis Rothman thinks that definition stops being useful the moment an agent enters a real business.
Once an agent can retrieve private data, remember previous interactions, and take action, the question is not about whether it has enough context. It is whether it should have access to that context at all—and who will be accountable for what happens next.
For this episode of the Agentic Engineering podcast, I spoke with Denis, an AI systems architect, author and someone I’ve had the pleasure (and occasional pain :P) of editing across several books. He has spent more than four decades working with AI and enterprise systems, which means he is not especially impressed by ideas that were solved by database administrators 25 years ago and have now returned wearing an agentic label.
The context engine should not have to run the company
Denis’s central argument is that much of the work must happen before information reaches the agent.
Company data should already have an owner. Access levels should already be clear. Policies should be current, and unreliable information should be marked as such. The agent should not be expected to work out which version of reality the organisation meant to give it.
He describes a production system handling hundreds of thousands of tasks each day. The difficult work was not adding an LLM. It was mapping the approval hierarchy, cleaning the incoming data and deciding which actions were allowed to proceed.
That required months of workshops with people across the business. The AI was only one component.
If Denis’s insistence on making agent systems measurable over impressive resonates with you, he’s taking that thinking into code on October 25.
In Graph Engineering for AI Agents, he will lead 5 hands-on labs covering graph-based agent workflows, reliability, governance gates, and GraphRAG retrieval with provenance. It’s designed for engineers trying to work out whether an agent plan is safe and worth the cost.
A prompt is not a permission system
We now place an extraordinary amount of faith in instructions such as “do not reveal sensitive information” or “ask before taking action.”
But those instructions are still being interpreted by the same model we are trying to control.
Denis argues that the real limits should sit outside the prompt. The retrieval layer should refuse data the user cannot access. The system should block tasks that are not authorised. Budgets should have hard limits.
Then comes his most radical piece of agent architecture: a human being.
His preferred structure combines the agent doing the work, another agent pushing back on it and an experienced person checking what matters. Removing experts in the name of automation, he warns, often means removing the people most capable of noticing when the system is quietly wrong.
Eventually, the CFO enters the room
More controls create more cost. Denis’s answer is not to remove the controls. It is to ask whether the system still earns its place.
Track the tokens. Measure the outcome. Build a dashboard. If the agent costs more than the value it creates, stop the project.
“We’ve been living in AI Disneyland for a few years,” Denis says. “But it’s over.”
It sounds ominous—Denis hears that from me several times during the episode—but his argument is ultimately practical. The way to build ambitious AI systems is not to believe in them more. It is to give them clean data, hard boundaries and people experienced enough to say no.
Watch the full conversation for Denis’s wonderfully unsentimental take on agents, context governance and what happens when the demos finally meet the balance sheet.
That’s it for this one. We’ll pick up the conversation on Thursday.
Until then, keep building.
Tanya D’cruz
Editor-in-Chief
