🎯 What Is the Agent Control Plane
Cole Medin built the Agent Control Plane as a direct response to the problems he identified with pure loop engineering. It’s a open-source dashboard on GitHub which acts as the central nervous system of any loop setup: durability, observability, and human-in-the-loop in one place.
"Criei este painel que estou muito animado para mostrar agora. Ele é open source no GitHub. Desenvolvi para resolver muitos dos problemas que temos atualmente com a engenharia de loops."
🧩 The Dashboard's Three Pillars
Durability
All loops, events, and logs live in Postgres. If the agent goes down, the orchestrator resumes where it left off by reading the state from the database.
Observability
See the orchestrator's decisions, workers' progress, and cumulative cost per run in real time.
Human-in-the-Loop
Pause the loop between rounds, validate results, and approve or reject them before continuing.
Context: why this exists
Cole is honest in saying this is "more experimental". But the motivation is concrete: without a dashboard, loops are black boxes. You start one, walk away, and when you come back, you don’t know whether the result is good or whether it burned tokens for nothing. The Agent Control Plane is an attempt to solve this in a practical, replicable way.
💾 Postgres/Neon as a State Store
The heart of the system is a Postgres database hosted on Neon (serverless Postgres). All the loop state lives there: which round we're on, which workers were launched, which ones completed, which failed, and the cumulative cost.
"We're managing all of our state in an external database. So we're not relying on that staying in any coding agent session."
🔄 The Orchestrator-State-Workers Cycle
Orchestrator reads the state
Query the database to find out: which tasks are pending? Which workers completed? What’s the overall progress?
Orchestrator decides and dispatches workers
Based on the state, plans the next round and launches workers with specific prompts.
Workers update the state
Each worker writes its result to the database. The orchestrator sees the updated state in the next round.
Loop continues until completion
The cycle repeats until the orchestrator determines that all tasks are complete or a human-in-the-loop intervenes.
🔍 Observability: Real-Time Decisions
The real power of the dashboard lies in see exactly what the orchestrator decides in each round: how many workers it launches, which prompts it sends, and how it responds to the results that come back. Without this, you're flying blind.
"Being able to see exactly what decisions are being made here makes it easy to analyze everything, even ask my coding agent to analyze the runs in the database, and then figure out how to improve the loop."
What you see on the dashboard
- ✓Complete run history with all rounds
- ✓Orchestrator decisions per round (how many workers, which tasks)
- ✓Tokens consumed per round and per worker
- ✓Status of each worker: completed, failed, in progress
The Live Demo
Cole demonstrated it live in the video: he created a prompt to build a Kanban board as a single-page app and started the loop. In the dashboard, you could see the orchestrator planning, spending 6,000 tokens on the initial plan, and dispatching three workers in the first round. "We can see that the orchestrator is deciding how to split up the work right now."
💡 Insight: Dashboard as an Improvement Tool
Cole points out that observability isn’t just for monitoring, but for improvement. By analyzing the logs in the database, you (or even your coding agent) can identify inefficiency patterns and adjust the harness. The dashboard becomes a tool for continuous learning about the system itself.
💰 Cost Tracking per Run
One of the dashboard's most practical features is the integrated cost tracking. Cole built this because he realized that without cost visibility, it's impossible to know whether the loop is efficient or burning money.
"In a single run, I spent over a million tokens just to build a relatively simple app. And yes, I’m sure there are a lot of optimizations I could make here. But I think just looking at this, you can understand why it would be so expensive."
📈 What Cost Tracking Reveals
Orchestrator vs. worker cost
The orchestrator spends tokens reasoning about the state and planning. Workers spend tokens executing. Viewing the breakdown shows where to optimize.
Cost per round
If the cost per round is rising, it may indicate context bloat or an inefficient orchestrator. If it is stable, the system is healthy.
Total run cost
The final question: does the value delivered by the loop justify the cost? If a Kanban board cost 1M tokens, it’s worth reconsidering the approach.
⚠️ The Scary Number
1 million tokens for a relatively simple app. And Cole using Kimi (the cheapest model), not Opus. Without cost tracking, this kind of spending goes unnoticed. The dashboard turns an invisible number into something actionable.
✋ Human-in-the-Loop: Pause + Approve
Cole considers human-in-the-loop the most important guardrail for loop engineering. The dashboard lets you pause the loop after any round and require human approval before continuing. This solves the classic problem of runaway loops.
"We can even have human in the loop so that we get to actually take a look at what has happened in the first round before the orchestrator moves on to the next. That is the kind of reliability that I feel like we really need to have right now."
How It Works in Practice
Pause between rounds
The loop completes a round, writes the state to the database, and stops. The human gets a notification (or sees it on the dashboard) and decides: approve and continue, or intervene and adjust.
Approve with identity
The “approve and resume” button on the dashboard verifies the user's identity via Retool. Only those with permission can approve the loop's continuation. This is essential for team use.
Status check via orchestrator
While the workflows run, you can ask the orchestrator for its status. "You can even ask for a status update while the Archon workflows are running."
🎯 Reflection Point
The problem with many loop engineering setups is that people "set up these systems to just go, go, go, go. And then you have a run for a day. And by the time it comes back, you just have crap." HITL isn't overhead: it's the difference between a useful loop and a destructive one.
❓ Questions and Deployment with Retool
Cole demonstrates how the local dashboard can be deployed in the cloud via Retool, turning a personal tool into team infrastructure. The process is simple: import React, connect to Neon, and get a URL accessible from anywhere.
"We can even take this kind of dashboard and deploy it to the cloud as well. So we can access it from anywhere, maybe even start to share our loop setup with our teammates."
Deploy in 3 Steps
Import the React frontend zip into Retool. The Retool agent connects everything automatically.
Connect to the Neon database by creating a Postgres resource in Retool with the connection credentials.
Set up permission groups to control who can approve/reject loop rounds.
Does the dashboard need to exist?
Yes, if you plan to use loops seriously. Without visibility, you're operating in the dark. Cole was direct: he built the dashboard because he needed it, not as an academic exercise. Observability is a requirement, not a nice-to-have.
It doesn't need to be sophisticated
The point isn't to build an enterprise dashboard. It's to have a minimum level of visibility: which rounds ran, how much they cost, and where the orchestrator went wrong. Even a script that queries the database and generates a report is better than nothing.
The Future: Dashboards as a “Second Brain”
Cole mentions that he’s integrating dashboards into his "second brain" to manage autonomous tasks. The idea is that the dashboard isn’t just for coding loops, but for any system where agents work autonomously and need supervision.
📋 Module Summary
Next Module:
3.4 - Cost Optimization: provider mixing, model routing, external state, and metrics to keep loops viable