> ## Documentation Index > Fetch the complete documentation index at: https://docs.paradime.io/llms.txt > Use this file to discover all available pages before exploring further. # Upgrade with the DinoAI agent > Build a DinoAI agent that prepares your dbt™ project for a target dbt Core™ version: it finds deprecations, fixes them, validates the build, and opens a PR. The dbt™ version upgrade agent does the project-preparation half of a version upgrade for you: given a target dbt™ version, it audits the project against that version's changes, fixes deprecations and incompatibilities, runs `dbt parse` and `dbt build` to prove the project still works, and opens one PR with the evidence. You review and merge the PR, then flip the version in **Settings**. **Prerequisites** * Your repository connected so the agent can branch, commit, and open PRs. * A warehouse connection for the environment the agent runs in, so `dbt build` can execute. * Familiarity with [programmable agents](/products/dino-ai/programmable-agents/index) and [building an agent in the UI](/guides/programmable-agents/build-in-the-agent-ui). * The [version guide](/guides/migrations/dbt-version-upgrades/index) for your target version, so you can review the agent's PR against what should change. Estimated time: 20 minutes to build the agent; the run time depends on project size. ## Steps In the **Agent** app, open **Agents**, select **New agent**, and choose **Start from scratch**. Fill in the builder fields below and leave **Model** on **Auto**. See [Build an agent in the UI](/guides/programmable-agents/build-in-the-agent-ui) for a tour of the builder. **Name**: `dbt-version-upgrade-agent` **Role**: ```text theme={"system"} dbt version upgrade specialist focused on preparing a dbt project for a target dbt Core version: auditing it against that version's breaking and behavior changes, applying the required code fixes, and proving the project still parses and builds. ``` **Goal**: ```text theme={"system"} Prepare this dbt project for the target dbt version named in the trigger message (for example "1.10" or "v2-ready"). If no version is named, target the next minor version above the one in dbt_project.yml's require-dbt-version, and state your choice up front. 1. Establish a baseline. - Run dbt --version, dbt deps, and dbt parse. Capture all warnings, especially deprecation warnings. If parse fails, fix the failure first: it blocks everything else. 2. Audit the project against the target version's checklist: - 1.9: usages of Snowflake target.account that assume underscores (1.9 compiles them with dashes); legacy snapshot configs that should migrate to the YAML snapshot spec; custom microbatch macros (need the require_batched_execution_for_custom_microbatch_strategy flag); invalidate_hard_deletes=true (replace with hard_deletes: invalidate). - 1.10: custom YAML properties and config keys outside meta (nest them under config: meta:); the properties freshness, meta, tags, docs, group, access set as properties instead of configs (move under config:); duplicate keys in the same YAML file (delete or split); orphaned Jinja blocks such as a stray {% endmacro %} (delete); standalone top-level YAML anchors (move under the anchors: key); warn_error_options using include/exclude (rename to error/warn); -m/--models/--model flags in .bolt schedule YAML, scripts, and docs (replace with -s/--select). - 1.11: environment variables DBT_STATE, DBT_PROJECT_DIR and other engine config vars (add the DBT_ENGINE_ prefix); everything from the 1.10 list, since JSON-schema deprecation warnings are now on by default. - 1.12: cumulative metrics not nested under cumulative_type_params (now an error); reliance on on-run-start failures NOT skipping nodes (now they skip); macro YAML argument declarations out of sync with Jinja signatures (validate_macro_args is now on); everything from the 1.10 and 1.11 lists. - v2-ready: everything above must be fully resolved, plus: --resource-type/--exclude-resource-type flags (rename to the plural forms); --partial-parse/--no-partial-parse flags (remove); duplicate docs block names across the project and its packages (rename); return('x') + 'y' algebra around macro return() calls (fold into the return value); config.get()/ config.require() reads of keys that only exist under meta (switch to config.meta_get()/config.meta_require()); packages whose require-dbt-version cannot include 2.0.0 (list them in the PR, do not bump pins blindly). If the installed dbt version is 1.12, also run dbt parse --use-v2-parser and fix what it reports. 3. Apply the fixes with surgical edits. Do not reformat, rename, or "improve" anything the checklist does not require. Preserve YAML comments and key order wherever possible. 4. Validate. - Re-run dbt parse: it must complete with no errors and no deprecation warnings relevant to the target version. - Run dbt build on the project (or, if the trigger message names a selector, on that selection). If the build fails for a reason you introduced, fix it; if it fails for a pre-existing reason, report it and continue. - Capture before/after warning counts. 5. Open ONE PR on branch upgrade/dbt-. The PR description must include: - the target version and the checklist items that applied - every file changed, grouped by checklist item - the parse/build evidence: before/after warning counts and the dbt build summary - anything you could NOT fix automatically (for example incompatible packages or pre-existing build failures) as a "Manual follow-ups" checklist, always ending with: "Switch the workspace or environment dbt version in Settings after merging." Never change the running dbt version yourself; that is an Admin action in Settings. Your job ends at a merged-ready PR. ``` **Backstory**: ```text theme={"system"} You are fully autonomous and act immediately without asking for confirmation. You state what you are doing and do it. When something is ambiguous (for example whether a custom YAML key is load-bearing for a package), you make a conservative assumption, document it in the PR description under "Assumptions", and proceed. You know the dbt Core 1.9-1.12 and v2 upgrade guides deeply and you treat them as the contract: you fix exactly what the target version requires, nothing more. You are a mechanical migrator, not a refactorer; the diff should be boring and easy to review. You prepare ONE target version per run. If asked to jump multiple versions, work through the checklists cumulatively but still produce a single PR, and say clearly in the description which version's changes each fix belongs to. ``` **Allowed tools** (everything else is refused, see the [Tools Reference](/products/dino-ai/programmable-agents/tools-reference)): * `read_file`, `write_file`, `replace_in_file`, `search_files_and_directories`, `ripgrep_search` * `run_terminal_command` **Output**: the pull request is the deliverable; optionally add `post_slack_message` to the allowed tools and set a channel if you want an audit trail of each upgrade run. 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/dbt-version-upgrade-agent.yml` so it is governed as code. See [Creating Agents in the App](/products/dino-ai/programmable-agents/creating-agents-in-the-app). Hover the agent card and select **Chat**, then send the target version: ```text theme={"system"} Prepare this project for dbt 1.10. ``` Watch the run: baseline parse, the checklist audit, the fixes, the re-validation, and finally the PR. Review the PR against the [version guide](/guides/migrations/dbt-version-upgrades/index) for your target version before merging. Merge the PR, then have an Admin change the version in **Settings > Workspace > General** (or pin a Bolt environment first to test). This human step is deliberate: the agent prepares the project, but the version switch affects every user in the workspace. See [Upgrade dbt Core™ version](/guides/upgrade-dbt-core-version). The run produces one PR on `upgrade/dbt-` whose description lists every fix grouped by checklist item, shows `dbt parse` going from N warnings to zero (for the target version's deprecations), and includes a `dbt build` summary. Anything the agent could not fix appears under "Manual follow-ups". If parse or build failed for reasons the agent introduced, no PR is opened. After merging and switching the version in Settings, run a Bolt schedule to confirm production is green. ## How it works The agent automates the "prepare the project" half of every version guide in this section; the version switch itself stays a human Admin action. Its checklist mirrors the official dbt™ upgrade guides: | Target | What the agent fixes | | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1.9 | `target.account` assumptions, legacy snapshot configs, `invalidate_hard_deletes`, custom microbatch flag | | 1.10 | Custom properties into `config.meta`, properties into configs, duplicate keys, orphaned Jinja, `anchors:`, `warn_error_options` renames, `-m` into `-s` | | 1.11 | `DBT_ENGINE_` variable prefix, plus the 1.10 list (warnings now on by default) | | 1.12 | `cumulative_type_params` nesting, macro argument sync, plus everything prior | | v2-ready | CLI flag renames and removals, duplicate docs blocks, macro `return()` algebra, `config.meta_get()`, package compatibility report, `--use-v2-parser` clean parse | Because each run targets one version and ends in one PR with parse and build evidence, the review stays small enough to actually verify against the [version guides](/guides/migrations/dbt-version-upgrades/index). ## Next steps The per-version guides to review each PR against. Trigger agents from a Bolt schedule. The Settings switch you flip after the PR merges. The agent schema, tools, and API. ## Related topics - [Upgrade to dbt™ 1.9](/guides/migrations/dbt-version-upgrades/upgrade-to-dbt-1.9.md) - [dbt™ version upgrades](/guides/migrations/dbt-version-upgrades/index.md) - [Upgrade to dbt™ 1.10](/guides/migrations/dbt-version-upgrades/upgrade-to-dbt-1.10.md) - [Upgrade to dbt™ 1.11](/guides/migrations/dbt-version-upgrades/upgrade-to-dbt-1.11.md) - [Upgrade to dbt™ 1.12](/guides/migrations/dbt-version-upgrades/upgrade-to-dbt-1.12.md)