Bob Quillin, CEO and Co-Founder, ControlTheory: “Trust is the whole question in agentic systems”

AI may be making software development faster, but the systems used to monitor that software have not necessarily kept pace. For Bob Quillin, Co-Founder and CEO of ControlTheory, that is becoming a problem as AI agents and engineers together push more code into production at a speed that traditional observability was never designed to handle.

Quillin’s argument is not that AI-generated code is inherently bad. It is that the assumptions behind conventional observability are starting to break down. Teams can no longer anticipate every failure worth monitoring, the cost of collecting and storing ever-growing volumes of telemetry can become significant, and runtime behaviour does not necessarily make its way back to the people – or agents – responsible for the code.

That is the thinking behind ControlTheory’s Dstl8, which the company describes as a “runtime feedback loop” rather than another observability platform. Instead of simply reporting what happened after deployment, Dstl8 analyses telemetry at its source, correlates runtime behaviour with deployments, diagnoses the underlying problem and sends that information back into development tools. Its approach includes analysing the actual language in logs for signals such as sentiment, patterns, anomalies and severity, rather than relying solely on predefined thresholds.

In this interview, Quillin discusses what breaks when software velocity accelerates, why ControlTheory believes telemetry should be distilled before it enters expensive observability pipelines, and what its “zero alert rules” approach means in practice. He also explains how feeding incident knowledge into a knowledge graph could change the role of engineers, from searching through dashboards for what went wrong to judging the evidence and deciding what should happen next.

You argue that traditional observability was built for a slower, more predictable cadence of human-generated code. What specifically breaks down when AI dramatically increases both the volume and velocity of software being shipped?

Traditional observability rests on a few assumptions that used to be safe. Someone knows which failures to watch for. A human being writes the thresholds, dashboards, and runbooks for those failures. You collect everything and query it later. And the person who wrote the code remembers what they shipped. All of that worked when humans wrote code at a human pace.

Now teams ship much more code much faster, and it’s written by agents and engineers together. Volume and velocity are climbing at the same time, and they compound. The problem isn’t that AI writes bad code. The problem is that more code is reaching production than any team can watch by hand.

Three things break. First, the known-failure model breaks. Runtime problems show up in behavior, not syntax: connection pools that run dry under real load, retry loops that turn pathological when three services run them at once, queries that are fine on seed data and become table scans at real volume. Nobody wrote a threshold for those. Second, the data economics break, because more code means more telemetry, and storing all of it gets expensive fast. Third, the feedback breaks. An agent’s context ends at merge, so what happens at runtime never makes it back to the author.

Dstl8 describes itself as a “runtime feedback loop” rather than another observability platform. What is missing from conventional observability today, and why is getting the diagnosis back to the engineer or AI agent so important?

Observability tells you what already happened. It was built for the ops side of the house: post-deployment dashboards that someone watches after the code has shipped. What’s missing is the path back to the engineers and agents who are writing the code right now.

That’s why we call Dstl8 the runtime feedback loop for AI-speed engineering. It watches the telemetry continuously, without alert rules, detects the incident, finds the cause wherever it landed—in the infrastructure, the configuration, or the code—and delivers a suggested fix with the evidence behind it. Most AI SRE tools stop at the incident summary. Dstl8 carries the answer to where the work happens and remembers it, so the same incident never gets solved twice.

Getting the diagnosis back is important because that’s where the fix happens. A coding agent already has the repo and the context of the change. When runtime evidence lands directly in Claude Code, Cursor, or Codex, the agent or engineer can act on it in the same session instead of starting from zero next week. Infrastructure fixes go the same way: a suggested change, a human approves, the team’s own agent applies it under their permissions. Teams can also start in staging, so agents see what a change did before customers do.

Telemetry Distillation is central to Dstl8’s approach, with the platform analysing telemetry at the source before it is sent to an observability platform. How does deciding what matters at that point change the economics and effectiveness of monitoring at AI-generated scale?

Our principle is simple: distill out the signal, eliminate the noise, and don’t store everything. The conventional model collects all your telemetry into a data lake, and even when you add AI on top, your agents still have to wade through a sea of noise, burn tokens, and pay to move and store all that data.

