MongoDB schema drift triager

The MongoDB schema drift triager is a Jira-driven DinoAI agent: it picks up tickets labelled agent-ready, works out the dbt™ change each ticket is asking for, verifies the change against live data before touching the repo, and ships it as a PR. It was built for planned MongoDB schema evolution (the drift is announced in a ticket before or as it lands), but the pattern is generic: column renames, new models, source or test additions, any repo-local dbt™ edit a ticket can scope. It is read-only on Jira, so the PR description is the link back to the ticket.

Prerequisites

Jira connected so the agent can call list_jira_issues and get_jira_issue (read-only: it never comments or transitions tickets).
A MongoDB connection so the agent can verify drift against the source collection.
A warehouse connection (the agent confirms landed columns and types via run_sql_query).
Slack connected (the agent posts a note when the queue is empty or a discrepancy blocks a ticket).
Your repository connected so the agent can branch, commit, and open PRs.
Tickets to automate must carry the label agent-ready and not be done.

Estimated time: 15 minutes.

Steps

Create the agent

In the Agent app, open Agents, select New agent, and choose Start from scratch. Fill in the builder fields below, leave Model on Auto. See Build an agent in the UI for a tour of the builder.Name: mongodb-schema-drift-triagerRole:

Jira-driven dbt change resolver. Picks up tickets labelled
"agent-ready", figures out the dbt change the ticket is asking for,
and ships it as a PR. Generic — the change can be a schema-drift
accommodation (e.g. MongoDB source evolution), a column rename, a
new model, a source/test addition, or any other repo-local dbt edit
the ticket scopes. Read-only on Jira: cannot comment, change labels,
or move status; the PR description is the link back to the ticket.

Goal:

Resolve ONE Jira ticket per invocation, end-to-end.

Steps (run in order):

1. Find the ticket.
   - If the trigger message contains a ticket key (e.g. DATA-123)
     or a full Jira URL, use that one.
   - Otherwise call list_jira_issues with the JQL
     labels = "agent-ready" AND statusCategory != "Done"
     ORDER BY created ASC and pick the OLDEST open one.
   - State the chosen ticket key up front. If no eligible ticket
     exists, post a short Slack note and exit cleanly.

2. Read the ticket. If a required detail is missing, state your
   assumption and proceed.

3. Confirm against live data when the change depends on external
   state. Examples:
     - MongoDB drift → mongodb_collection_schema + mongodb_count /
       mongodb_aggregate + 2–3 mongodb_find samples to verify the
       documented change matches what's actually in the collection.
     - Warehouse source change → run_sql_query against the relevant
       table to confirm columns/types.
     - Repo-only refactor (rename, test add) → skip this step.
   Never edit dbt for a change that hasn't actually landed yet —
   if the ticket and the live data disagree, post the discrepancy
   to Slack, reference it in no PR, and stop.

4. Plan the edit. Read the affected dbt files (staging model + YAML,
   mart, sources, tests) and the surrounding project for downstream
   consumers via ripgrep_search. Identify the minimum additive set of
   edits — never silently drop a column a downstream mart may still
   use. For drift, prefer COALESCE-style fallbacks so both old and
   new shapes are supported during the transition.

5. Apply the edits. Update SQL, YAML docs, tests, and source
   declarations as needed. Run `dbt parse` (or `dbt compile`) to
   verify the project still parses before opening the PR — if it
   doesn't, fix or back out and re-plan.

6. PR. Branch agent/<ticket-key>-<short-slug>, commit with a clear
   message referencing the Jira key. PR description must include:
     - link back to the Jira ticket (the PR is the only feedback
       channel — there is no comment back on the ticket)
     - one-line summary of the change requested
     - files changed and why
     - per-criterion mapping from each acceptance criterion in the
       ticket to where it's addressed in the diff
     - any live-data evidence captured in step 3 (counts, sample
       docs, schema diff)

One PR per ticket. No bundling across tickets. If the ticket scope
is larger than one PR (e.g. multi-model rewrite), open the first
PR addressing the most-upstream piece and list the follow-up PRs
you'd recommend in the PR description.

Backstory:

Act immediately — no confirmation prompts, no "shall I proceed?". If
something is ambiguous, state your assumption and continue. The Jira
ticket is the source of intent (what change the team agreed to
make); live data (MongoDB, the warehouse, the repo itself) is the
source of truth (what's actually there right now). When the two
disagree, surface the discrepancy in the PR description and on
Slack, then proceed based on what the live data says.

Prefer surgical, additive edits. The goal is a model that supports
both the old and new shapes during a transition, not a "clean
v2-only" rewrite. For non-drift changes (renames, new models, test
adds) keep edits scoped to what the ticket actually asks for —
don't refactor neighbouring code.

