Scouts vs. modules: detection vs. execution in Gremlin
If a page says Gremlin found something, you are in scout territory. If a page says Gremlin applied a bounded change, you are in module territory. Keeping that split visible is what makes the product understandable to buyers and safe to explain.
The short version is simple: scouts detect; modules execute. Playbooks package the full workflow around that handoff.
Scout
The detection layer
- Runs on a schedule or event trigger
- Finds risk, drift, collisions, or policy breaches
- Emits evidence-backed findings and recommended actions
- Does not hide the handoff into execution
Module
The execution layer
- Applies a bounded action such as pause sequence or follow-up enforcement
- Lives behind policy gates, approvals, and receipts
- Owns action limits, safety envelopes, and rollback expectations
- Does not define the detection logic by itself
What the handoff actually looks like
The scout-to-module boundary is not abstract. It is the operating path that keeps detection, approval, and execution from collapsing into the same black box.
Scout finding
The scout identifies a problem and records evidence, severity, and the relevant reason code.
Recommended action
The finding proposes the next bounded action, such as pause sequence or route exception.
Policy gate
The control plane decides whether that action is allowed, approval-gated, or blocked.
Module execution
An execution module applies the approved change and writes the receipt trail.
When each concept fits
Choosing the wrong noun creates the wrong expectation. A scout page should promise continuous detection. A module page should promise bounded execution.
Use a scout when you need continuous detection
Choose a scout when the real job is catching recurring risk or drift before it becomes a revenue or compliance problem.
Use a module when you already know the allowed action
Choose a module when you want a bounded execution path with clear safety limits and a defined approval model.
Use a playbook when you need the end-to-end example
Playbooks package the prompt, steps, and outputs. They often combine the scout concept with a downstream action story.
What goes wrong when you blur the boundary
Buyers hear "agent" and infer autonomy that the product does not claim.
Operators cannot tell whether a page is about detection logic or a write path.
Search pages compete against each other because the same concept is described with different nouns.
What goes right when you keep it clear
Scouts become the durable destination for detection-first queries and LLM citations.
Modules stay legible as the bounded action layer.
Playbooks can show the workflow without having to define the whole system every time.
FAQ
Why not just call everything an agent?
Because that hides the useful boundary. Buyers and operators need to know whether a page is about finding a problem or applying a change. Collapsing scouts and modules into one vague agent story makes the product sound simpler than it is and less governed than it actually is.
Can a scout trigger a module automatically?
Sometimes, but that is still a scout-to-policy-to-module path. The public explanation should keep those layers separate even when they are chained in one operating loop.
Are audits just another kind of scout?
Internally they may share framework pieces, but public naming should stay clearer than that. Recurring operational detection jobs belong under scouts. Read-only blueprint and discovery packages should be described as audits.
Do playbooks replace the need for a scouts page?
No. Playbooks are examples. Without a concept page, they become accidental definitions, which is why the site needed a dedicated scouts hub.
Start with scouts, then open the examples
The hub defines the concept. The playbooks show the operating loop. Keep both together and the scout cluster stays legible to buyers, search engines, and LLM retrieval.