At the ADE User Meetup in May 2026, I gave a 20-minute talk about what actually happens when you put Agile Data Agent into a real, live ADE project. Not a vision talk. Not a product pitch. What I wanted to share is the practitioner's view: what happens to your work, your reviews, and your team when you actually wire this thing into a project that already exists.
Here's the short version.
The mental model that landed for me, the one I used on stage, is the factory. When you start working agentically, you stop being the person at the workbench making data models by hand. You become a factory builder. Your job is to set up the floor, write the rules the workers follow, install the tools, and inspect what comes off the line.
The agent is the worker. The harness is the factory.
That word "harness" gets thrown around in the agentic-AI literature without much grounding. Every agent tool already ships with one. GitHub Copilot and Claude Code wrap the model in an execution loop that reads context, calls tools, and acts. That part is roughly the same everywhere, and it isn't where the value is. The harness that actually differentiates you is the layer you build on top, the part that makes a generic loop understand your specific project:
None of that is in the model. The model is generic. Your project is not. That gap is the whole game, and the harness is how you close it.
Quick aside, because someone always asks. ADA doesn't generate SQL. It generates structured YAML metadata that has to conform to ADE's schema. ADE then generates the SQL deterministically from that metadata. So the agent's failure surface is bounded in a precise way: it can't emit SQL that won't parse or deploy, because the generated code is correct by construction. What it can still do is propose a wrong design, a metadata change that validates cleanly, deploys cleanly, and is the wrong model anyway. That class of error survives validation, which is exactly why you still review every spec.
This is what makes ADE structurally well-suited to agentic work, but the reason is narrower than it validates and code-first platforms don't. They validate before execution too (dbt parse, linting, CI). The real difference is the generative surface. The agent emits constrained metadata, not free-form Python or SQL, so it has far fewer ways to go wrong. Schema conformance is checked before anything deploys, and once the metadata is valid I push it and trust it produces exactly what I'd have built in the UI, because functionally I did. I just had an agent do the typing. That gives me a clean mechanical result. Whether it's the right result is still my call.
The first time you generate a working package agentically and open it in ADE's UI and think "I could have made this with my own hands," that's the moment it locks in. This is the future.
After a few weeks of doing this seriously, the work stops looking like data modeling and starts looking like a loop with exactly two moves:
Review the spec the agent gave you
Update the harness so it's better next time
That's it. That's the whole shape.
The interesting bit, the thing that separates teams who make this stick from teams who burn out trying, is which move you make when the agent gets something wrong. The junior instinct is to fix the output: edit the YAML, correct the design, ship the change. The practitioner instinct is to look at the wrong output and ask what's missing from the harness that let this happen? Then you fix that. The output fixes itself next time, and every time after.
This is why the harness is the asset and the agent platform isn't. The model gets rented and replaced every quarter. The harness is the accumulated, version-controlled understanding of your project: your conventions, your source-system quirks, your team's hard-won corrections. It compounds. Whatever agent runs underneath it next year, the harness still works.
Reviewing the spec is the visible work. Updating the harness is the work that compounds. Most teams do the first and skip the second. That's why it doesn't stick for them.
Three things shift, and they're worth being explicit about because most of the value of agentic development shows up at the team level, not the individual level.
Roles change. Less hand-coding. More design review. More harness maintenance. A new role appears, even if nobody's title says it: the harness maintainer, the person who owns AGENTS.md, the skills, the conventions, the memory. On a healthy team this rotates. On an unhealthy team it doesn't exist and the harness rots.
Reviews change. They get shorter and more conceptual. The question is no longer "is this query correct?" It's "is this the right model?" That's harder, more important, and more interesting. It also means a wrong design propagates faster when an agent is generating from it, so review quality matters more than ever.
Senior engineers get massive leverage. This is the part I want people to internalize. If you have a decade of ADE experience, agentic tooling is not a threat to your value. It's a 10x multiplier on it. Your judgment, your conventions, your hard-won taste, all of that goes into the harness, where it stops being trapped in your head and starts compounding across every project you touch.
The harness is where your senior engineers' judgment goes to stop being a single point of failure.
---
In the second part, I'll walk through what a day of agentic ADE work actually looks like: the specific tools, the workflow loop, and the honest signals for whether it's working or not.
Markus Heiskanen is Data Architect and Tech Lead for Intelligence Platforms at Solita. He works across ADE, Databricks, Snowflake, and Azure, building data platforms end-to-end with an agentic approach.