Building Henry: A Secure, Cost-Governed Multi-Agent Control Plane

At Atlas Atlantic, we've been quietly building something we think a lot of teams will eventually need: A local-first, security-hardened multi-agent orchestrator that can run a stable of sub-agents without turning into an expensive, unpredictable, self-triggering machine. We call it Henry.

Henry is built on the Moltbot/OpenClaw approach: an agentic 'control plane' that routes tasks, calls tools, coordinates sub-agents, and produces usable work. The problem with systems like this isn't whether they can be smart. It's whether they can be trusted.

So our work has been less about 'making Henry clever' and more about building a system where: powerful actions can't happen accidentally, costs can't spiral silently, concurrency doesn't create weird edge cases, and every decision leaves a trace. This is the story of what we've been doing, and the strategy behind it.

Most agent experiments start as a prototype: a prompt, a tool loop, a few integrations. Then they become real. Then they get connected to real services. Then the cost graphs spike, and the security posture becomes… vibes.

We decided to invert that. Henry's design assumes: it will eventually touch privileged systems, it will inevitably be asked to do risky things, and it will absolutely try to do too much if you let it.

So we designed the guardrails as first-class architecture, not a bolt-on.

The most important shift we made was moving away from 'Henry is allowed' toward 'Henry is allowed only if it holds a specific capability.'

The backbone is a capability-token model: Capability-based JWTs (scoped permissions, time-bounded), Process binding (tokens are bound to the process identity—PID + command hash—so you can't steal a token and replay it elsewhere), No token, no action as a default rule.

This is the difference between 'the agent is authenticated' and 'the agent can do this one thing, right now, from this exact process.' That framing is everything.

We also assumed something simple: if Henry can do anything powerful, it must be able to ask permission like a responsible operator. So we designed a two-step approval workflow:

Henry requests approval for a dangerous action (explicit, human-visible). If approved, it receives a signed one-time execution token (short expiry—on the order of minutes) that authorizes only that action.

Key point: the safety system is the ultimate authority and cannot be bypassed.

This isn't about slowing the agent down. It's about preventing the nightmare scenario where a 'helpful' agent: deletes something, emails someone, changes production settings, runs a destructive script, or exfiltrates sensitive data… all because it misread a prompt or got stuck in a loop.

Multi-agent systems create concurrency problems by default: two sub-agents updating the same resource, retries that re-run side effects, duplicate events, tool calls that get replayed.

So we added structural protections: Optimistic locking + versioning to prevent 'last write wins' corruption, WebSocket event streaming with sequence numbers to support deduplication, replay protection, and backpressure, A standardized, safe error model (no leaky stack traces; predictable failure behavior), Rate limiting + circuit breakers so one runaway lane can't melt the system.

In human terms: Henry shouldn't be able to accidentally DoS itself, spam tools, or create inconsistent state just because it's juggling tasks.

Agents don't 'hack you' by getting clever. They hack you by passing untrusted strings into powerful tools. So we treat tool inputs like hostile terrain:

Strict schema validation (Pydantic-style contracts), Sanitization and normalization, Clear separation between 'user text' and 'execution parameters', Safe defaults everywhere.

If the input doesn't match the contract, the tool call doesn't happen. Period.

The second major risk with agents is cost. They don't just get expensive because models cost money. They get expensive because agent loops create unbounded behavior: re-checking the same files, re-planning repeatedly, escalating models unnecessarily, outputting long 'status reports' that don't add value.

So we built cost controls into the system itself: enforced budgets/quotas, kill switches, and routing strategies that start cheap and escalate only when needed (e.g., local → lightweight cloud → stronger cloud, with explicit rules).

We also experimented with mandatory cost transparency, so every response can report: model used, token counts, estimated cost, cumulative session cost.

Even when we later decide to simplify how much of that is shown to humans, the principle stays: no silent spending.

And just as importantly: we've been pushing hard on 'anti-loop discipline': no repetitive planning, no redoing work unless there's evidence the previous attempt failed, no long agentic runs without checkpoints.

If Henry can't keep itself honest, it can't scale.

Most complex systems become insecure during development because they're 'partially migrated.' Henry's roadmap is structured so we don't end up with an in-between monster.

We laid out a phased plan with explicit 'exit gates' so we can verify: the system is safe before moving on.

Phase 0: critical fixes first (auth, validation, rate limiting). Then approvals, event streaming, safety integration, and documentation. Each phase has explicit verification gates.

This seems boring until you've lived through a real incident caused by an 'intermediate' system that was never meant to ship, but did.

When these pieces work together, Henry becomes less like a chatbot and more like a controlled operating environment for agent work:

Sub-agents can do useful tasks, but only inside strict permission boundaries, with observable execution, deterministic approvals for risky steps, and cost containment as a first-class constraint.

That's the difference between 'an agent demo' and 'an agent you'd let near real systems.'

We're heading toward a world where: everyone has agents, those agents can run tools, and the big question isn't capability—it's governance.

The winners won't just have the smartest models. They'll have the best control planes: security primitives, permissioning, auditability, cost control, and failure-safe defaults.

Henry is our attempt to build that foundation locally-first, with a bias toward pragmatism and safety.

Next steps are about making the system operationally elegant: tightening routing and escalation rules, refining the approval UX so it's fast but safe, expanding invariants and adversarial tests, and mapping the right 'skills' and responsibilities across a larger roster of sub-agents without creating chaos.

The goal is not just more agents. It's more outcomes, with less risk.

If you're building agentic systems and you're feeling the tension between speed and safety, we'd love to compare notes. The future of reliable AI systems is control planes that work. Henry is ours. What's yours?