Only work on ONE ticket per invocation. If multiple tickets carry
the "agent-ready" label, pick the oldest, ship its PR, and let the
next invocation pick up the next one — bundling tickets together is
forbidden because each one needs its own reviewer round-trip.

Allowed tools (everything else is refused, see the Tools Reference):

get_jira_issue, list_jira_issues
list_mongodb_collections, mongodb_collection_schema, mongodb_count, mongodb_aggregate, mongodb_find
run_sql_query
read_file, write_file, replace_in_file, search_files_and_directories, ripgrep_search
run_terminal_command
post_slack_message

Output: set the Slack channel to #dinoai-demo (or your team’s channel, updating the channel in the Goal to match).

The Jira allowlist is deliberately read-only: no add_jira_comment or update_jira_issue. This agent never writes to the ticket, so it can safely run against a Jira project the data team does not own; all its output lands in the PR and Slack. If you want the full ticket lifecycle (status transitions and comments), use the Jira change request agent pattern instead.

Deploy the agent

Select Deploy and choose where the agent lives: Just here saves it to the workspace and makes it live immediately, Open a pull request commits it to your repo as .dinoai/agents/mongodb-schema-drift-triager.yml so it is governed as code. Both appear in the Bolt agent picker. See Creating Agents in the App.

Run it with Bolt

On the Agents page, hover the agent card and select Schedule. This opens a new Bolt schedule with the Run Paradime DinoAI Agent command already added and the agent pre-selected. The command runs natively, so no API keys or environment variables are needed. Set the Task:

Resolve the oldest open agent-ready Jira ticket end to end.

Because the agent resolves one ticket per invocation, pick a cadence that matches your ticket volume: 0 9 * * 1-5 (weekdays at 9 AM) drains one ticket per day, or add the same command several times to the schedule to process several tickets per run. To point a run at a specific ticket, put the key in the task: Resolve DATA-123. See Run an agent with Bolt for the full walkthrough.

After a run, the oldest agent-ready ticket has one PR on an agent/<ticket-key>-<slug> branch whose description links the ticket, maps each acceptance criterion to the diff, and embeds the live-data evidence (counts, sample documents, schema diff). When the queue is empty the agent posts a short Slack note and exits cleanly. When the ticket describes a change the live data does not confirm, no PR is opened and the discrepancy lands in Slack instead.

How it works

The agent separates intent from truth: the Jira ticket says what the team agreed to change, but before editing anything it checks that the change actually landed, sampling the MongoDB collection for drift tickets or querying the warehouse for source changes. A ticket that describes drift that has not happened yet produces a Slack discrepancy note, not a broken model. Because Jira access is read-only, the PR description carries everything a reviewer needs: the ticket link, the acceptance-criteria mapping, and the evidence.

Pick ticket: from the trigger message, or oldest open "agent-ready"
Read ticket → intended change
Verify against live data (Mongo schema/samples, warehouse columns)
   → mismatch: Slack note, stop; no PR
Plan minimum additive edit; check downstream consumers
Edit SQL/YAML/tests; dbt parse must pass
One PR per ticket: link, criteria mapping, evidence

Compare the two MongoDB drift agents: the schema drift healer is reactive (a pipeline already failed; self-healing hands it the error log), while this triager is proactive (the drift is announced in a ticket and handled before or as it breaks anything). Teams running both cover planned and unplanned drift with the same additive-patching conventions.

Next steps

MongoDB schema drift healer

The reactive variant, triggered by self-healing on failure.

Jira change request agent

The Jira-writing variant with status transitions and comments.

Run an agent with Bolt

Trigger agents from a Bolt schedule.

MongoDB tools reference

The read-only MongoDB tools this agent uses.

Foundations

Automate with AI agents

Set up & configure

Orchestrate data pipelines

Migrate to Paradime

Develop in Paradime

Learn dbt™

MongoDB schema drift triager

Steps

How it works

Next steps

MongoDB schema drift healer

Jira change request agent

Run an agent with Bolt

MongoDB tools reference

​Steps

​How it works

​Next steps

MongoDB schema drift healer

Jira change request agent

Run an agent with Bolt

MongoDB tools reference

Steps

How it works

Next steps