A control layer for imperfect autonomous systems: security, operations, verification and intervention in one place. Know what your agents can do, see what they actually do, and verify that the job got done.
AI agents are brilliant when they work. The problem is knowing when they don't.
An agent can run successfully, miss half the task, hit an error, work around it badly, use the wrong tool, stop early, exceed its intended authority, or confidently report that everything went perfectly. So you add monitoring. Then another agent to check the first agent. Then alerts. Logs. Spreadsheets. Scheduled checks. More agents. Before long, supervising the automation becomes work of its own.
Agent Control is being built to change that: one place to know what agents you have, what they're supposed to be doing, what they're allowed to do, what they actually did, whether the job really got done, and which ones need you.
Most agent failures aren't science fiction. They're ordinary. The agent misses something. The task silently stops. The API fails. The agent thinks it recovered; it didn't. The scheduled task doesn't run. The expected output never appears. The agent completes 17 of 20 checks and reports SUCCESS. The checker agent looks at the result and reports VERIFIED. It isn't. Meanwhile, the human thinks everything is working.
The problem isn't rogue agents. It's unsupervised confidence.
A modern AI agent may be able to browse websites, read documents, write code, access your CRM, change records, send emails, publish content, call APIs, use other agents and operate while you're asleep. Yet that same agent may fail to recognise that it misunderstood the task, that an expected step was skipped, that the information it received was wrong, that its workaround created another problem, or that the job isn't actually finished. Capability can exceed judgement. That's why agents need control.
Running multiple agents can sometimes feel like supervising a room full of very capable toddlers. You give each one a job. One wanders off halfway through. Another confidently brings you the wrong thing. One insists it's finished when it isn't. Another gets stuck and doesn't tell you. So you ask another one to check everyone's work. It tells you everything looks fine. It doesn't.
The analogy isn't perfect. AI agents aren't children. But the solution is surprisingly similar. You don't stand in the middle of the room trying to watch every movement. You control the environment: which doors are open, what they can touch, where they can go, what requires you, how you know when something happened, what proves the task succeeded, and how you intervene when it didn't.
You don't control agents by constantly supervising every move. You control the environment they're allowed to operate in.
With two agents, you can remember everything. With five, maybe. Then you have scheduled agents, research agents, coding agents, customer agents, monitoring agents, content agents, subagents, different models, platforms, tools, permissions, schedules and owners. Suddenly you're remembering which agent runs when, which failed yesterday, which stopped running, which needs checking, which has access to what, which someone changed, which is costing too much, and which said everything was fine when it wasn't. The human shouldn't have to be the Agent Register. The system should.
Agent Control is designed to create a control layer around the AI agents working across your business. Not another agent telling you "don't worry, I've checked the agents", but a system for understanding the evidence. The model is six steps: KNOW what agents exist, DEFINE what they're supposed to do, CONTROL what they're allowed to do, OBSERVE what they actually do, VERIFY whether the job got done, and INTERVENE when something needs you.
Start with the Agent Register. Every agent gets a unique identity, name, purpose, human owner, model, provider, platform, systems, tools, risk, authority, status and review date. So instead of "I think we've got about 20 agents running", you see: 23 active agents, 4 high authority, 3 need review, 1 has no owner, 2 haven't run successfully, 5 haven't been independently verified recently.
Agents shouldn't become orphaned infrastructure. Someone leaves, their agent keeps running, the credential remains, the schedule continues, nobody remembers why it exists. Agent Control should flag "active agent, no owner", and retirement should mean more than turning a schedule off: revoke credentials, remove integrations, remove delegated permissions, stop schedules, remove agent relationships, archive logs. And because an agent reviewed three months ago may not be the same agent today (someone may have changed its prompt, model, tools, credentials, permissions, schedule, workflow, connected systems or subagents), Agent Control should answer what changed and whether that change requires another review.
An agent shouldn't simply exist because "we built it six months ago". Agent Control records its purpose, for example: "Competitor Monitor: check 25 named competitor websites each morning and report significant product, pricing or positioning changes." Now you can compare expected behaviour with observed behaviour. If Competitor Monitor suddenly accesses Finance, that's unusual. If it checks only 17 competitors, that's incomplete. If it stops running, that's visible. Purpose becomes part of control.
Success should be defined before the agent starts. "Monitor our competitors" is difficult to verify. "Check these 25 domains every weekday, record whether each was successfully checked, alert me to material changes, and a run cannot be marked complete unless all 25 are checked or failures are explicitly reported" is observable. Agent Control should help define expected inputs, actions, coverage, output, verification and failure behaviour, so the agent doesn't get to invent what "done" means.
Not simply "CRM access", but what the agent can actually do, using an authority model: READ, RECOMMEND, PREPARE, CHANGE, SEND, SPEND, PUBLISH, DELETE. An agent can be highly capable without having high authority. A brilliant research agent might remain READ + RECOMMEND. The smartest agent in the business doesn't need to be the most powerful one.
For every important system, permissions resolve to ALLOW, DENY or APPROVAL REQUIRED. For example, a Sales Agent:
| System / action | Decision |
|---|---|
| CRM READ | Allow |
| CRM CHANGE | Limited |
| CRM DELETE | Deny |
| External SEND | Approval required |
| Finance | Deny |
Now "the agent has CRM access" becomes something meaningful. And consequential actions get hard boundaries, not just instructions. Instead of telling an agent "don't spend more than £500", enforce or connect to a rule: transaction over £500, approval required. Instead of "never send customer data outside the company", enforce: unapproved external destination, denied. The agent cannot negotiate with the boundary.
Humans go where consequences begin, not in front of every action. Research and drafting autonomous; routine internal actions autonomous where appropriate; unusual customer communication maybe review; significant spend, production deployment and irreversible deletion under approval or strong control.
Once agents work together, individual permissions aren't enough. If a Sales Agent cannot access Finance but can call the Finance Agent, can it ask the Finance Agent to retrieve financial data? If yes, the original permission may not mean much. Agent Control should show an Agent Relationship Map (Sales Agent to Research Agent to CRM Agent, while Finance Agent sits behind a separate authority boundary) and preserve original requester, originating agent, delegating agent, executing agent, authority, approval and result. Delegation should never create authority: a low-authority agent shouldn't acquire greater authority simply because it knows which agent to ask.
A Content Agent with direct authority READ + PUBLISH looks reasonable. But if it can call a Research Agent that can call a CRM Agent that can access customer records, it may have an indirect route to information nobody intended it to reach. Agent Control should calculate direct authority and effective authority. Not just what can this agent do, but what can this agent cause?
A scheduled task existing doesn't mean it ran. Agent Control should show expected run, actual run, start and finish time, duration, status, errors, retries, missing runs and unexpected runs, instead of discovering three weeks later that your "daily" agent stopped on Tuesday. For each run, it should show which agent, which task, which systems, which tools, which actions, which failures, which denied actions, which approvals, which other agents, what output, what cost and what result. Not necessarily every internal thought; the operational evidence.
Some of the most important agent problems aren't actions, they're absences: the expected task didn't run, the expected source wasn't checked, the expected output wasn't created, the expected approval didn't occur, the expected verification was skipped, the expected agent never responded. Nothing dramatic happened, and that's exactly the problem. Silence can be a failure signal. Agent Control should also watch the edge of authority: denied actions, repeated denied actions, approval requests, unusual systems and destinations, unexpected tools, new agent relationships, unusual spend, unexpected execution times, large changes and retries after rejection. That's often where interesting behaviour appears first.
And it should watch cost, because an agent can enter a retry loop, run too frequently, launch unnecessary subagents, repeatedly call APIs, use expensive models or run far longer than expected. Model usage, API calls, tool calls, runtime, retries, subagents, task cost and daily cost all matter. A broken agent shouldn't quietly spend £400 proving it's broken.
This is one of the most important ideas behind Agent Control: separate agent-reported status from verified status. The agent may report SUCCESS on a task that expected 25 competitor websites checked, while the observed evidence is 21 checked, 3 failed, 1 skipped, giving a verified status of INCOMPLETE. The system doesn't simply repeat what the agent believes happened; it compares that claim with evidence.
Don't ask the agent whether it succeeded. Verify the outcome. Agent says email sent: check the email provider. Agent says database updated: check the database. Agent says backup complete: check the backup. The closer verification gets to the real consequence, the more useful it becomes.
So outcomes stop being just SUCCESS or FAILED. Real agent operations need VERIFIED SUCCESS, PARTIAL, INCOMPLETE, BLOCKED (agent correctly stopped at a control boundary), NEEDS REVIEW, FAILED, and NOT VERIFIED (agent reported completion but independent verification hasn't occurred). A green tick should mean something. And one of the most useful alerts is disagreement: agent status not equal to verified status. Agent SUCCESS but evidence FAILED is urgent. Agent SUCCESS but evidence PARTIAL means investigate. Agent FAILED but evidence SUCCESS means the agent's own reporting may be wrong. Each tells you something.
Crucially, don't just add another checker agent. Agent A does the task, Agent B checks it, but Agent B can fail too, and then you need Agent C to check Agent B, and eventually you've built a tower of agents checking agents. Agent Control should favour independent evidence where available: system APIs, database queries, logs, automated tests, external monitors, expected-state comparisons, transaction records, human verification. Another agent can help, but another AI saying "looks good" isn't proof.
This is the heart of the dashboard. Not "14,762 events today", which nobody wants, but which agents need you. For example:
| Agent | Issue | Consequence | Action |
|---|---|---|---|
| Backup Agent | Agent says SUCCESS, no backup found | High | Investigate |
| Competitor Monitor | Expected 25 sources, observed 23 | Low | Review |
| Payment Agent | Requested £780 new supplier, limit £500 | High | Approve / Deny |
| CRM Agent | 214 unexpected changes | High | Pause / Investigate |
When something goes wrong, you need a stop button. PAUSE AGENT stops new tasks, scheduled tasks, queued work and, where technically possible, current execution. For larger environments, STOP ALL AGENTS may eventually be appropriate as an emergency capability. The stop mechanism should sit outside the model: you don't want to ask the misbehaving agent "would you mind stopping now?" And if agents have individual identities, separate credentials, defined relationships and known permissions, you can isolate one agent, one tool, one credential, one relationship or one workflow, rather than turning off all AI.
When something does go wrong, Agent Control should help reconstruct input to agent to delegation to tool to action to consequence: what started it, which agent, which other agents, which system, which permission, which approval, what actually changed and what evidence remains. That's much more useful than "something strange happened yesterday". For important agents it should automatically maintain an Incident Card (agent, owner, emergency contact, purpose, authority, systems, credentials, connected agents, pause and credential-revocation processes, high-risk actions, logs, backup and recovery, restart approval) so you already know where to start.
The main screen should be calm. Not cybersecurity theatre, no giant flashing "THREAT LEVEL: RED". Something more like: 38 active agents, 1,284 tasks today, 1,246 verified, 12 partial, 8 incomplete, 5 blocked, 3 failed, 10 need attention. Then a "needs you" list, and the ability to drill into any agent and see its purpose, owner, authority, schedule, expected versus actual coverage, agent status, verified status, last verified success, cost and the available actions (retry, review, pause). That's the level of clarity we're aiming for.
Agent Control shouldn't try to replace your identity systems, security tools, SIEMs, monitoring, logs, cloud platforms, workflow systems, model platforms or API gateways. Its job is to create the missing layer around the agent: who is it, why is it here, what can it do, what should it be doing, what actually happened, did it work, what needs attention, and can we intervene?
The first version won't automatically discover and control every agent on every platform. Start with the Agent Register, authority profiles, permission maps, relationship maps, verification definitions, review dates, manual and imported activity, agent status, verified status, alerts and pause architecture. Then progressively connect APIs, MCP servers, agent frameworks, model platforms, workflow tools, cloud services, identity providers and monitoring systems. The control model comes first. Automation follows.
Businesses starting to deploy agents, who need visibility before agent use spreads. Businesses already running multiple agents, who need one place to understand them. AI agencies, who need a repeatable control model for client deployments. Developers, who need to understand authority and runtime behaviour. Operations teams, who need to know whether autonomous work actually happened. Security teams, who need identity, permissions, behaviour and containment. And business owners, who need the simplest answer of all: are my agents working, and is anything happening that needs me?
It isn't designed to make agents less useful. It isn't another approval layer for every tiny action. It isn't built on the assumption that every agent is dangerous. And it isn't trying to scare businesses away from autonomy. Quite the opposite. Good control enables more autonomy. If you know the boundary, the authority, the outcome and the stop mechanism, you can be more comfortable allowing agents to work independently inside that environment.
Let the agent reason, adapt, choose approaches, use approved tools, complete work and operate independently. But define where it can go, what it can touch, what consequences it can create, when it needs you, and what proves the job is done. Give your AI agents freedom to work. Not freedom to do anything.
Agent Control grew out of running agents in the real world. As the number of agents increased, so did the systems needed to track them, check them, monitor them, understand failures and work out whether tasks had actually completed. Eventually the oversight became a problem of its own. That's the problem Agent Control is intended to solve. Not theoretical rogue AI, but the practical reality of trying to run autonomous systems you can't simply assume are always right.
Agent security often begins with "what if an agent does something dangerous?" That's important. But Agent Control begins slightly earlier: how do we safely give imperfect AI useful amounts of power? Enough freedom to be valuable. Enough visibility to know what's happening. Enough verification to know whether it worked. Enough boundaries to limit consequences. Enough human control for the decisions that matter. And enough containment to stop things when they don't go to plan.
Know what your agents can do. See what they actually do. Verify that the job got done.
Agent Control is in build. Leave your email and we will let you know when it is ready. No spam, just the launch.