The Agent Manager Is the New Control Plane

Developer tools are becoming orchestration systems

For most of software engineering history, the developer tool was a text editor with helpers around it — intellisense, debuggers, linters, source control. The unit of attention was the line, the file, the buffer.

Agent-first IDEs change that. Antigravity’s Agent Manager / Mission Control puts the developer one level up: looking at a roster of agents, each working on its own task in its own workspace, each producing its own plan and artifact trail. The unit of attention is the agent, not the file.

That is an orchestration system. The label has not caught up, but the shape has.

Manager views create a new operating model

When the dashboard shows ten agents working on five tasks in four workspaces, the developer’s job is closer to a team lead than to a typist. Decisions look like: which agent to escalate, which artifact to inspect, which task to redirect, which workspace to merge.

That is genuinely useful. It is also new infrastructure that has not yet absorbed the lessons of every other operations dashboard humanity has built — namely, that visibility without policy is incomplete.

Multi-agent work needs policy, not just visibility

A control plane that only shows what is happening is observability. A control plane that constrains what is allowed to happen is policy. The two are not the same thing.

• Observability — you can see Agent #3 is about to merge a change that introduces a forbidden dependency.
• Policy — the merge does not happen, regardless of who is watching.

Both are valuable. Only one is sufficient for autonomous execution at scale.

Governance must travel across workspaces

The manager view in Antigravity shows agents working across multiple workspaces. That distribution is the point — parallelism. But it is also the failure mode: each workspace is a potential surface where an architectural decision in one place is not enforced in another.

The governance layer underneath the manager view has to be the same across all of them. Governance propagation is what makes that possible — the same compiled constraints fan out to every agent in every workspace, so the manager view is showing work that was already evaluated against the same rule set.

Architectural decisions need to become executable controls

The Agent Manager surfaces what agents are doing. The governance layer underneath should surface, alongside each task, the architectural decisions that apply — and the verdict from checking the agent’s work against them.

That turns the manager view into a real control plane: not just “here is what the agents did,” but “here is what they did, and here is whether the system approves of what they did.”

Mneme framing

Mneme is not trying to be the agent manager. It is the governance layer that agent managers should call before and during execution. The Agent Manager orchestrates; Mneme constrains; together they form a control plane that does both jobs.