A marketing leader at a fast-growing SaaS company asks her Snowflake Cortex agent a question last week: "What's our LTV by acquisition channel this quarter?" The system that answers her, and the system that fixes what it can't, are not the same system. But they're the same operating model.

Cortex does what it was built to do. It parses the question. It looks at the semantic model. It writes the query. It returns the data. And then — because it's good at its job — it tells her the truth: the acquisition_channel attribution is missing for roughly 30% of users this quarter. The number she's looking at is incomplete.

The next thing that should happen, of course, is that someone fixes the attribution gap. Builds the dbt™ model that resolves missing channel data from clickstream events. Tests it. Ships it. Materializes it. By the time the marketing leader reloads her dashboard tomorrow morning, the answer should be complete.

But that "someone" is, in most companies, a ticket in a sprint that won't ship for two weeks.

Snowflake Cortex is the AI in your data cloud. It answers questions of the data you have. The data you don't have — that's a different job. That's data engineering. And data engineering is what Paradime DinoAI is built for.

§ OneTwo engines, two jobs

Snowflake Cortex and Paradime DinoAI are not competitors. They are complementary engines pointed at different parts of the same workflow.

Snowflake Cortex is purpose-built for analytics over curated data. Semantic understanding. Natural-language-to-SQL on known schemas. Embeddings. Fine-tuned models. Agentic question-answering. It lives next to your data, runs in your data cloud, and answers questions of that data with low latency.

Paradime DinoAI is purpose-built for data engineering. Building the models. Writing the tests. Maintaining the lineage. Fixing the broken pipelines. Optimizing the expensive queries. Documenting the undocumented. Migrating the legacy. It runs as a specialist agent inside its own infrastructure, indexes your entire stack into a context graph, and produces pull requests, tests, docs, and fixes.

Cortex answers questions of your data. DinoAI builds the data that gets asked. — The pairing in one line

§ TwoWhere DinoAI takes over

The job of a data engineering team is to make sure that when someone asks a question, the data needed to answer it exists, is fresh, is trusted, and is documented. That job has gotten harder as the surface area of "data needed" has expanded — every business team now wants their own metrics, dashboards, ML features, predictive scores.

The work that surfaces every week:

• Change requests. Add a column. Add a metric. Change a definition. Backfill a year of history.
• Test gaps. Models in production with no coverage. Schema drift no one caught.
• Cost overruns. That one query that costs $40,000 a month no one has had time to refactor.
• 3 AM failures. The DAG that fell over. The upstream that changed shape.
• Documentation debt. Three years of models, none of them documented.

All of that work is where Cortex hands off to DinoAI. DinoAI's agents — both conversational and Programmable — pick up these tasks, do the work in isolated sandboxes, and ship pull requests back to your repo. Slack triggers them. CI triggers them. DAGs trigger them. Cron triggers them. So can a Cortex agent, via the Paradime MCP server.

§ ThreeThe pairing in practice

Here is what the pairing looks like in a concrete loop.

It's Monday morning. The marketing leader asks her Snowflake Cortex agent: "What's our LTV by acquisition channel this quarter?"

1. Cortex responds. The agent identifies the right semantic model, generates the query, returns the data. It also surfaces a caveat: 30% of users this quarter have acquisition_channel = null.
2. The Cortex agent invokes a Paradime Programmable Agent via MCP. A pre-defined agent named attribution-fixer is in the repo at .dinoai/agents/attribution-fixer.yml. Cortex calls it.
3. DinoAI takes over. The agent reads the relevant dbt™ models, examines the clickstream events table in Snowflake, identifies the missing attribution logic (a join condition that doesn't account for redirect parameters), writes the fix, generates tests, and opens a PR.
4. A human reviews the PR. The data engineering team reviews the PR in the morning, approves it, merges it. Bolt deploys the new model. The new attribution data starts flowing into dim_users.
5. The marketing leader reloads her dashboard the next morning. This time the answer is complete. She didn't file a ticket. She didn't wait two weeks.

Cortex doesn't try to engineer the data. DinoAI doesn't try to answer business questions. Each does what it's best at, and they pass the baton via MCP.

§ FourThe new operating model

The data team that runs on Cortex + DinoAI doesn't look like a 2023 data team.

The 2023 data team had a fixed backlog and a fixed throughput. Requests came in faster than the team could ship. Sprint queues grew. Important strategic work — ML, experimentation, forecasting — kept slipping to the next quarter because the team was buried in tickets.

The Cortex + DinoAI team has a different shape. Business users get most of their answers directly from Cortex. The questions that surface gaps in the data automatically trigger Programmable Agents that ship the fixes. The data engineers spend their week on the work that compounds: improving the semantic model, designing new agents, building the experimentation platform, working with ML.

The team isn't smaller. It's pointed at the right problem.

Snowflake calls this the AI Data Cloud. We call it the Agent OS for data engineering. They are two parts of the same operating model — the one where your business moves at the speed of its ideas, not the speed of its sprint.