Using the library
Console ships the agents below. They appear in the agent list and the workflow agent picker alongside anything your organization writes. They’re also the best available examples of the format — if you’re about to write an agent, open one first and read how its frontmatter and instructions are put together.Scanning
The vulnerability scanners share one approach: map the repository’s security conventions, hunt for places the implementation diverges from that intent, then confirm candidates through analysis. They differ only in how broadly they hunt and how deeply they confirm.
The caps are deliberate. A scanner that returns everything it half-suspects is noise; these stop at a
defined budget so the results stay reviewable.
Detections
These two are the ends of a loop worth understanding:
detection-author turns a one-time discovery into a
permanent rule, and detections-runner is what applies every rule you’ve accumulated from then on.
Patching
Add it as its own step after any agent that produces findings —
detections-runner, a vulnerability
scanner, or one of your own. It consumes findings grouped by detection and file
by default, so it runs once per (detection, file) pair rather than once per individual match.
Patch generation used to be a setting on
detections-runner itself. It’s its own step now — if your
workflow used the old setting, Console already added patch-generator as a step for you.Agents spawned by other agents
These exist in the library but are normally driven by another agent rather than added directly as workflow steps:
You can name one as a workflow step, but they expect a briefing their usual parent provides, so they work
best left to it.
Common chains
Next steps
Write your own
Extend or shadow any of these.
Build a workflow
Put a chain to work.