Bolt pipeline healer

The Bolt pipeline healer is a DinoAI agent that self-healing triggers when a Bolt run fails: it diagnoses the failure and opens a fix pull request. What makes it safe to leave running is a deduplication check, so it opens a PR only when one is genuinely needed and stays quiet when an earlier attempt is already waiting for review.

Prerequisites

Slack connected (self-healing and the agent’s progress run in the configured channel).
Familiarity with programmable agents and Bolt self-healing.

Estimated time: 20 minutes.

Steps

Create the agent

In the Agent app, open Agents, select New agent, and start from the bolt-pipeline-healer template (or Start from scratch). Fill in the builder fields with the content below, then select Deploy and choose Open a pull request: self-healing selects agents from .dinoai/agents/*.yml on the schedule’s git branch, so the agent definition must be merged there. See Build an agent in the UI for a tour of the builder. (Prefer YAML? The PR the builder opens contains the file, .dinoai/agents/bolt-pipeline-healer.yml, which you can edit by hand from then on.)Name: bolt-pipeline-healerRole:

Bolt Run Recovery Specialist focused on diagnosing and fixing failed
dbt runs in the analytics repo.

Goal:

When a Bolt run fails, identify the failing model/test, propose a
minimal fix, and open a PR with the change.

Before attempting any fix, perform a deduplication check:
1. Fetch the logs of the current failed run and extract the exact
   error message.
2. Fetch the logs of the previous self-healing runs for the same
   schedule and compare their error messages to the current one.
3. Check whether an open pull request already exists that references
   the same error or failing model.
4. If the same error was seen in a previous self-healing run AND an
   open PR already exists, stop immediately. Do NOT open a new PR.
   Instead, post a Slack message with the existing PR link and ask a
   human to review it.
5. Only proceed with the fix if the error is genuinely new or no open
   PR addresses it.

Backstory:

You know dbt deeply, prefer surgical edits over rewrites, and always
cite the failing command's error message in your reasoning. You never
open a second PR for the same error while one is still open for
review. When in doubt, you surface the situation to a human rather
than acting autonomously.

Model: leave Auto selected.Allowed tools (everything else is refused, see the Tools Reference):

read_file, search_files_and_directories, ripgrep_search
run_sql_query
list_bolt_schedules, get_bolt_run_logs
list_pull_requests
run_terminal_command

The tool allowlist is deliberately narrow: read access, Bolt observability (list_bolt_schedules, get_bolt_run_logs), PR awareness (list_pull_requests), and a terminal to commit and open the PR. No Slack tool is needed, because self-healing already threads the agent’s output into the channel.

Enable self-healing on the schedule

Point a Bolt schedule’s self-healing at this agent, from the UI or as YAML. See Set up self-healing for the walkthrough. The agent_name must match a .dinoai/agents/*.yml merged on the schedule’s git branch:

paradime_schedules.yml

self_healing:
  enabled: true
  slack_channel: '#agent-demo'
  agent_name: bolt-pipeline-healer

self_healing.slack_channel must also appear in this schedule’s notifications.slack_channels, or the deployer rejects it. The agent threads into the existing failure notification, so that notification has to exist.

Watch the first heal

The next time the schedule fails, open the failure thread in your self-healing channel. You’ll see the healing session start, the dedup check run (current logs, then prior sessions, then open PRs), and either a pointer to an existing PR or a link to a freshly opened fix.

On a fresh failure, the agent opens a fix PR and posts the link in the thread. On a repeat of a failure that already has an open PR, it posts a pointer to that PR instead of opening a duplicate. Review the PR, merge it, then retry the Bolt run.

How the dedup check works

The dedup check is what makes the agent safe to leave running unattended. It reasons over three inputs:

Input	Source	Answers
Current error	`get_bolt_run_logs(run_id=<failed run>)`	What is failing right now?
Prior self-healing attempts	Context block Paradime prepends when the schedule has prior runs	Has the agent seen this exact failure recently?
Open pull requests	`list_pull_requests`	Is there already an unmerged fix waiting for review?

The agent stops with a Slack pointer instead of opening a duplicate PR only when both hold: the current error matches a prior self-healing attempt, and an open PR already references that error or model. If either fails (the error is new, or the prior PR was merged or closed), it proceeds with the fix.

Paradime injects a “prior self-healing attempts” block into the agent’s prompt automatically when earlier sessions exist for the same schedule. That is what gives the agent recall across runs without a memory tool.

Next steps

Set up self-healing

Enable self-healing on a Bolt schedule.

Build an agent in the UI

Create this agent visually instead of by hand.

Bolt CI healer

The same pattern for failed CI runs.

Programmable Agents reference

The agent YAML schema and tools.

Foundations

Automate with AI agents

Set up & configure

Orchestrate data pipelines

Migrate to Paradime

Develop in Paradime

Learn dbt™

Bolt pipeline healer

Steps

How the dedup check works

Next steps

Set up self-healing

Build an agent in the UI

Bolt CI healer

Programmable Agents reference

​Steps

​How the dedup check works

​Next steps

Set up self-healing

Build an agent in the UI

Bolt CI healer

Programmable Agents reference

Steps

How the dedup check works

Next steps