What Is an Agent Control Plane? James Everingham on Guild.ai and Why 2026 Is The Year of Agents

Most engineering orgs are stuck in the same loop. They roll out AI tools, see promising demos, and then watch the productivity numbers go fuzzy as the org quietly drifts back to business as usual.

James Everingham has lived the opposite story. After nearly a decade at Meta — including leading Instagram engineering — he was pulled back to run Dev Infra, the 1,000-person org responsible for the internal developer experience of 40,000 engineers. The platform his team built there, DevMate, grew to the point where its agents were submitting roughly 50% of all diffs at Meta.

Now, as CEO of Guild.ai, Everingham is taking those lessons to every other engineering org. On a recent episode of Dev Interrupted, he sat down with host Andrew Zigler to explain how he thinks about the shift — and why he believes 2026 is the year engineering teams have to start thinking about agents as infrastructure, not as editor plugins.

An agent control plane is a centralized piece of infrastructure that lets a company govern AI agents across its entire stack. It manages how agents are deployed, how they're rolled back, what parts of the infrastructure they can access, what they're doing in real time, and how much each one costs.

His plain-English version of the same idea, from the episode:

What is a control plane? It's a piece of infrastructure that allows you to govern these things. You need to be able to understand what these agents are doing in your infrastructure instead of just giving them access to everything and letting them YOLO it. The ability to deploy these, roll them back, give them access to specific parts of your infrastructure to be able to log and see what they're doing, to be able to understand the costs of what each of these are doing — this is the challenge that's coming up.

The OpenClaw incident is the cautionary tale he points to on the show: people gave an agent broad access, and ended up with passwords exfiltrated and malware installed. Annoying on a personal laptop. Catastrophic at the corporate level.

When Meta started experimenting with AI in the SDLC, the team began where everyone begins: in-editor autocomplete. Meta even built its own version of Cursor internally, called Code Compose.

It worked — for some people. Junior engineers got a meaningful boost. Surprisingly, so did some of the most senior engineers. But the bulk of engineers in the middle didn't move. Everingham is the first to admit the team had to do real thinking about what "moving the needle" even means before it could measure anything.

The unlock came when the team stopped thinking about AI as something that lives inside the editor and started moving agentic behavior closer to the source control system.

AI is a very powerful tool, but if you actually move some of this new agentic behavior closer to your source control system as part of the infrastructure, you get a lot more impact and you can do a lot more interesting things. Source control is the canonical source of truth — your teams, your tools, everything connect to it.

That insight is what eventually became DevMate.

DevMate gave Meta engineers a single surface where they could see what agents existed, how they worked, fork them, and build their own. Everingham is direct about why that mattered:

As engineers — speaking for myself — I was a better thief than coder. I would go look for something that does kind of what I want, wrangle it into something that works for my specific thing, and learn along the way.

When the centralized platform existed, ideas stopped coming top-down from the Dev Infra team and started coming from the engineers actually using the tools. Two examples that came up on the show:

• Diff Risk Score (open-sourced last year). An LLM-powered system that scores how likely a diff is to crash production. Meta freezes its codebase from December 9 through January every year because that's the highest-traffic period — Diff Risk Score is what's letting them start to remove that freeze.
• The onboarding agent. An engineer who wanted to ramp up on a new codebase built an agent that turned the source control system "sentient." A new engineer could ask, "I need to work on these specific camera filters," and the agent would point them at the right files, draw a system diagram, and explain the history of why things were built the way they were. Meta tracks TTFD — time to first diff — and this single agent moved it significantly.

Building great software is an act of empathy.

That last quote is a refrain throughout the conversation, and it's the philosophy behind why the onboarding agent worked: it wasn't built by leadership trying to optimize a metric. It was built by an engineer trying to make the next engineer's life easier.

One of the strongest parts of the conversation is the pushback on top-down AI mandates from CEOs.

I do get a little frustrated when I see CEOs and leaders mandating their teams use AI for productivity. The best developer tools — you have to earn the usage. Developers are smart. They have a set of tools they've become very proficient with over time, and they take some convincing.

His alternative: instead of mandating tools, put business challenges in front of the org that are big enough that AI is the only realistic way to solve them. Then let senior engineers who succeed with AI become evangelists organically.

A few of the challenges Meta put out internally:

• Eliminate code freeze.
• Build self-healing fabric — software that detects its own crashes, writes the fix, writes a test case proving the fix works, and lands it responsibly.
• Build a testing harness that simulates how a real human uses the product. Not a unit test — a script like "You're a user walking down the street, you take photos, you wonder where there are restaurants, you look those up," and an LLM replays that scenario against the product.

You don't say "I want something incrementally better." You have to put challenges out to your org that are crazy. You have to go order of magnitude. Go to your team and say: we have to 10x revenue in six months. Or our CI/CD from land to production is six hours — get it to five minutes.

This is the point in the conversation where the framing pivots from "what worked at Meta" to "why every org now needs new infrastructure."

If 2025 was the year of coding, 2026 is the year of agents. What this means is that we're seeing a lot of these reasoning models and different architectures that are now not just being part of an autocomplete — they're becoming a fabric of the company. So you need a control plane to be able to manage these.

The pattern he sees: agents are about to stop being tools an individual engineer fires up locally and start being infrastructure that a whole company depends on. The teams that build for that shift early will look very different from the teams that don't.

One of the most useful framings in the episode is the distinction between how most teams run agents today and where they need to go.

Right now, the way that engineers and teams are building agents and infrastructure is what we call single-player mode. It's like you have an engineer firing up Claude Code, has it running on their server or even their laptop, doing something. But this stuff needs to be multiplayer.

Multiplayer mode means more than one human can use, share, and inspect the same agents — and more than one role in the company has to be able to access the system. Security teams need to set policy. Finance teams need to audit token spend. Platform and IT teams need to manage the lifecycle. That's what a control plane actually solves: it's the layer that turns a personal workflow into shared infrastructure.

When Andrew asks who in an org should own the control plane, Everingham reframes the question — and lands on a more important one: what kind of control plane should you avoid?

If you have a specific vendor owning it, just by the nature of what they're trying to do, it'll probably lock you in and limit you more to their solutions. If you're trying to build something that picks up the best of all of the solutions out there, you may not want to be locked to a single vendor.

This is the case for a neutral control plane: one that can route across OpenAI, Anthropic, Google, and self-hosted models without rewriting agent code every time the model landscape shifts. Which it will.

The answer to "where do we even begin" is grounded — and it's the same advice that closes the episode.

I always think a place to start for any team is to find something that works, look outside your company, and use that as a model.

Reference agents. A centralized place to share them. Big enough business challenges that AI becomes the natural tool. Senior engineers who become evangelists because the work is genuinely better. That's the playbook.