Treating Infrastructure as Data: Building an AI-Native Control Plane

And this clicks. Yeah? Yep. Okay. Cool. Alright. Excellent. So this is actually a really good segue from what Boyan just talked about. So we're gonna talk about the AI native control plane here. And we've all been this dude at one stage. Right? Your state file locks, your pipeline's failing, you find yourself handcrafting and hand rolling state files to sort of unbreak things.

And this is before AI. So this is actually you know, this is before AI. So if we look at if we talk about IAC in general terms, so it was really largely premised around four assumptions. All of these were valid ten years ago. Right? So humans authored the changes. Changes happen at human time scales, which is minutes or days.

One writer per environment, which is usually enforced by some sort of state file or review. And drift was an exception. So this is something you fixed when when and take it went back to steady state afterwards. So these assumptions were all true until AI came along. So AI changes everything.

So every one of those assumptions that we had inverts in the agentic era. So agents and humans both author changes. Changes happen at machine speed, which is dozens per minute, potentially. There are multiple writers operating on the same resource at the same time and they're not coordinating with each other. And drift is no longer the exception.

It's a default state. So we need to start rethinking around the model that we have, you know, known up until now. So we start looking at Drift. So Drift used to be a binary alarm. You know, it went off, you reconciled it, it went back to flat, and, yeah, life goes on.

Right? So in 2026, drift is a continuous waveform. So it's a signal of what the system is actually doing. Should we should be treating this as telemetry, not an error. So agents need to decide, is this a problem or not? Do we need to remediate? Do we need to escalate? Do we need to accept? So this is sort of the new paradigm that we're in.

So if we start to look at where the model strains, so there's four specific places. First is the single rider paradigm. The other is the plan and apply expecting expecting a human, which might always not be the case. Opinionated abstractions, which we'll talk about, and the control plane data plane split. So we're going to go through each one.

There is a demo I've prepared here as well, which I'll show you. So the state file is a cache of what a tool did. So it represents the application of the intent at a point in time. So this sort of, again, is a really good segue to what Boyan talked about. It's not necessarily the current reality. So if a human and an agent touch the same resource at the same time, your state file's invalid automatically.

Right? So the fix isn't to improve locking. It's to recognize that we potentially need to look at this a little bit differently. You know, the source of truth is what the cloud is telling you, what the APIs are telling you. So if we talked about the review cycle. So the review cycle before was doing all the safety work.

And and again, this is really good sort of tie into what Boyan talked about with policies. So when we start to inject humans assessing things and potentially stopping things from happening, you know, autonomous agents don't stop. They proceed. You know, they're they're wired to keep going. Right? So whatever safety we got from a review, we need to replace with something else.

And we'll talk about what the something else is and sort of really good sort of tie into what Boyan talked about. Okay. So opinionated abstractions. So every IAC tool implement you know, Terraform, Polami, CDK, you name it, they all implement their own DSL, their own resource model, their own ecosystem. You know? And that's fine for humans who can master one tool.

But when we have an agent, you know, every abstraction is essentially a new surface that that agent needs to learn. And and it's a new place that can be wrong as well too. So sometimes what helped humans doesn't always help agents. So the other thing is IAC tools are built for the control plane. You know? So they're they're built almost exclusively for the control plane. The data plane is sort of an afterthought or a bolt on in some cases.

So data plane operations, your queries, table access, data access, these all typically lived in different tools. But agents need to traverse both. They need to traverse the control plane and the data plane, you know, to make in a single decision. So the split is starting to become a constraint, and the reality is the cloud provider APIs are converging anyway.

So they're they're exposing the data plane and the control plane through effectively the same interface. Okay. So if we accept that the model is broken, what replaces it? So this is the the piece de resistance here. The new IAC is infrastructure as context.

So it's a it's a small but consequential reframe of IAC. If we start thinking about it this way, we start to to sort of adapt the model that we had. So in the infrastructure as code model, the intent lived in the code. With the infrastructure as context model, the agents query the current state of the system, and the reality is the data.

So the reality is what the API is telling you. So we're not we're not taking away code, so code doesn't disappear. It just stops becoming the contract. Okay. Right. Now I have a demo queued up. I don't know if you guys can switch the is Kieran around? Or

In this scenario, we have a Cloudflare zone sitting in front of an origin and receiving live traffic. Some legitimate, some from AI crawler user agents, some from generic bot scanners. The demo includes two agents, one that reads live analytics and the current rate limit rule, one that tightens the rule and logs the decision. A Kafka topic is used as the audit substrate everywhere an agent makes a call, the record of what, and why lands there. This demonstration will show you a live example of agents querying live reality, decisioning and acting through a universal interface, and treating every action and decision as an audit event.

StackQL is a universal protocol agnostic interface that exposes cloud control plane and data plane APIs, As data sources, you can query or update with SQL. It talks to any provider's interface without needing that provider's SDK. Every query and mutation operation is exposed to humans and agents through a single SQL interface. This includes all CRUD and lifecycle operations for the provider.

