Ship smarter agents in production with dbt Agent Skills

Coding agents are doing a tremendous amount of useful work today. Since Claude Code dropped last year, followed by Opus 4.5 and GPT 5.2, software engineering has very clearly passed a phase change. We've gone from copilot-style autocomplete to agents that can run end-to-end across the SDLC.

But anyone who's tried to point one of these agents at a dbt project has hit the same wall I have. Ask a coding agent to build a new dbt model, and it'll happily make five or six changes across your DAG, then try to run the new model at the end.

It breaks. The agent didn't know which columns existed, didn't iteratively run queries as it walked the DAG, and didn't think about lineage or contracts.

The technology is marvelous. The agents simply haven't been taught how to do data work yet. Without a governed foundation—your actual models, lineage, contracts, and metrics—a coding agent is working from guesswork. It can write SQL that looks right and still return numbers no one can verify.

That's what we're fixing with dbt agent skills.

Coding agents are generalist agents, including for data

We call them coding agents, but that framing undersells what they are. dbt agent skills can do all types of work. One of those types is data work, which is where most of you reading this probably want to put them.

The catch is that the agents have been specialized for coding workflows. There's a long list of small tweaks and improvements that make them slot neatly into a software engineering loop. Data has its own additional bits that haven't been baked in by default: understanding data lineage, respecting contracts, iteratively running queries to validate as you go, and knowing when to materialize what.

A lot of teams have been layering those in by hand with AGENTS.md files. But there's a ceiling to how big an AGENTS.md can get before it becomes its own problem.

What agent skills are, and what dbt's are doing

Agent skills are a protocol Anthropic released late last year and donated to an open foundation. They're how you give an agent context into specific processes and workflows it needs to know about, packaged as markdown plus optional supporting scripts that the agent loads when relevant.

We've taken everything dbt Labs has learned about analytics engineering and ported it into a series of agent skills, in an open repo that works with any agent supporting the protocol. You can think of agent skills as dbt best practices ported directly into your agent. That includes:

• Building a model iteratively rather than one-shotting it
• Writing unit tests
• Understanding your Directed Acyclic Graph (DAG)
• Building your semantic layer
• Debugging incremental models (which any longtime dbt user has spent their share of time on)

The goal is to have the entire Analytics Development Lifecycle (ADLC) captured within skills, so the combination of a generalist coding agent and the dbt skills gives you a powerful data agent out of the box.

That's part of the way there. The rest is your custom context, the things only your organization knows. Naming conventions, materialization choices, source quirks, gotchas. Skills are designed for that too: anyone can write one for their own project, and the strongest setups combine the general dbt skills with org-specific custom skills layered on top.

How Factory scaled up with dbt

Nikhil Harithas from Factory has been building this out from scratch. Factory is in the business of bringing autonomy to software engineering through Droids, their generalist agents that work across the SDLC, including the terminal, web, CLI, GitHub, and Teams. Nikhil's a field engineer there, and over the last few months, he's been standing up Factory's data posture using dbt as the central piece.

Factory's materialization strategy changed as the team scaled up. Factory is a younger company, so the default was to materialize as late as possible, with a blanket rule that worked fine in the early days.

As certain queries took long enough that things started getting expensive, and as the team wanted fresher data, that rule needed to change. The math, Nikhil notes, is both money and time, and also how many people you have to maintain the pipeline.

Up until a few weeks ago, Factory was rebuilding entire tables on every single run because it was fine. The shift to incremental builds came because that was the only way to run more often without blowing up cost. Incremental builds are finickier than entire builds, so testing started to matter a lot more.

As Nikhil puts it: "I wasn't as familiar with the dbt test suite until a couple of weeks ago, when I was like, okay, it's time to shore up all these kind of implicit contracts in these table definitions. We realized that every row has to have a distinct ID of some kind, depending on the table."

Tests went on the most important tables first. The principle behind it: "How can you increase individual leverage as far as you can by systematizing as much as you can, by giving Droid the same kind of feedback you or I would?"

Lessons learned from the build-out

Nikhil’s top-line claim from the build-out: months of work that would have taken five or six people was done by one and a half people, in a couple of months. That alone is worth taking seriously.

A few of the patterns he ran into:

Build vs. operate are different motions, and you need to teach the agent both. Nikhil's framing: "What is it like to develop in dbt, and what is it like to operationalize in dbt?" Those things are related but slightly different. The historical reason agents have struggled with data teams more than they've struggled with generalist software engineering is, ultimately, a context problem on both fronts. Data is a mix of writing code and running operational workflows. It's closer to SRE work than pure software engineering in places.

Skill creep is real. Early on, Nikhil ran into trouble with too many skills, which led to inconsistent triggering and ambiguity about which skill applied. The fix: Be intentional about how many skills you have, and make each one denser. Skills you're confident the agent will discover on its own can stay as habit-forming background. The high-value skills are the ones that anchor behavior on the most important tasks.

Say it louder in AGENTS.md. Skills get auto-invoked sometimes, but you shouldn't bet on it. AGENTS.md is what's guaranteed to be in context, so Nikhil's pattern is to point at the relevant skills there explicitly: "You're going to be using BigQuery and dbt and a few other vendors that Extract, Transform, and Load (ETL) data to us. You have to pay attention to the skills of these particular frameworks, because there's going to be how you do anything at all."

Build the repo so agents bump into skills naturally. Even when a skill isn't auto-invoked, an agent grepping around to get its bearings should run into it. The mere mention of "dbt" anywhere in the project should surface the relevant SKILL.md in the search results.

Skill golf. Doug Bady at dbt coined this. The practice: go through your skills and try to rip out everything you can to make them as tight as possible. Distractions in context cost you.

Documentation as a hook. Factory now has a check that fires when someone changes a column or table. It requires documentation to land somewhere in the project before the change can merge. The agent doesn't have to write the docs by hand, but the structural requirement creates a flywheel where good behavior produces more good behavior.

To see these principles in action, watch a full demo of Factory’s Droids and dbt agent skills in our webinar.

Building faster feedback loops

"Look at the last 20 years of software engineering,” Nikhil says.. “We’ve gotten faster because of feedback loops. It's easier to write tests, easier to write integration tests, logs are easier to look at. Humans are getting faster feedback loops. We have to give the same thing to agents."

Nikhil's framing of where coding agents are today is worth leaning on. We're at a point, he says, where "if you can imagine it and if you are determined to build it, you can build it." That's a pretty magical thing to be able to say.

But it feels like not everyone is experiencing that reality. The reason, in his view, is that while a lot of things that used to be difficult are now easy, some of the things that were hard are still hard. Integrations. Human context and assumed knowledge. Naming things, famously.

If you're going to put one thing on your list this week, Nikhil's call was to figure out how to give your agents access to the most tools you can and the most amount of direct feedback you can. Nothing is more powerful than read-only access to the database. If an agent can't query the database, everything goes slower.

The reframe he offered is the one I'd lead with: What would need to be true for you to give an agent access to your database? That's the question. Maybe the work this week isn't a data engineering task at all. Maybe it's setting up your environment so you'd feel safe handing an agent that access. Once they have it, they fly.

This is a singular moment in technological progression. The combination of generalist coding agents, dbt agent skills, the dbt MCP server, your own custom skills, and platforms like Droid is making it possible for very small teams to do work that used to require very large ones.

Get involved. The dbt agent skills repo is open, and we want to see what you build with it.