Agents built on your data platform inherit something powerful and dangerous: the platform’s authority. When a Databricks Supervisor Agent answers a question, the answer arrives wrapped in the trust you’ve spent years building in your lakehouse. The SQL ran. The numbers came from governed tables. So nobody double-checks.
That’s the problem. A data agent can run the right query against the right table and still hand someone the wrong answer, because it misread a qualifier three turns ago and every follow-up built on it. Here’s where conversational and agentic apps on Agent Bricks break in practice, and how Turn3 finds the turn that broke before your users act on it.
Data-platform agents fail differently
On a data platform, an agent’s behavior isn’t defined by code alone. It’s defined by a stack of things that change without a deploy: the semantic model that maps business terms to columns, the retrieval index over your documents, the routing instructions that decide which specialist gets the question, and the model underneath.
Any of them can shift on a Tuesday afternoon and nobody files a ticket. Nothing throws an error. The agent just starts answering slightly differently.
Databricks Agent Bricks: when the supervisor picks the wrong specialist
The Supervisor Agent in Agent Bricks routes each request by intent to specialized agents, including Genie Agents for structured data, Knowledge Assistants for documents, Unity Catalog functions, and MCP servers. It’s a smart design, and it creates a specific failure shape: a routing or context decision made early that every later turn quietly inherits.
Where sessions break:
- Misrouting. A question about policy terms goes to the structured-data specialist, which returns a confident number instead of a document-grounded answer.
- Context lost in handoffs. The user’s filter (“EMEA only,” “excluding returns”) is set at turn 2 and doesn’t survive a handoff to a different sub-agent at turn 5.
- Blended answers. The supervisor merges a Genie result and a Knowledge Assistant passage that disagree, then presents a smooth summary that hides the conflict.
Turn3 pulls the governed telemetry your Agent Bricks workloads already produce, with no exporter changes. It rebuilds the full multi-agent session, including turns, tool calls, and sub-agent hops, and names the turn where the routing or context went wrong.
What this looks like in one session
Take a conversational analytics assistant on either platform. This is an illustrative composite:
→ Turn 2: User asks for Q3 revenue in EMEA, net of returns.
→ Turn 3: The agent resolves “revenue” to the default gross metric and drops “net of returns.” This is the breaking turn.
→ Turns 4–7: Follow-ups (“break it out by country,” “compare to Q2”) each return valid SQL and fluent answers, all built on the gross number.
→ Turn 8: The user pastes the figure into a board deck.
Every query executed. Every response was well-formed. The session failed.
Turn3 flags the goal as not met and points at turn 3, not turn 8. It groups this session with every other one where a “net of” qualifier got dropped, so you see one tracked issue instead of a pile of one-off complaints. Once you fix the semantic model, the failure becomes an eval. If a later model or semantic-layer change brings the bug back, Turn3 marks it regressed.
How the loop closes on your platform
- See the session.
- Judge the outcome.
- Cluster failures.
- Stop the regression.
Then Turnguard, Turn3’s inline guardrail layer (Enterprise), applies the same session understanding in the live request path. It evaluates responses in under 200ms at p99 and catches what single-response checks can’t, like an answer that contradicts the “net of returns” constraint the user set earlier, or a draft that exposes PII.
Policies are written in CEL (allow, block, rewrite, or flag), and it fails open by default.
Somewhere in your agent traffic, it’s already turn 3.
👉 Start free at klimber.io or write to turn3@klimber.io. If your agents touch customers and money, ask about Turnguard.