Here, we're running live queries against the control and data planes of both Confluent and Cloudflare. This includes a Cloudflare control plane query that reads the active rate limit rule from the Rulesets API, and a Cloudflare data plane query showing live analytics over the zone, so we have the rule configuration and the traffic it's governing, both retrieved through the same interface.

StackQL includes an MCP server which exposes tools to agents to read and act on cloud infrastructure as data, inspecting live state and provisioning or updating resources through a single SQL interface in the famous words of Talk is cheap. Show me the code. Here we have our agent code implemented using the Anthropic SDK, with the Stack QLMCP server.

First it queries Confluent to discover the live Kafka cluster, cluster ID, region, and endpoint. Next it queries Cloudflare for the last thirty minutes of analytics on the zone. It reads the current rate limit rule directly from the live state. This is an example of the query before mutation pattern. The agent receives the activity report and makes a live adjustment to the Cloudflare ruleset, tightening the requests per period threshold.

In other words, the agent asserts the new desired state and converges to it automatically. The agent logs a decision record for every decision and action to a Kafka topic describing what it did and why. This is an example of the agents as event sources pattern. Additionally, every tool call the agents made is written to a log by the MCP server.

We can use DuctDB here to read and analyse the logs. This is the bi temporal pattern in practice. Reality is in Cloudflare and Confluent. Intent is in the agent's prompts. History is this log as well as the Kafka sync. All three surfaces are queryable. So let me leave you with the shift. Infrastructure isn't something agents deploy.

It's something they query, reason about, and act on. The control plane and data plane are both just data sources, and once you see them that way, the answer is obvious: Interact with them with a first class data language. This is what an AI native control plane looks like.

Cool. Thank you, Emma. That's my lovely assistant, Emma. I just need to get her to to pronounce Stack U L correctly, It will be good. And Kafka as well. I don't know if you picked that up. Okay. Cool. So my clicker is not working here for some reason. Is there a reason why that's not happening? Oh, no. That's disabled.

Is that right?

You should just leave the clicker in your hands. Does that work?

Yeah. No. It's not working.

Oh, you may need to just use the slides.

Okay. Cool. That's alright. Now, it's all good. Okay. Cool. So what that demo showed is some of the things we'll talk about that are workable patterns that stand up in the engine era. So none of these ideas are new in isolation. But if we start to combine them together, this becomes the new contract.

Okay. So the first is query before mutation. So we inspect the reality before acting, not the state file. So that is the API. So every decision an agent makes is now grounded in what the actual reality is, the actual state, not what a cache file says or a state file says.

Okay. So that's the first sort of pattern here. Idimportant assertions. Sorry. Did I miss one? No. So we declare what should be, not how to get there. So that's that's not radically dissimilar to what we're doing now. But because we're dealing with live state instead of cache state, we have better guarantees and guards around the changes that we make.

And retries are safe because we're checking the state before we retry. So again, we can we can give agents the ability to retry and resume from partial failures. So bitemporal view, and it should actually be try tritemporal view here. So these are three views. We're keeping them separate.

What is, which is what is what's observed now. What was, which is the trail of observations that we've made, and then what should be, which is the declared intent. So most tools collapse all these into one state file, and we lose the history. So if we keep them separate, then Drift stops being an alarm, and we can it be can something we can drill into and get get telemetry from.

So agents as event sources, every mutation by any author becomes an event. So the audit log is not an afterthought. It's not a a bolt on. It's not a separate artifact. It's actually part of the substrate. So replay, metrics, reconciliation, all read from the same log.

So we don't necessarily need to have a special audit story if we consider the event sources the agents as event sources by default. Universal interfaces. So if we have one query shape across providers yep. So agent you know, agents forcing agents to learn different SDK for every cloud spend, essentially, you're gonna waste most of your tokens on plumbing. So if we have a single self describing interface, we can collapse that. And, you know, again, we're still dealing with the provider specific surface. We're just not making it the model's problem to to work out.

So, again, human review was the safety loop. So agents bypass this by design, so we need policy gates. And, again, you know, a good dovetail from what Boyan talked about with CEDAR and OPA. So policy gates are are the replacements or declarative rules that the agent evaluates against its own intent before acting. Okay. So let's wrap this up here because I'm getting to hurry up here. So three things to take away.

Static state was an artifact of slow infrastructure. It's not a permanent design choice. Agents need safe access to control planes and data planes because the split's going away. We're not you know, agents don't necessarily make a discern a decision of, you know, I stop here. And we treat APIs as our data layer, not our deployment target.

So we build for query, not for code. So in saying that, if I could ask one favor of everyone here in the last minute I've got, who here has GitHub on their phone? Right? I'm I'm surprised. I'm not yeah. So here, can you take a photo of that and star the repository?

It would be greatly appreciated. And with that, I thank you very much.