InspectAutomations
Run repeatable Inspect work on schedules and product events.
Feature overview
An automation starts an Inspect session without a person writing a new prompt each time. It combines a reusable prompt, one or more triggers, optional template variables, and destinations for useful results. Every run remains an inspectable session.
Triggers
- Scheduled: recurring work such as weekday health checks.
- GitHub: pushes, status check results, and pull request comments.
- Datadog: monitor alerts and warnings.
- LaunchDarkly: flag changes.
- Sentry: issue and metric alerts.
- Slack: new messages or reactions in selected channels.
One automation can have any number of each trigger type; every trigger keeps its own configuration, enabled state, and identity, so you can pause, edit, or remove it independently. Choose the narrowest trigger that represents each real start condition.
Prompts and variables
Define one responsibility, what evidence Inspect should gather, and what a successful run produces. Template variables let operators supply values while preserving the prompt contract.
State across runs
Use automation_state when one run needs to leave a small value for a future run, such as an external resource ID, cursor, or counter. A run receives a starting-state snapshot captured when the run is created, so queued or overlapping runs do not see updates made after their creation. The run can set, delete, or increment values for future runs. State values are strings; encode small structured values as JSON strings. Keep generated output in its destination rather than copying it into state, and never store credentials or secrets.
Example: update one Notion page
A weekly status automation can create a Notion page on its first run, then save the page ID under notion_status_page_id with automation_state. Later runs use that ID to update the same page instead of creating duplicates. Tell the prompt to replace the saved ID only after it successfully creates a new page when the old one is missing or inaccessible.
Proposals and fanout
Use post_automation_proposal when an automation finds a concrete action that a person should verify before Inspect carries it out. The tool posts an Inspect-managed Slack card with Accept and Reject actions.
Fanout destinations are purpose-routed, not a broadcast list. Give every Slack channel or Team triage board a specific purpose. A run should choose the single most-specific matching destination, send nothing when no purpose matches, and post to multiple destinations only for genuinely distinct findings.
Organization administrators can create a public Slack channel directly from an automation's channel selector: enter a new channel name and select Create. For an existing private channel, paste its Slack channel link and invite the posting bot before the automation runs. If its custom agent has a dedicated Slack app, invite that bot. Otherwise, invite Inspect; inviting a custom agent's user-group handle does not give the shared Inspect bot access.
Real-life examples
Scheduled maintenance: scan a repository weekly for stale flags, then propose one verified cleanup in the owning team’s channel.
Production signal: react to a Datadog monitor or Sentry alert, gather logs and traces, and post an evidence-backed investigation to the service channel.
Feedback triage: review new customer feedback, enrich an existing issue when it matches, and propose a new task only when the request is concrete and novel.
Combine automations with agents
Select an agent under Custom agent, model & repositories when the job needs specialized instructions or access. The automation starts the work and passes in its task-specific prompt. The agent’s prompt, model, and access apply to every run.
A GitHub push automation can send a changed interface to a Design QA agent. The agent checks it against the design system at each breakpoint, then posts screenshots and a ranked list of problems.
A Datadog trigger can send a monitor alert to a Production Triage agent. The agent uses the team’s playbook to review the relevant telemetry and recent deploys, then posts its assessment to the service channel.