Ship the Agent to the Data. Here Is What That Looks Like.

Shipping the agent to the data means DataAgent, an autonomous SRE platform, runs inside your Kubernetes cluster and reads state, changes and topology where they already live. Your observability backend stays, and becomes long-term storage priced like storage. Fixes arrive as pull requests your own pipeline executes, and DataAgent acts only within the scope and fault classes you enable.

In What You Won’t Hear at ObservabilityCON I argued that autonomous SRE flips observability: instead of shipping every signal to the agent, you ship the agent to the data. This is how we built DataAgent around that flip, what it does to the stack you already own, what it does to the bill, and how it earns the right to act.

That post closed its argument with a question I suggested taking to every booth at ObservabilityCON: “If my agent could read my data where it already lives, what would I still be paying you for?”

It is only fair to answer it about ourselves. So here is what DataAgent does, shift by shift, with the numbers we have modeled, labeled as such.

The agent inside DataAgent is the thing doing the work in each section below. Three shifts, one per section: where the agent lives, what happens to the backend and the bill, and who holds the keys when something has to change.

Shift 1: the agent goes to the data, inside your Kubernetes cluster

DataAgent runs inside your cluster. It reads what Kubernetes already knows about itself (state, events, what is running where), derives the topology from the live stack, and keeps the drift trail: what changed, and when, before every fault. When a fault needs more evidence, it pulls the logs and metrics for that fault, from where they already are. Nothing is shipped to us raw. What leaves your environment is an abstracted report.

That changes what the “single pane of glass” means. The pane used to be a wall of dashboards that someone had to build, maintain and remember to look at. With an agent in the cluster, the pane is the agent itself. You ask a question in plain language. The agent decides what the answer needs, reads only that, and builds a view for that question. When the question is answered, the view goes away.

Figure 1: The single pane moves to the agent. A plain-language question becomes a view built for that incident, drawn from the live cluster first and from long-term storage only when the question goes past the hot window. From the book The Autonomous SRE.

Notice the third box. Most of the layers that ran every minute in the old model, for a question nobody asked, simply do not run. That is not a feature we added. It is what falls away when the reader can go to the data instead of waiting for the data to come to a screen.

Shift 2: cut the observability bill without replacing your stack

Piece one showed what the central model costs. Priced on one identical workload, platforms that copy everything into a central store came in at roughly 3 to 9 times the cost of running the open-source stack yourself, while the option that reads in place came in at about 1.2 times. The question for anyone who already owns one of those stacks is how to move from the right of that chart toward the left without ripping anything out.

Our answer starts with what a root-cause analysis actually reasons over. We weighted each evidence source by how much it contributes to an accurate answer, and set that against its share of the bill. Three quarters of the weight comes from evidence that never touches the bill: the change history, Kubernetes state and events, and the topology. Metrics and logs still matter. They are how the agent notices the fever in the first place. But they carry roughly a quarter of the answer and almost all of the cost.

Figure 2: RCA weight versus share of the observability bill, by evidence source. Weights are DataAgent’s day-one priors, fitted per fault class over time. From Right-Size the Pipeline, Kill the Data Tax.

Once detection and diagnosis happen in the cluster, the backend you already pay for stops being your real-time nervous system. It becomes what it always was underneath: long-term storage. And long-term storage should not be priced like a hot tier.

So we right-size it, we do not replace it. Your observability engine stays. What you actively read stays hot. Routine data that nobody reads continuously moves to cheap storage, still queryable by you or by the agent. Nothing is deleted. Every change is a native setting in the platform you already run, so it can be reviewed, and almost all of it can be reverted.

How far to go is a dial, not a switch:

• Conservative: reversible configuration changes only, such as moving older data to cheaper tiers and sampling less often.
• Fully optimized: adds routing routine logs to cheap storage at the source, before they are ever ingested.
• RCA-led: the paid firehose is trimmed to what people still read. DataAgent reads live signals in place, alongside your backend, which gets the incident window flushed to it when something actually happens.

A saving built by turning off telemetry is easy to promise and hard to trust. That is why every cut is coverage-gated: a lever is proposed only while DataAgent can still detect what that signal used to catch. If coverage drops, the plan withdraws the cut.

Here is one kind of leak this catches. We gave DataAgent a check for metrics collected more than once. A common culprit: two scrape jobs written for a single central collector, both running on every node. The fix is a couple of lines of configuration, with the same metrics, the same alerts and the same coverage. Leaks like this are how right-sizing ends up potentially reducing observability costs by up to 90%. The full story is in Right-Size the Pipeline, Kill the Data Tax.

