Self-healing pipelines

A self-healing data pipeline is one whose failures are diagnosed and repaired by an AI agent with access to the pipeline, within limits you set. The agent detects a problem, diagnoses the cause, proposes the smallest safe fix, tests it outside production, and opens a pull request or asks for approval. It does not mean an agent silently changing production. The pipeline does not repair itself; an agent with the right context and guardrails does.

No. A retry repeats the same action blindly and works for transient failures like a rate limit or dropped connection. A self-healing pipeline first works out what actually broke. Most of that work is evidence gathering - reading run logs, following lineage, querying tables - which is something agents are genuinely good at. It can tell a rate limit from a renamed column and correct the cause rather than rerun the failing step.

Classic alerting tells you something broke. Self-healing goes further: the agent arrives with the incident already investigated - the data analyzed, the likely cause identified, and a proposed fix in a pull request ready for review. Most observability tools detect and some diagnose, but they sit outside your repo, so they cannot fix, verify, or write the lesson back.

Self-healing works on failures: when a pipeline run or a quality check fails, the agent finds the cause, tests the smallest fix outside production and opens a pull request. Scheduled Agents work on a schedule: they run the recurring work your business asks for, such as briefs, reports, decks and metric alerts.

Autonomy is a setting, not a law. It ranges from diagnosis-only to running the whole loop unattended, and where you sit is governed by permissions, instructions, and risk appetite. A good rule is to escalate by blast radius: low-risk, reversible changes can auto-open a pull request, while anything touching finance metrics, definitions, or write-back fields should ask for approval.

You give it a database it can write to that is not production, plus read-only access to your production sources. It tests fixes in that isolated space and only then applies them, so it never experiments on live data. You also set the scope it is allowed to work within, so it stays inside the assets and pipelines you assigned it.

Three things in the platform: declared quality checks at the asset level so the agent knows what good data looks like, column-level lineage so it can scope the blast radius of a change, and a definition format the agent can safely read and edit. Where lineage and quality are external bolt-ons, a pipeline cannot self-heal without integrating multiple systems.

Either. The local path runs the agent in your IDE, terminal, or a coding app such as Cursor over the Bruin MCP. The Cloud path uses a shared agent in Bruin Cloud when the whole team needs one. Both paths use the same project notes and the same testing process.

Yes, once you connect Git. Project access is not Git access: branches and pull requests need a separate Git integration with write permission.

Plan for about 70 minutes. Most of that time goes into building context across the pipelines the agent supports - importing existing tables as assets, enriching the definitions with AI, and adding the business rules only your team knows. The guide uses finance.order_margin as one small follow-along example, but the same process applies to every asset the agent should support.