In my previous post I described the mental model shift: when you start working agentically with ADA, you stop being the person building data models by hand and start being the factory builder. The loop has exactly two moves: review the spec, update the harness.
Here's what that loop looks like in practice.
You start in your terminal. You don't open Jira; you tell the agent to open Jira. Go to this epic, see what's going on, do this task. The agent reads the ticket, follows the linked documentation, builds context from the source-system MCP server, looks at how similar tickets were handled in the package's git history, and drafts a metadata change.
You review the design, not the SQL. You never review the generated SQL anymore, and that turns out to be fine because ADE generates the code deterministically from the metadata. You look at the conceptual model: does this Hub belong here, is this Satellite split correctly, is this dimension grain right? That's the part the agent can get wrong in a way validation won't catch, so that's the part you own.
You iterate. Sometimes the agent missed a convention. That's a harness update, not a one-off fix. Sometimes the design needs a structural adjustment, which is a conversation with the agent, not a rewrite.
When the spec is right, you ada plan to see the diff against ADE, then push. ADE validates the metadata, deploys, runs. Schema validation catches malformed metadata before deploy, but it can't catch a load that fails at runtime for a reason the metadata couldn't express, like a source-data surprise or a broken upstream. When that happens, you can ask the agent what failed last night? and it queries the ADE MCP server directly and tells you. The agent is in operate too, not just build.
Then you tell the agent to update Jira with detailed notes. You write very long, very thoughtful Jira comments without ever opening Jira. Everyone in your organisation starts wondering when you got so verbose and articulate.
A few specific harness components that have outsized impact:
Jira MCP integration. The single highest-leverage piece. The spec already exists. It's in Jira. The augmentation is making it consumable. This is what changes the workflow from "agentic modeling" into "the engineer never context-switches into Jira to translate a ticket by hand."
Source-system MCP servers. For instance, an MCP exposing SAP documentation that the agent uses live during staging and modeling work. The agent stops re-deriving "what is a customer entity" because the source documentation is one tool call away.
Context7 MCP. External MCP from Upstash that serves up-to-date, version-specific documentation for a huge range of software libraries and frameworks. Supplementary knowledge source, useful when the agent encounters something niche.
ADE MCP server. First-party, ships with the platform, gives the agent real-time visibility into production state. Closes the build-operate loop.
Git. The unsexy one, and the one with the biggest practical payoff: ADE never had an undo button. With ADA on top of a Git repository, every change is historized. *"Restore the previous checkpoint"* actually works now. Anyone who has lived without that capability for years will feel it the first time they use it.
The honest signals.
It's working when:
You spend more time improving the harness than fighting the agent
The agent learns from corrections instead of repeating them
New team members get productive faster because the project's knowledge is in the harness, not in tribal memory
You can defend the agent's output in a design review without the agent in the room
It's not working when:
You're re-explaining the same conventions over and over (a harness gap you never closed)
You're stuck in an "AI slop loop": plausible output that's quietly wrong
Nobody owns the harness and it's rotting
Your sense of "good model" is eroding because mediocre is now your baseline
The most useful single heuristic: if it feels like the agent is learning, you're on the right track. If you have to repeat yourself on the same naming convention three times in a week, you're not. Your harness has a hole, and you should fix that before you do anything else.
It's early. The tooling is new. Patterns are still forming. Anyone telling you this is fully solved is selling something. But the shape of platform engineering work changes about once a decade, and this is one of those moments. The teams that win in the next phase will not be the ones with access to the best model. Everyone rents the same models. They'll be the ones with the best harness.
If you want to try it this week:
1. Write an AGENTS.md for your most-touched ADE project. Just one. See what changes when the agent has it.
2. Take one mistake the agent made and fix the harness, not the output. Convert the mistake into a memory or a skill update.
3. Pick one repetitive modeling task and turn it into a skill that knows your conventions.
Initialize ADA, point it at your repo, ask it to look at how you've been working. Let it generate the first staging package. Review the design, not the SQL. When it gets something wrong, fix the harness, not the file. Then do it again.
Little by little, you outsource the manual work. The harness compounds. The agent gets better at your project specifically. Not at "data modeling in general," but at your project.
That's the shape of the change. Review the spec. Update the harness. The compounding takes care of itself.
---
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. If you want to talk about putting ADA into a real project, find him on LinkedIn or via Solita.