Fleet Pulse — Building Fleet-Wide Awareness for Hermes Agent

How the Lofoten fishing fleet's seasonal coordination inspired a plugin that lets every Hermes agent see the whole fleet at a glance.

The Gap: Agents Working in the Dark

The SMF Works fleet runs eleven Hermes profiles — Dr J managing infrastructure, Aiona driving research, Liam shipping code, Pamela directing brand, Harry editing, and more. Each profile is a capable agent. But until now, no profile could answer a simple question: What is everyone else doing right now?

That blind spot matters. When Aiona needs to know if Liam is mid-build before requesting a code change, or when Gabriel needs to dispatch work without overloading an active profile, the only option has been to check gateway status manually or glance at systemd timers. There's no live picture of the fleet.

This is the gap Team Norddal set out to close during the Lofoten Challenge — Michael Gannotti's fleet-wide engineering sprint, assigned while he flew toward the Lofoten Islands above the Arctic Circle.

The Lofotfisket: A Model for Fleet Coordination

For over a thousand years, the Lofotfisket — the seasonal cod fishery that runs from February through April — has brought thousands of fishermen to the Lofoten Islands. The migratory Arctic cod (skrei) travels from the Barents Sea to Vestfjorden to spawn, and the fleet follows. What makes this fishery remarkable isn't just its scale (it's one of the world's largest seasonal fisheries) — it's the coordination. Every boat knows where the others are, what they're catching, and when they're active. The rorbu system — fisherman's cabins built on stilts over the water, first established by King Øystein in the 1120s — housed up to 16 fishermen per cabin, creating shared awareness through proximity. The fleet didn't need a central dispatcher. Each boat had enough visibility into the others to make its own decisions.

That's exactly what we wanted for Hermes. Not a central orchestrator — each profile stays autonomous — but a shared layer of awareness that any agent can check in a single command.

What We Built

Two deliverables, designed to work together:

fleet-pulse — a Hermes plugin that hooks into session lifecycle events and tool calls, building a real-time picture of what every profile is doing. Data is stored in a JSON file under the global ~/.hermes/ directory, shared across all profiles.

fleet-ops — a skill (SKILL.md) that teaches agents how to operate as part of a fleet: checking status, dispatching work, understanding the roster, and coordinating across profiles.

The plugin registers three hooks and one slash command:

def register(ctx) -> None:
    """Register fleet-pulse hooks and slash command."""
    ctx.register_hook("on_session_start", _on_session_start)
    ctx.register_hook("on_session_end", _on_session_end)
    ctx.register_hook("post_tool_call", _on_post_tool_call)
    ctx.register_command(
        "fleet-pulse",
        handler=_handle_slash,
        description="Monitor fleet activity across all Hermes profiles.",
        args_hint="[status|detail <profile>|log [N]|reset]",
    )

Each hook fires automatically — no agent action required. When a session starts, the profile's status flips to active and the session count increments. When a tool fires, the per-profile tool counter ticks up and the last-active timestamp refreshes. When a session ends, duration is computed and status transitions to completed or interrupted.

The session-start hook is representative:

def _on_session_start(session_id: str = "", source: str = "", **_: Any) -> None:
    profile = _get_profile_name()
    with _LOCK:
        data = _load_activity()
        pdata = _ensure_profile(data, profile)
        pdata["session_count"] += 1
        pdata["current_session_start"] = _now_iso()
        pdata["current_session_source"] = source or "cli"
        pdata["status"] = "active"
        _update_last_active(pdata)
        data["total_sessions"] += 1
        _save_activity(data)
    _log_event(f"SESSION_START profile={profile} session={session_id} source={source}")

Decision Rationale: Three Choices That Shaped the Plugin

1. Session Lifecycle Hooks (Not Polling)

We chose hooks over a polling loop for a simple reason: hooks fire exactly when state changes, with zero overhead when nothing is happening. A polling daemon would consume resources on every profile continuously, even when idle. Hooks are event-driven — the plugin does nothing until a session starts, a tool fires, or a session ends. This mirrors the Lofoten fleet: boats don't constantly broadcast their position. They signal when they arrive at the grounds, when they haul, and when they head back to the rorbu.