That leak was not a pricing problem. It was a configuration change nobody verified. Which is why this has to run continuously, not as a one-time clean-up: estates drift, new clusters log everything by default, and cardinality creeps back. The saving is re-earned every cycle, and it is measured as a real drop in ingestion, not assumed from a spreadsheet.

Shift 3: the agent plans, your pipeline acts (GitOps incident remediation within the scope you enable)

Piece one was honest about where practitioners stand. “Agents can investigate alone, nobody lets them fix alone.” They are right to hold that line, if acting means handing a vendor’s agent write access to production.

So by default we do not ask for it. The hub produces a remediation plan. A pull request carries that plan to a person on your team. The merge is the approval. Your own runner then executes the plan inside your environment, under your credentials, checks that the fix worked, and reports back. The incident is updated with what was done and what was verified, and it stays the system of record for every fault, whether a person fixed it or the pipeline did.

Figure 3: Who holds which key. DataAgent holds the incident, the plan and the verdict. You hold every credential that can change anything. By default, two arrows cross the line, and neither of them is write access. From Remediation First in Action.

DataAgent acts only within the scope and fault classes you enable. Not on day one: it starts read-only, and changes can keep going through your own pipeline. What changes with experience is whether a plan waits for a person. Autonomy is earned one kind of fault at a time: a fault class that has been fixed and verified enough times can, once you enable it, run without waiting for a merge, while everything else still goes through review. That is exactly the rule one practitioner wrote in piece one: “let it draft, never let it decide, until checking its work is fast.” The pull request is how checking stays fast.

Notice how the three shifts depend on each other. Because the agent lives next to the data, its evidence is local and specific. Because the evidence is specific, a reviewer can check a plan in minutes. Because checking is fast, autonomy can be earned instead of granted. And because you decide which fault classes it may act on, none of it requires trusting us more than you trust your own pipeline.

What we do not do

A few things worth saying plainly, because the category is noisy:

We do not ask you to rip out your observability stack. Your engine stays, your people keep the views they rely on, and the archive keeps doing its job.

We do not delete your data to cut your bill. Data is tiered, not dropped. The one destructive lever, expiring stale retention, is off unless you turn it on.

We are not the only team working on autonomous remediation. Several vendors now ship it. We compete on architecture (in the cluster, reading in place, no central data lake) and on auditability (a plan you can read, a merge you control, a record you keep), not on being first or only.

The answer to the booth question

So, what would you still be paying for? With this architecture: storage, priced like storage. History, for the investigations that need it. And an agent that reads in place, plans the fix, and acts only where you have enabled it.

The stage this week showed agents sitting on top of the data cloud. This is the other direction: the agent goes to the data, and the data cloud goes back to being an archive.

See it on your own estate. We offer a free assessment: read-only, inside your environment, on your data. It answers two questions: which classes of failure you are actually covered for, and what your observability bill could right-size down to. Only an abstracted report leaves, and it is yours to keep either way. Book the assessment and say “assessment”. If you would rather build the loop yourself first, join the free, open-source autonomous SRE training series.

FAQ

Does DataAgent replace my observability backend?

No. It runs alongside the stack you already have. Your engine and your team’s views stay; the backend becomes long-term storage, and routine data moves to cheaper tiers instead of being deleted.

What data leaves my cluster?

Only an abstracted report. DataAgent reads Kubernetes state, events, topology and the drift trail in place, and pulls logs and metrics for a specific fault from where they already are. Nothing is shipped raw.

Does DataAgent ever get write access to production?

No. DataAgent never holds your credentials: fixes run through your own runner under your credentials. By default, DataAgent produces a remediation plan and a pull request carries it to your team. The merge is the approval, and your runner executes it and reports back. What you enable, per fault class, is whether a plan can run without waiting for a person.

How is DataAgent priced?

Per managed cluster. No ingestion fees, no telemetry tax, no data retention costs.

Can I evaluate it without letting it change anything?

Yes. A read-only deployment inside your environment produces a fault-coverage report (which failure types it can detect, understand and potentially remediate) and a cost analysis of the telemetry your tools collect, including overlap and redundancy.

Which fixes can run without a human approving each one?

Only the fault classes you enable after they have been fixed and verified enough times, such as restarting a service, scaling a resource or rolling back a deployment. Everything else still waits for a merge.

References

This series

• What You Won’t Hear at ObservabilityCON: the vendor-neutral argument this post answers, with the 355-practitioner read and the managed-premium chart.
• Who Is the Dashboard For?: why the dashboard was always built for a human reader.
• Right-Size the Pipeline, Kill the Data Tax: RCA weight versus bill, and the measured duplicate-collection leak.
• Nobody Can Tell You What Observability Really Costs and Good news: your observability bill is about to drop: the cost method and the managed premium.