AI agent systems are becoming increasingly capable — but operating them reliably is a different problem.
Once a system contains multiple agents, workers, APIs, asynchronous jobs, infrastructure automation and security controls, the main challenge is no longer simply building agents.
It is controlling the system around them.
I built an agentic control plane to explore this problem: a platform designed to give me a single operational layer for orchestrating agents, observing executions, enforcing governance and replaying workflows.
This article explains the architecture and the engineering principles behind it.
The problem: agents are easy to add, difficult to operate
A single AI agent is relatively simple.
Add several agents with different responsibilities, however, and the system quickly becomes more complex:
User
↓
Agent A
↓
Agent B
↓
Worker
↓
API
↓
Infrastructure
Now introduce asynchronous execution, shared state, authentication, failure handling, observability and security.
The architecture starts looking more like a distributed system than a chatbot.
The question becomes:
How do you operate an agentic system as an engineered platform rather than a collection of independent agents?
That is the problem I wanted to investigate.
From agents to a control plane
Instead of treating every agent as an isolated application, I designed a control layer around them.
The simplified architecture looks like this:
┌─────────────────────┐
│ Client │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Control Plane │
│ │
│ Routing │
│ Governance │
│ Execution │
│ Observability │
└──────────┬──────────┘
│
┌───────────────┼───────────────┐
│ │ │
▼ ▼ ▼
Agents Worker Services
│ │ │
└───────────────┼───────────────┘
│
▼
Infrastructure
The important distinction is that the agents are not the platform.
They are components operated by the platform.
That distinction changes the architecture considerably.
1. Agents become managed components
Each agent has a defined responsibility.
Instead of allowing agents to arbitrarily interact with everything around them, the control plane provides boundaries around execution.
Conceptually:
Agent
├── Identity
├── Capabilities
├── Inputs
├── Outputs
├── Execution state
└── Policies
This makes an agent closer to a platform workload than a simple prompt wrapped around an LLM.
The control plane can therefore answer questions such as:
- Which agent is running?
- What is it allowed to do?
- What triggered the execution?
- Which workflow is it part of?
- What happened during execution?
- Did the execution succeed?
- Can the execution be reproduced?
These questions become increasingly important as the number of agents grows.
2. Governance is part of the architecture
Governance should not be an afterthought.
An agent that can call an API, modify infrastructure or trigger another workflow effectively has operational capabilities.
Those capabilities need boundaries.
I therefore treat governance as an architectural layer:
┌───────────────────┐
│ Request │
└─────────┬─────────┘
│
▼
┌───────────────────┐
│ Governance │
│ │
│ Identity │
│ Permissions │
│ Policies │
│ Validation │
└─────────┬─────────┘
│
▼
┌───────────────────┐
│ Execution │
└───────────────────┘
The objective is not to prevent automation.
It is to make automation controlled and observable.
3. Asynchronous execution
Not every operation should happen synchronously.
Some workflows can take time, involve external systems or require multiple steps.
A worker-based execution model provides a useful separation:
API
│
├── validate request
│
├── create execution
│
└── enqueue job
│
▼
Redis
│
▼
Worker
│
├── Agent execution
├── External API calls
└── Infrastructure operations
This separates the request lifecycle from the execution lifecycle.
The API can acknowledge the operation while the worker performs the actual workflow.
It also gives the control plane a natural place to track execution state.
For example:
PENDING
↓
RUNNING
↓
SUCCESS
or:
PENDING
↓
RUNNING
↓
FAILED
The state itself becomes an operational artifact.
4. Observability
An agentic system cannot be operated effectively if the only observable output is:
"Task completed."
I want to know what actually happened.
For each execution, the platform can associate:
Execution
├── workflow
├── agent
├── timestamp
├── input
├── state
├── events
├── logs
├── outputs
└── errors
This creates an execution history rather than a black box.
The control plane becomes a place where the system can be inspected as it operates.
5. Replayable workflows
This is one of the most useful capabilities I added.
If an execution is represented as a structured workflow rather than an ephemeral interaction, it can potentially be replayed.
For example:
Workflow #1842
Step 1 → Agent A
Step 2 → Validation
Step 3 → Agent B
Step 4 → Worker
Step 5 → Infrastructure operation
Instead of simply recording:
Something happened.
The platform records:
This workflow executed these steps, in this order, with these inputs and these results.
That enables another important operation:
Original execution
│
▼
Record
│
▼
Replay
│
▼
Compare results
Replay is particularly interesting for testing.
A workflow that previously failed can become a regression case.
A security scenario can become a repeatable test.
An operational circuit can become something that can be executed again under controlled conditions.
This moves testing closer to the actual behavior of the platform.
6. The control plane as an operational interface
Once the system has structured execution state, workflows, agents and infrastructure events, the next problem becomes visualization.
Instead of exposing every component through separate interfaces, I built a centralized operational interface around the control plane.
The interface provides a representation of the system itself:
CONTROL PLANE
┌──────────┐ ┌──────────┐
│ Agents │──────▶│ Workers │
└──────────┘ └────┬─────┘
│
▼
┌──────────┐
│ Services │
└────┬─────┘
│
▼
Infrastructure
The visual layer is not the architecture.
It is a representation of the architecture.
That distinction is important.
The underlying system remains API-driven and service-oriented; the visual interface becomes an operational surface on top of it.
7. Why this architecture matters
The interesting part of an agentic platform is not the number of agents.
It is the operational model around them.
I found four principles particularly important:
1. Agents should be managed as workloads
An agent needs identity, capabilities, state and boundaries.
2. Execution should be observable
A workflow should produce structured execution data, not only a final response.
3. Workflows should be replayable
If an operation matters, being able to reproduce it is extremely valuable for testing and debugging.
4. Governance belongs in the control plane
Permissions, validation and execution policies should surround automation rather than being implemented independently inside every agent.
What I learned
Building this system changed the way I think about agentic applications.
The difficult part is not getting an LLM to call a tool.
The difficult part is building the infrastructure that makes those actions:
- controlled,
- observable,
- testable,
- reproducible,
- and operationally understandable.
That is why I increasingly think about agentic systems in terms of platform engineering.
An agent is a component.
A workflow is an execution unit.
A worker is an execution engine.
And the control plane is what turns those components into an operable system.
Where this goes next
There are still many areas to explore:
- stronger policy enforcement,
- richer execution traces,
- more deterministic replay,
- automated regression testing,
- failure injection,
- security testing,
- and better visualization of distributed agent workflows.
The goal is not to build more agents.
The goal is to make increasingly autonomous systems operable.
That is the problem I am exploring with this project.
What would you put in an agentic control plane?
I am particularly interested in approaches to governance, replayability and testing of multi-agent systems.
Top comments (0)