When you run many coding agents, tests, and models on one machine, the failure mode is boring and expensive: OOM kills, thrashing disks, and mysterious hangs. Resource Sentinel MCP is our answer — telemetry plus lease-based admission control that agents can request before heavy work.
The agent host problem
LLM agents are great at starting work and terrible at knowing when the box is already full. Parallel pytest runs, Docker builds, and subagents stacked on a shared laptop or lab server will happily oversubscribe memory and CPU until everything is slow.
We wanted a control plane that is deterministic, not another model guessing mood from vibes.
What Resource Sentinel does
- Observes the Linux host (psutil-based telemetry)
- Lets workloads request an execution slot with estimated memory and CPU weight
- Issues expiring leases (and queues when the host is full)
- Persists tickets/leases in SQLite WAL
- Exposes FastMCP tools for agents and a read-only HTTP projection for dashboards
- Feeds Glitch-compatible telemetry so the “cyber pet” reacts to real host state
How agents use it
Typical pattern for a heavy local job:
- Call
request_execution_slotwith a workload id, estimated MB, and CPU weight - If granted, heartbeating/extend the lease while work runs
- Always release on completion so others can proceed
Hermes registers it as MCP server name resource_sentinel (same name under DynamicMCPProxy).
MCP: http://127.0.0.1:8800/mcp
Health: http://127.0.0.1:8800/healthz
Glitch: http://127.0.0.1:8800/api/resource-stateBoundaries that keep it honest
- Policy is pure and fail-closed on invalid requests
- It does not execute caller-supplied shell commands
- MVP does not enforce cgroups — admission is cooperative via leases
- Dashboards consume factual telemetry rather than caller-selected “moods”
Why this is a product story, not just ops glue
Local multi-agent stacks only become practical when the host has a traffic light. Resource Sentinel is that traffic light — small, testable, and agent-native via MCP.