Most agent frameworks focus on the reasoning loop. Production agents also need isolation, scoped data access, and replay, which come from the data layer.
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.
To run safely in front of real users, an agent needs:
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:
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.
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.
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:
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:
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.