Footprint Ladder#
Every new capability should climb from the least footprint that still works.
The rungs#
- Extend existing code — variation of something that exists; zero new surface
- CLI command + skill — express setup/ops as
hermes <subcommand>+ a skill that teaches the agent; default for many workflows - Service-gated tool (
check_fn) — structured tool that appears only when a prerequisite is configured (process/profile reachability — not “who is watching”) - Plugin — third-party / niche / user-specific;
~/.hermes/plugins/or pip entry points - MCP server (catalog) — tool-shaped but not core-fundamental; reusable across MCP hosts
- New core tool — last resort: fundamental, broadly useful, unreachable via terminal + file / skill / MCP
Why the order exists#
Core tool schemas ride (nearly) every API call. Skills and plugins keep that waist thin while still shipping power at the edges — matching Design philosophy.
Session vs process gates#
| Question | Right mechanism |
|---|---|
| Is Home Assistant configured? | check_fn / toolset enablement |
| Is a GUI session watching? | Named toolset from session platform — not HERMES_DESKTOP alone |
| Is this only for one user’s niche API? | Plugin |
Decision drill (preview)#
Practice fully in Footprint decision drill. Quick examples:
| Idea | Likely rung |
|---|---|
| Document a deploy checklist the agent should follow | Skill |
| Wrap a private internal HTTP API as a tool | Plugin tool |
| Add WhatsApp as a chat surface | Platform adapter (edge), not a core tool |
Universal read_file-class primitive | Already core — extend carefully |
Next#
Further reading#
- Root
AGENTS.md§ Footprint Ladder website/docs/developer-guide/adding-tools.mdplugins/AGENTS.md