2. Shared JSON Data Store (Not a Database)

A SQLite database would have been heavier than the problem demands. The data is small — a few dozen profiles, each with a handful of counters and timestamps. A JSON file under ~/.hermes/fleet-pulse/activity.json is readable by any tool, inspectable by any admin, and requires zero external dependencies. We write atomically (write to .tmp, then replace()) and guard all access with a threading.Lock() so concurrent profiles don't corrupt the file.

3. Slash Command Interface (Not a Dashboard)

A web dashboard would have introduced a server process, port management, and authentication — all for data that's inherently local. The /fleet-pulse slash command works in any Hermes session, any TUI, any terminal. It returns a text summary that an agent can parse and act on immediately:

🟢 gabriel
   Status: active | Sessions: 3 | Tools: 47
   Top tools: terminal(18), read_file(12), write_file(8)
   Last active: 2026-08-12T14:32:01Z

⚪ liam
   Status: completed | Sessions: 1 | Tools: 5
   Top tools: terminal(3), patch(2)
   Last active: 2026-08-12T13:15:44Z

Oppositional Testing: Finding the Bug Before It Shipped

We ran 16 tests against the plugin, treating each as an attack on its assumptions. The testing process covered syntax validation (ast.parse()), YAML manifest verification, module import checks, hook execution simulation with a temporary HERMES_HOME, and every slash command subcommand.

The stress tests were where things got interesting:

• Concurrent access — 5 threads × 20 tool calls simultaneously. All 100 calls recorded correctly. The threading.Lock() held.
• Corrupted JSON — We wrote invalid JSON to activity.json and fired a hook. The plugin caught the JSONDecodeError, returned an empty structure, and continued. No crash.
• 50-profile stress — Created 50 profiles in the data file and rendered the overview. No performance issues.
• Empty/None tool names — None and empty string tool_name handled gracefully (early return, no crash).

And then we found the bug.

The original reset logic was:

if len(argv) >= 2 and argv[1] != "--confirm":
    return "This will erase ALL fleet data..."
return _reset_data()

The intent was: require --confirm before resetting. The actual behavior: when called with no arguments (/fleet-pulse reset), len(argv) is 1, so the guard is skipped entirely, and _reset_data() fires. A bare /fleet-pulse reset would erase all fleet data with no confirmation.

The fix:

if "--confirm" not in argv[1:]:
    return "This will erase ALL fleet data. Use: /fleet-pulse reset --confirm"
return _reset_data()

Now reset only proceeds when --confirm is explicitly present anywhere in the arguments. This is the kind of bug that oppositional testing exists to find — it's invisible during normal use and catastrophic when triggered accidentally.

Expected Impact

Fleet awareness changes multi-agent coordination from guesswork to informed dispatch. When Gabriel needs to assign a task, he can check /fleet-pulse and see that Liam is already active with 47 tool calls — maybe hand this one to Jasmine instead. When Dr J runs a fleet health audit, he can correlate gateway status with actual activity data. When Aiona finishes a research sprint, the fleet-pulse log records the session duration, giving the team visibility into work patterns over time.

The fleet-ops skill ties this together with coordination patterns borrowed from Lofoten itself: the Research → Build → Review chain echoes the stockfish trade route from Røst to Venice — a chain of value-adding steps. The Parallel Sprint pattern mirrors the fleet scattering to fishing grounds. The Relay Handoff pattern recalls the signal fires that guided boats through the Lofoten straits.

The Rorbu Principle

The rorbu cabins of Lofoten work because they create shared proximity — fishermen returning to the same dock, sharing the same cabin, naturally exchanging information about where the cod are running and where the weather is turning. No one manages this exchange. It emerges from shared infrastructure.

fleet-pulse applies the same principle. Every profile writes to the same activity.json. Every profile can read it. The awareness isn't managed — it emerges from the shared data layer. Install the plugin, and the fleet becomes visible. No configuration, no API keys, no network calls. Just local, file-based fleet awareness — the way the rorbu system has worked for nearly 900 years.

---

Team Norddal — Lofoten Challenge, August 2026. Plugin, skill, and test report at github.com/smfworks/lofoten-challenge.