Opinion
We are asking agents questions our data systems were never built to answer
"The data layer deserves more attention in the discussion about agents," writes Coralogix CEO Ariel Assaraf. "Retention matters, but so does the ability to use what we retain."
A customer tries to transfer money. It fails. They try again, then give up. The bank has a failed transaction, but understanding why it lost that customer takes more work. The answer could involve an application error, a slow service or a problem affecting one version of the mobile app.
That is a useful job for an AI agent. It can follow the transaction through the system and check different explanations. Unless the trace was sampled out, the relevant field was dropped or the logs have already expired.
We made those choices for reasonable reasons. Keeping detailed telemetry was expensive. Teams retained what they needed for their dashboards and expected investigations. Over time, the data available became a reflection of the questions people already knew to ask.
An agent inherits those limits. It might write a correct query against an incomplete dataset and produce a convincing explanation. We can change the model, but the missing event is still missing.
This is why I think the data layer deserves more attention in the discussion about agents. Retention matters, but so does the ability to use what we retain. If checking a new explanation requires restoring an archive or asking someone to build another data pipeline, the investigation gets stuck. The agent needs to query the original records, extract a field it has not used before and connect events across services.
We started building around this at Coralogix seven years ago: analyze telemetry as it arrives, keep it in an open format in the customer’s own object storage and query it directly. It was slow and expensive at first, and sometimes unstable. Our teams spent years working on stream processing, how the data is organized and written, and the DataPrime query engine. The aim was to make retained history usable during an investigation, even when the question was new.
For agents, this has a very practical consequence. Each result leads to another query. They need to know whether a query completed, returned only part of the data or found no matching events. Those outcomes cannot be treated as the same answer.
Having that history available does not mean feeding all of it into a prompt. The agent should retrieve the evidence it needs within its permissions. And if it proposes a change, we need to be able to check the evidence behind it, enforce authorization before execution and observe whether the change actually helped.
In the banking example, an agent saying “fixed” would not be enough. We would need to see that transfers were succeeding again, including for the customers who had been affected. That requires the technical events and the business outcome to be observable together. It is the standard I would use to judge whether the agent did its job.
Ariel Assaraf is Co-Founder and CEO of Coralogix.
