OpenClaw dbt Data Quality Assistant

This hub collects the garden notes extracted from the OpenClaw + dbt Data Quality Assistant article. The article designs a 24/7 agent that runs dbt tests overnight, cross-references documentation, assesses severity, and delivers a prioritized morning summary to Slack. Each building block is documented as a separate note that can be implemented independently.

If you’re new to OpenClaw for data work, start with OpenClaw for dbt Monitoring for the high-level concept. If you haven’t set up the cron-based monitoring foundation yet, read through the OpenClaw Pipeline Monitoring hub first — this article assumes you’re comfortable with OpenClaw’s scheduler and skill system.

Building Blocks

1. dbt Test Output Parsing for Automated Monitoring The foundation. How to extract structured information from raw dbt test output — distinguishing FAIL vs ERROR vs WARN, capturing sample failing rows with --store-failures, pulling model and column context, and handling partial runs where some tests error and others pass. This is the input layer that everything else depends on.

2. dbt Test Failure Severity Framework A four-tier prioritization system (Critical / High / Medium / Low) for ranking test failures by actual business impact. Covers the base tier criteria, how downstream dependent count adjusts severity, and how to encode these rules explicitly enough for an AI agent to apply them consistently. Also covers how test type (uniqueness vs. freshness vs. singular) should modify default severity assignments.

3. OpenClaw Persistent Memory for dbt Context How to load dbt project documentation, downstream dependency graphs, and investigation history into the agent’s persistent memory so that failure reports include business context rather than just technical output. Covers the format for memory documents, pre-processing manifest.json into a compact dependency summary, and the failure history tracking pattern that lets the agent distinguish first-occurrence failures from recurring patterns.

4. dbt Quality Morning Summary Pattern The two-cycle design: a daily cycle for incident detection (midnight test run, 7 AM delivery) and a weekly cycle for pattern detection (Friday afternoon digest). Includes the summary template format, Slack threading pattern for tiered detail, follow-up capability via Slack replies, and the weekly digest structure that surfaces coverage gaps and resolution metrics.

5. AI Agent Data Quality: What Works Today vs. What’s Aspirational An honest maturity assessment. Which capabilities are production-ready (cron execution, output parsing, explicit severity rules), which require significant work but are achievable (documentation cross-referencing, manifest-based impact analysis, failure history tracking), and which are still too unreliable to depend on (automatic test generation, self-healing pipelines, anomaly detection without explicit tests). Includes a comparison against purpose-built tools like Elementary and a layered architecture recommendation.

The Architecture

Everything in the daily cycle follows the same flow:

Midnight cron → dbt test --target prod --store-failures
              → Parse output (FAIL/ERROR/WARN per test)
              → Look up documentation context (persistent memory)
              → Assess severity (4-tier framework + downstream weight)
              → Check failure history (first occurrence vs. recurring)
              → Compose prioritized summary
              → Deliver to Slack at 7 AM (main message + threads per critical failure)

The weekly digest runs separately on Friday afternoons:

Friday cron → Aggregate 7-day failure history
            → Identify recurring failures (3+ occurrences)
            → Check manifest for models with zero test coverage
            → Calculate resolution metrics
            → Deliver weekly digest to same Slack channel

Each building block is independently useful. A good output parser with no severity framework still produces more useful output than raw test results. A severity framework with no persistent memory still helps you triage faster than a flat list. Build incrementally, starting with the foundation cron job from OpenClaw Pipeline Monitoring, and add layers as you confirm each one is working reliably.

Where This Sits in the Observability Stack

An AI agent for dbt quality monitoring is not a replacement for dedicated observability tools — it’s a layer on top of them. Elementary, Monte Carlo, and dbt Cloud’s built-in alerting handle structured storage, statistical anomaly detection, and consistent historical tracking better than an agent can.

The agent layer adds: contextual summaries in plain language with business implications, natural language follow-up via Slack, cross-system correlation, and the flexibility to monitor any system through a shell command. The right combination depends on your team size and existing tooling — the maturity assessment note covers the decision logic.

For the broader question of which observability approach fits your team, see the Data Observability Build vs. Buy hub.

Series Context

This hub is part of the “OpenClaw for Analytics Engineers” series. The series covers:

• OpenClaw for Data People — the overview
• Pipeline Monitoring — the foundational tutorial (start here if you’re new)
• dbt Data Quality Assistant — this article