Hive mind
The hive mind is what makes Puck a swarm rather than a collection of independent agents. When an investigation finds an indicator on multiple hosts, the brain correlates the pattern, validates it isn’t noise, and pushes a lead — a small targeted investigation — to every agent in the fleet.
Why it exists
A single agent running a plan and posting results is useful. A fleet where one agent’s discovery changes what every other agent looks for in real time is qualitatively different.
Without the hive mind, each investigation would be self-contained. You’d find a suspicious binary on host A, file a report, and separately discover the same binary on hosts B and C during unrelated investigations weeks later. The hive mind connects those dots automatically: when the investigation completes and the brain sees the binary on two or more hosts, it generates a lead and pushes it to the rest of the fleet within minutes.
This is how Puck transitions from “point-in-time investigation” to “ambient awareness.”
How it works
flowchart LR INV[Investigation\ncomplete] --> CORR[Fleet correlator\nfinds shared indicators] CORR -->|≥2 agents, baseline-filtered| LLM[LLM assessment\nfast tier] LLM -->|significant, confidence > 0.5| PROP[Lead propagator] PROP -->|disable_outbound_leads check| LEAD[HiveMindLead\nTTL 24h] LEAD --> A1[Agent 1\npoll every 10s] LEAD --> A2[Agent 2] LEAD --> AN[Agent N] A1 -->|micro-plan execution| RES[Results back\nto investigation]Correlation: After an investigation reaches 100% completion, the brain’s FleetCorrelator scans all stored results for that investigation. It extracts indicators — process names, file hashes, network IPs, file paths — and finds any that appear on two or more agents. Indicators that appear in the fleet baseline (common across the environment) are filtered out so you don’t get leads for launchd or svchost.
LLM validation: Each candidate correlation goes through a fast-tier LLM assessment. The LLM is asked whether this shared indicator is security-significant. Only correlations where the LLM says yes and the confidence exceeds 0.5 become leads. This prevents noisy or benign shared indicators (a common system binary, a shared log path) from generating fleet-wide leads.
Propagation: The LeadPropagator turns each significant correlation into a HiveMindLead. It generates a micro-plan — two to four commands — to check whether the indicator is present on any given endpoint. The lead carries a 24-hour TTL. Priority is set by correlation confidence: above 0.8 → high, above 0.6 → medium, otherwise low.
Polling and execution: Agents poll for leads every 10 seconds. The brain deduplicates lead delivery per agent and never sends a lead back to the agent that originally surfaced the indicator — there’s no point checking the source. Agents run the micro-plan through the same plan runner (and the same whitelist validation) as any other plan, then post results back to the originating investigation.
When you’d touch it
The hive mind is automatic. The main operational lever is the disable_outbound_leads tag policy field.
Set disable_outbound_leads: true on any label worn by agents you don’t want to act as lead sources. The canonical use case is CI runners: ephemeral test boxes frequently have test fixtures, build artifacts, and synthetic credentials that would generate spurious leads if allowed to propagate. Labelling them ci-runner and setting disable_outbound_leads on that policy means their findings stay local.
Note that this only suppresses outbound propagation — the tagged agent still receives and executes leads from other agents in the fleet.
The Hive Mind console page shows the real-time lead feed: which agents sourced correlations, which indicators propagated, and which agents executed the resulting micro-plans.