Putting raw logs straight into a large language model doesn’t solve it either. Raw log volume overwhelms context windows, and costs add up quickly. At 10GB of logs a day, sending them into a frontier model can run anywhere from roughly $75,000 to $750,000 a month, depending on the model.

Telemetry distillation runs where the data already lives. It reads the actual content of every log line, not just its status code, and pulls out four classes of signal: sentiment, patterns, anomalies, and severity. Only what matters moves on. That focuses the agent on the appropriate context, shrinks the data you pay for, and thus makes the result more useful, because ControlTheory’s own fine-tuned model reasons over signal rather than digging through noise.

Dstl8 treats “sentiment” as a new telemetry signal, analysing the content, tone and confidence of what a system is saying about itself. What kinds of problems can that reveal that traditional thresholds, status codes and anomaly detection might miss?

Logs are language. Systems tell you a lot about themselves in plain text, and most tools reduce that text to a number or a status code. Think of messages like “falling back to default config,” “retrying,” or “unexpected null, continuing.” Each one might sit silently next to an HTTP 200 OK log message. No threshold gets crossed, and nothing looks anomalous on a chart. But the system is quietly telling you, in words, that a problem remains hidden without sentiment analysis.

Dstl8 reads tone and confidence in log and error text the way a person would. That catches the missed failures: swallowed exceptions, errors that have lost their request context, degradations that build slowly after a deploy. It also catches a growing category in AI-native products, where an LLM response is technically successful but fails from the customer’s point of view. Traditional monitoring might count that as a success, but sentiment tells you it actually wasn’t.

You report that an early enterprise fintech customer running Dstl8 across 13 Kubernetes clusters surfaced and resolved 328 incidents over two months without writing a single alert rule. What did that experience teach you about the limitations of rule-based alerting, and what does “zero alert rules” actually mean in practice?

Alert rules encode what someone expected to go wrong. They’re a snapshot of past knowledge. When code changes daily, and the same prompt can produce a different implementation, with a different way of failing, every time it runs, there’s nothing stable to write a rule against.

With one ControlTheory customer in enterprise fintech, Dstl8 ran across 13 Kubernetes clusters over a two-month period and automatically surfaced and resolved 328 incidents, without the team writing a single alert rule.

In practice, “zero alert rules” means nobody configured thresholds, monitors, or runbooks to get there. Dstl8 distills what’s happening, ties what changed to the deploy event, and brings the incident forward with evidence. It doesn’t mean zero humans: engineers still triage and decide. But their time goes to fixing things instead of maintaining alerts. And every one of those results came from log and event data alone. The loop is about to get a lot wider.

Dstl8 doesn’t just diagnose incidents; it feeds investigations and fixes into a knowledge graph and can route diagnoses directly to coding agents such as Claude Code, Cursor and Codex. How does this change the role of the engineer when the system can move from detecting a problem to recommending – or potentially enabling – the fix?

The engineer moves from searching to judging. Instead of jumping between dashboards to rebuild what happened, they start with a diagnosis and the evidence behind it, and then decide what to do.

Trust is the whole question in agentic systems, so to apply the fix, Dstl8 works through the agents you already trust. Dstl8 finds what broke and why, cites the evidence, and pinpoints the change, whether that’s a line of code or a cluster config, then hands it to the agent you’ve given access to make it. Dstl8 does the diagnosing. Your agent does the changing.

The knowledge graph may be the bigger change. Every investigation and fix feeds into it, so past incidents and prior fixes come up automatically the next time. Knowledge that used to live in one senior engineer’s head becomes something the whole team, and every agent session, can build on. That’s how AI-engineering gets better over time, not just faster.

More great interviews coming up

• Spencer Young, SVP International at Delinea: “The most impressive AI demonstrations typically involve a clearly defined task in a controlled environment”
• Jay Wu, President BenQ Europe: “If you have a good setup in your desktop, you immediately feel, oh, I’m pumped to work, right?”
• Ajit Varma, Head of Firefox: “As browsers and software become capable of taking actions through AI, the risks extend beyond what employees intentionally share”