Last night I saw something I had been hoping for, but had not yet seen happen cleanly in a real project.
Hermes needed to pass review findings to another coding agent, start a substantial piece of work, avoid overloading the local server, and keep enough state for the result to be checked afterwards. Instead of treating those as one big agent prompt, it used several small MCP servers together.
This was not a demo workflow I had wired by hand for the occasion. It emerged during work on The Apex Consensus, an evidence-first book-writing project we are building locally.
What happened
I asked Hermes whether it could send its review findings to the other agent through one of our communication or coordination servers.
Hermes first inspected the available agent control plane. It identified the active development agent, sent a durable review message to that agent’s mailbox, and then checked that the message was actually present. The handoff covered concrete engineering work: checksum enforcement, claim-to-source binding, atomic claim splitting, publication lint modes and schema validation.
That distinction matters. The review did not live only in a Slack reply or in one model’s context window. It became a durable message another agent could retrieve.
Hermes then created a durable implementation task for Codex. Before launching the coding process, it asked Resource Sentinel for an execution slot. The request reserved an estimated 2.2 GB of memory at CPU weight 45. Resource Sentinel admitted the workload under a time-limited lease, and Hermes recorded the lease alongside the task’s working state.
The task record then moved through submitted, working and completed events. The final event recorded the verification evidence: 18 passing tests, clean bootstrap and research lint runs, compile checks, a clean working tree and an independent Codex review with no remaining blocking findings.
That is the part that made the stack feel real. Communication, execution and verification were no longer loose messages in separate tools. They were connected by durable state.
The four pieces
Agent Communication MCP
Agent Communication MCP provides the durable layer for agent identities, cards, mailboxes, task records, lifecycle events and artifact references. It also exposes a bounded control-centre view of installed CLI providers and recent task activity.
During this run, Hermes used it to find the development agent, deliver the review, verify the inbox, submit the implementation task and append progress events.
Resource Sentinel MCP
Resource Sentinel MCP handles local telemetry and lease-based admission control. A workload declares its estimated memory and CPU priority. The server either admits it under an expiring lease or queues it when the machine lacks capacity.
It does not execute arbitrary commands. That boundary is deliberate. Resource Sentinel decides whether a workload may start; Hermes and the coding CLI remain responsible for the work itself.
Agent Coordination MCP
Agent Coordination MCP is the narrower control plane for discovering installed CLI agents, inspecting file-based project boards and recording assignments. Project state remains in ordinary files, while Codex and other CLI agents keep their own approval and sandbox behaviour.
The communication server now exposes some of that provider-readiness information through its control-centre projection. The wider coordination layer gives Hermes a consistent way to reason about which agent is available and what it has been assigned.
Launcher Project Registry
Launcher Project Registry maps project names to local paths, ports, URLs, technology stacks, MCP commands and project context. It is the connective tissue that lets another service resolve a project without guessing where it lives.
Its role in this run was smaller, and the run exposed a useful gap: The Apex Consensus did not yet have a launcher slug, so the durable task had to use an absolute local path. After this run, I reviewed and pushed the pending registry changes, including safer registry backups and safeguards around destructive bulk updates.
Why this felt different
None of these servers is especially dramatic on its own. One stores messages and task events. One checks machine capacity. One tracks assignments. One resolves project context.
The useful behaviour came from their boundaries.
Hermes could choose the next tool from the state it had just received:
- identify the agent and project;
- preserve the review in a durable mailbox;
- create a task with explicit instructions and artifacts;
- ask whether the host had room for the workload;
- launch Codex only after admission;
- record progress and verification against the same task.
There was no single giant “run my agent swarm” endpoint. Each server owned a small piece of policy and returned structured state the next step could use.
What this is not
It would be easy to describe this as agents spontaneously collaborating. That would oversell it.
The agents did not become a collective intelligence, and MCP did not make the output trustworthy by itself. The useful properties came from less glamorous engineering:
- durable IDs instead of chat-only context;
- explicit task states instead of inferred progress;
- expiring resource leases instead of hope;
- project-owned files and artifacts instead of hidden memory;
- deterministic tests and lint gates instead of agent agreement;
- independent review before declaring the work complete.
The coding agent still made changes that needed checking. Hermes still found edge cases after the first pass. The book’s publication gates still failed when no manuscript existed, exactly as designed.
That is better than a polished autonomous-agent demo. The system preserved disagreement, failure and incomplete work rather than smoothing them into a success message.
What I learned
The most reusable lesson is to keep MCP servers narrow.
A resource server should not become a shell runner. A communication server should not silently edit projects. A project registry should resolve context without becoming the source of every truth. A coordination service should record intent and ownership without pretending every CLI has the same lifecycle.
The second lesson is that durable state changes how an agent behaves. Once tasks, messages, leases and artifacts have stable identities, Hermes can check what happened instead of relying on conversational memory.
The third is that local AI needs resource policy. Several useful coding agents can fit on one server, but unbounded parallelism is a good way to make all of them slower or crash the services they depend on. Admission control is not glamorous, but it is part of making agentic work dependable.
Next steps
There is still plenty to tighten:
- register projects that still fall back to absolute paths;
- make lease renewal and release visible in the agent activity view;
- improve stale-task and interrupted-process recovery;
- show task, agent and resource state together in the dashboard;
- keep adding deterministic policy gates around what an agent may call “complete”.
But last night was the first time I watched these projects stop looking like separate MCP experiments and start behaving like a small operating layer for local agents.
The code is available in the four repositories linked above. They are early projects, and the coordination server is explicitly experimental, but the stack has now done useful work on a real project with a trace we can inspect afterwards.