-3.png)
Table of contents
Most agent frameworks focus on the reasoning loop. Production agents also need isolation, scoped data access, and replay, which come from the data layer.
What does an AI agent need to run safely in production?
The fifth and final part in our series When LLMs meet enterprise data tackles a question we kept asking ourselves, half as a joke and half not. Somewhere in the middle of building LLM features into a data platform, one of us said, “Wait a second, are we building an agent framework?”
It’s a funny question, because the answer is clearly no, but also kind of yes. The gap between the two is the most interesting thing I learned along the way.
It’s no in the obvious sense. We’re not trying to compete with the agent frameworks everyone reaches for to wire up prompts, tools, and reasoning loops. That’s not our game, and the world doesn’t need another one of those from us.
But there’s also a yes. The longer we worked, the more we noticed that the popular frameworks handle the visible part of an agent – the reasoning loop – and mostly ignore what runs underneath it. That less visible part decides whether a production agent succeeds or fails.
What does an AI agent need to run safely in production?
To run safely in front of real users, an agent needs:
- Isolated states for every session, so two agents running at the same time can’t corrupt each other.
- Data access scoped to the right identity, so the agent can’t wander into data it isn’t entitled to see.
- A safe place to snapshot and replay a run, so when an answer goes wrong, you can debug it under the same conditions.
- Read and write boundaries enforced below the model, so an agent that’s been talked into something still can’t do damage.
None of these is an AI prompt engineering problem. They’re properties of the runtime and data layer underneath the model. That layer is what we call an agent harness.
A handful of things (we mostly built for other reasons) turned out to be what an agent framework needs underneath it to put an LLM near real enterprise data without it becoming a liability:
- Entity modeling
- Micro-Databases
- Token-based permissions
- Session isolation
- A clean split between design time and runtime
We never made the model more trustworthy. Instead, we built an environment where the model doesn’t need to be trusted. I think that’s the right lesson for this whole era.
Why does entity isolation make a good agent harness?
Over time, we realized that a data platform built around entity isolation makes a pretty good harness for agents.
We didn’t build session isolation for AI. We built it years ago, because organizing data by business entity, such as a customer or an order, makes performance, security, and compliance simpler.
An agent session that runs against one isolated entity gets all of that for free. There’s no shared global state for two agent sessions to fight over, and there’s no crosstalk between them. The isolation we built for data management reasons turns out to be the isolation agents need for safety reasons.
How we do it
Since K2view 8.4, every deployed data product automatically becomes an MCP (Model Context Protocol) server. Each entity instance gets its own MCP session, scoped to a single data product and a single entity ID. An agent attached to customer C-12345 sees that customer’s tables and nothing else. The session boundary is the entity boundary.
That one design choice covers most of the checklist above:
- Session isolation
Each entity instance runs in its own session against its own Micro-Database™, which holds all the data for that one entity, so no state is shared. - Scoped access
The MCP session inherits the entity’s masking and permissions. - Tools instead of raw access
Workflows tagged as MCP tools let an agent act through controlled, auditable logic, instead of running arbitrary commands.
The lesson
You can bring the reasoning loop from any framework you like. The harness underneath it is the part K2view already had.
A handful of things (we mostly built for other reasons) turned out to be what an agent framework needs underneath it to put an LLM near real enterprise data without it becoming a liability:
-
- Entity modeling
- Micro-Databases
- Token-based permissions
- Session isolation
- A clean split between design time and runtime
We never made the model more trustworthy. Instead, we built an environment where the model doesn’t need to be trusted. I think that’s the right lesson for this whole era.
Don’t ask the model to be safe.
Make the floor as safe as possible
and let the model stand on it.
If you’re building something similar and hit walls I didn’t mention here, we’d love to hear about it. The failure modes are where the real learning is.
