Your Agent Isn't Broken. Your Data Layer Is.

An engineer stares at a dashboard during an incident. Thirty browser tabs, four time formats, logs scrolling in one pane while metrics spike in another. They mentally filter the noise, correlate timestamps across tools, and compress hours of signal into a decision in minutes. They do this instinctively. Now hand that same surface area to an agent.

Andre Elizondo makes this gap the centerpiece of Making Data Agent Ready—and his argument is that the fix lives upstream of the model. Useful agents start before the prompt, in the transformations, tool design, and control loops that make production context safe for a model to act on.

That framing stopped me. Every enterprise AI deployment I have been close to hits some version of this wall. Teams invest in model capability, tool access, orchestration frameworks—then discover the bottleneck was always the data layer. The interfaces built for human operators actively mislead automated systems. Humans compensate for messy context. Agents mostly don't.

The Missing Layer

What does "agent-ready" actually mean in practice?

Elizondo draws a hard line: it is not a post-processing step. It is a design commitment that sits between raw observability data and the agent's context window. Normalize the formats. Strip the noise. Pre-join what the agent would otherwise have to correlate across five tools. Build that as infrastructure, not as prompt hacks.

It's not just about ingesting that data, transforming that data, but it's really about making it agent ready. - Andre Elizondo, Mezmo

That sounds obvious in retrospect (usually after something breaks). But most teams skip it. They expose existing APIs, wrap them in an MCP server or a function-calling layer, and assume the model will figure out the rest. Mezmo's claim is that this missing transformation layer—not model choice—is where most agent projects silently fail.

The Token Tax

Elizondo's best analogy is also the simplest.

If you wanted to buy a protein shake or an energy drink and every single time you wanted a single one you go to Costco and you get a pallet. - Andre Elizondo, Mezmo

That's what a lot of generic agent tooling feels like right now. Expose a broad MCP server, return a warehouse of JSON, then act surprised when token cost spikes and the agent still misses the point.

He is not arguing that MCP is useless—it solves connectivity. But connectivity is not curation. MCP gives you a pipe; it says nothing about what should flow through it or how much. The transformation layer—filtering, pre-joining, reshaping for the decision at hand—still has to live somewhere, and most teams leave that gap empty. At Tier, constraints on edge systems forced us to ship only what the client could actually use. Same principle: agent tools are closer to agent UIs than API wrappers. Design for the decision, not for backend completeness.

Time Is Data Too

This one caught me off guard: timestamps are a concrete failure mode. A time value in a log, metric, and trace may look equivalent to a human. For an LLM, formatting differences—ISO 8601 in one source, Unix epoch in another, relative offsets in a third—can change whether it interprets the sequence correctly or silently inverts causality.

That sharpens the whole thesis. If something as mundane as timestamp representation changes reasoning reliability, the data layer owns part of model quality. It also raises an uncomfortable question: what happens to half the prompt-engineering advice out there if the bigger lever was always upstream transformation?

The Control Plane Question

Better context helps. It does not remove production risk.

Production is sensitive. Production you don't get the opportunity to make mistakes. - Andre Elizondo, Mezmo

But here's the catch: agent-ready data is necessary. It is not sufficient. My lens here is enterprise, so take it with that filter, but orchestration alone does not close the gap. Ownership, rollback paths, and lower-environment testing still matter once an agent can touch real systems.

Mezmo's answer to that pressure test is Aura, an open-source agent framework built to sit on top of their data pipeline and turn curated context into structured investigation loops. One detail stands out: contradictions in the synthesize step trigger replanning instead of confident nonsense. It is model-agnostic, so teams can use a larger model for planning and smaller ones downstream.

And the observability piece matters. Aura exposes trace data through OpenTelemetry so teams can inspect how the agent reached a conclusion and where it corrected itself. That is also why the open-source decision matters. Elizondo is blunt that trust and transparency are slowing the industry down.

I didn't expect that to be one of the strongest parts of the talk, but it might be. Trust rarely comes from "our agent is smarter." It comes from "I can see why it did that."

Why This Matters

That changes the economics. Curated context makes a narrower, safer product possible—one where trust compounds instead of eroding with each production interaction.

Here's the question I'm still working through: if trust and transparency are the real bottlenecks, what should teams measure besides time saved? Incident quality? Replan rate? False-confidence rate? The teams that answer those questions won't just have better agents. They'll be the only ones whose agents survive contact with production.

What Works

Start with the data surface. Do not hand agents raw logs, generic trace dumps, or dashboards and hope the model sorts it out. Curate first.

Design tools for the decision, not backend completeness. If the agent needs "compare anomalous traces before and after deploy," give it that. Do not make it assemble the answer from five CRUD calls and a pallet of JSON.

Keep the reasoning loop explicit. Plan, execute, synthesize, evaluate. Skip the evaluation step and you remove the moment where contradictions can trigger a safer replan.

Make the agent observable. If you cannot inspect tool calls, traces, and self-corrections through something standard like OpenTelemetry, you are asking operators to trust a black box.

Use autonomy as an earned property. Start with co-pilot or assistant modes, especially in production operations, where bad actions cost real money fast. Add sandboxing and lower-environment tests before you let the system take bigger swings.

Stay skeptical of framework-heavy stories. Some of the problem is orchestration. Some of it is operational design, governance, and measurement. Context engineering and guardrails beat raw capability theater.

This works when teams are willing to do the unglamorous work in the data and control layers. Most would rather buy another model and call it progress.

Full talk: Watch on YouTube