DEV Community: Evan Rosa

Anthropic Proved the Agentic Data Stack Works.

Evan Rosa — Tue, 01 Sep 2026 13:45:08 +0000

Anthropic Proved the Agentic Data Stack Works.

I just read Anthropic's post on self-service analytics. Nothing surprised me. It described, almost line for line, the bet I made when I started building OptimaFlo.

Their core claim is blunt: writing SQL is trivial now. For people, and for the model. The hard part is everything wrapped around it.

Which table should the agent use? Which definition of "revenue" is the real one? Which dimensions are safe to join? Which source went stale last week? When someone asks for "active users," what counts as active, and does it match what the last person who asked meant?

Point an agent straight at your warehouse and you find out the hard way. It feels like magic for a little bit but then it starts handing over confident, wrong answers, and nobody catches them until the number is already in use.

Anthropic's fix isn't as loud and groundbreaking as people thought. Canonical datasets. A semantic layer. Curated reference docs. Lineage. Validation. Skills that encode how a good analyst actually works. Their agent went from under 21% accuracy to consistently over 95%, and the jump came from building context and tools around the model.

The detail I keep thinking about

They gave the agent direct access to thousands of their own past queries. Every question, already answered correctly, sitting right there. Accuracy barely moved, about less than one point. The agent read the queries and still did not use them.

The bottleneck was never access to data. It was structure: taking a messy human question and mapping it to the one correct entity, then knowing how to work with it. That is the part no model solves for you just by getting bigger. I have watched it play out in our own product. You can hand the model everything and still get a shrug, because "everything" is not the same as "the right thing, defined."

I agree with all of it. I have believed it for over a year.

Who builds the scaffolding

Every layer Anthropic describes is built and owned by a data team. The governed models. The semantic layer. The colocated repo. The eval harness. The maintenance hooks that keep docs from rotting. All of it is the day job of people who do data for a living. But Anthropic has one of the best teams in the world.

A lot of companies that want self-service analytics do not have that. They have a small team or even one data person (oftentimes frustrated and overwhelmed). Sometimes zero, and a founder running SQL at midnight.

So the post raises the bar in a way that is easy to miss. "Point an agent at the warehouse" does not work. "Build and maintain the full agentic stack" works, but it needs the exact team you were trying to get by without. That is the gap OptimaFlo exists to close.

Same scaffolding, one person or a small team to run it

My bet is simple. The structure Anthropic describes should not be a project you staff. It should come with the product.

The canonical models, the semantic layer, the reference docs, the validation step: we build that for you, in your own cloud, on open formats like Iceberg, so it is your data the whole way through. One data owner or a small team can run the stack a whole team used to run.

Anthropic said it as plainly as I would; "We recommend generating the documentation with Claude, but having a human own the definition." That's it. Someone still has to decide what "revenue" means. What "active" means. What counts as retention. The model can't make that call and it shouldn't try.

That is why the SQL that builds your tables passes a human approval step before it runs. Not as a compliance checkbox. The data owner is the one who knows the business. The agent should do the grunt work of finding, joining, and checking. We amplify the owner. We do not replace them.

So here is the real question

If you are a data owner reading Anthropic's post and feeling the weight of that to-do list, canonical datasets, semantic layer, evals, maintenance, all of it, that is the right instinct. It is a lot. It is also exactly the work we think you should not do by hand.

Anthropic just made the case that the agentic data stack is table stakes. They are right.

The question they leave open is the one I care about: who builds and maintains it when you do not have a full data team?

If that is you, I would like to know your plan. Come tell me, or see how OptimaFlo runs the stack for one owner.

Frequently asked questions

What did Anthropic's self-service analytics post argue?
Writing SQL is trivial now, for people and for the model. The hard part is the scaffolding around it: canonical datasets, a semantic layer, curated reference docs, lineage, and validation. With that structure their analytics agent went from under 21% accuracy to consistently over 95%.

Why didn't giving the agent access to past queries help?
Anthropic handed their agent thousands of correct past queries and accuracy moved less than one point. The bottleneck was never access to data. It was structure: mapping a vague human question to the one correct table and metric. The agent read the queries and still did not use them.

Do you need a data team to build an agentic analytics stack?
In Anthropic's model, yes. Every layer they describe, the governed models, the semantic layer, the eval harness, and the maintenance that keeps docs from rotting, is built and owned by a data team. OptimaFlo packages that scaffolding into the product so small and overwhelmed data teams can run it.

Can AI replace a data team?
No, and that is the wrong framing. The model does the repetitive work of finding, joining, and checking. A person owns the meaning: what "revenue" or "active" means for your business. OptimaFlo puts a human approval step in front of the SQL that builds your tables.

How is OptimaFlo different from pointing an agent at your warehouse?
Pointing an agent at a raw warehouse feels like magic for a week, then it returns confident wrong answers. OptimaFlo builds the canonical models, semantic layer, reference docs, and validation for you, in your own cloud on open formats like Iceberg, so the agent works against governed data instead of a guess.

Anthropic's post: "How Anthropic enables self-service data analytics with Claude" (June 3, 2026).

Originally published at optimaflo.io.

Everyone Just Agreed on the Foundation. Nobody's Answering Who Gets to Run It.

Evan Rosa — Tue, 01 Sep 2026 13:43:09 +0000

Everyone Just Agreed on the Foundation. Nobody's Answering Who Gets to Run It.

The whole data industry just agreed on what good looks like.

This week Fivetran and dbt Labs closed their merger. The deal was announced back in October, and on June 1 it became official: one company, with George Fraser as CEO and Tristan Handy as President, serving more than 100,000 data teams. They called it "the data infrastructure for trusted AI agents."

Read past the headline and the thesis is clear. Trust in AI doesn't get built in the model. It gets built underneath the model, at the infrastructure layer: on open standards, on governed business logic, and on high-quality data an agent can actually rely on. Tristan Handy put it plainly. "Trust is built at the infrastructure layer, on high-quality tooling and on open standards. That's the bet we're making together."

I agree with almost all of it. It's the same bet I made when I started building OptimaFlo: open formats, data that stays in your own cloud, and a governed semantic layer underneath everything. When the two biggest names in the modern data stack merge and land on the same foundation you've been building on, that's not a threat. That's validation.

But there's one line in the announcement I don't agree with. And I think it's the most important line in the whole thing.

"No human in the loop"

Here's the exact passage:

"And many organizations want to move into a world where most agents are autonomous – no human in the loop."

This is where it gets messy.

A clean, governed foundation is necessary. It is not sufficient. Governance and guardrails don't decide which joins are right for your business. They don't know that "active customer" means something different in your finance reports than it does in your product analytics. They don't know which of three revenue tables is the one leadership actually trusts. That context lives in people's heads, in Slack threads, in the way your company actually operates. It is not in the schema.

And LLMs are still hard to make deterministic. Ask the same question twice, get two different queries. Most days that's fine. The day it isn't, you don't get an error. You get a confident answer that's quietly wrong.

So play out the autonomous version. An agent runs a join that looks reasonable and isn't. It doesn't have the full picture of what the business is trying to do. There's no one to catch it before the number ships. Now that number is in a board deck, or worse, in a pricing decision. The agent was fast. It was governed. It was also wrong, and nobody knew until the damage was done.

"Trusted" and "no human in the loop" are not the same thing. Treating them as the same is how you build something that feels trustworthy right up until it costs you.

I think AI agents absolutely belong in data engineering. I've built my whole platform around them. But a human in the loop isn't friction to be optimized away. It's the quality gate. Someone has to direct the work and approve what ships, especially while the models are still this unpredictable.

The question nobody's answering: who actually runs this?

Look at who the giants build for. The merger announcement names OpenAI, LVMH, Pfizer, Verizon, Siemens. More than 100,000 data teams.

The operative word is teams.

This foundation, the one everyone now agrees is correct, was designed to be operated by people who do data for a living. Data engineers to wire it up. Analytics engineers to model it. Platform owners to keep it governed. If you're a Fortune 500 with a department for this, the new world is great.

Now picture the company that doesn't have that. A growing mid-market business. Real revenue, real customers, data spread across Stripe and HubSpot and a warehouse someone set up two years ago. They have every data problem an enterprise has. What they don't have is a data team, and they can't justify stitching together six to ten specialized tools and hiring the engineers to run them.

These companies are not a niche. They are most companies. And they are the ones this consolidation quietly leaves behind. The foundation is open and excellent. The cost of operating it is still a full team.

That gap is the whole reason OptimaFlo exists.

Same foundation. One person to run it.

OptimaFlo is built on the exact open, governed foundation the industry is converging on. Apache Iceberg and open formats, so there's no vendor lock-in. Bring-your-own-cloud, so your data lives in your environment, never ours. A governed semantic layer and business logic underneath everything, in the platform from day one.

The difference is who operates it. Instead of a team, we give one data owner an AI data team to run the whole thing. The agents do the heavy lifting: generating pipelines, writing the SQL, modeling the layers, running quality checks on every layer. The owner stays in control. They direct the work. They approve the SQL before it runs. No pipeline ships on the agent's say-so alone.

That's the human in the loop, built into the product on purpose. The AI amplifies the person who owns the data. It doesn't replace them, and it doesn't pretend their judgment is optional. The work that used to take a whole team, one person can now direct, with the agents handling the volume and the human owning the call.

It's the same answer to the trust problem the giants are reaching for. We just don't think trust means taking the human out. We think it means giving one human the reach of ten, and keeping their hand on the approval.

Where this leaves us

The industry has settled the hard architectural argument. Open standards. Governed business logic. High-quality data an agent can rely on. That part is done, and the Fivetran and dbt merger is the clearest signal yet.

The open questions are the ones about people. Who gets to operate this foundation, not just the enterprises with a department for it? And does "trusted" really mean "no human in the loop"?

I don't think it does. I think the companies that get AI in data right will be the ones who kept a person in the room, directing the agents and approving what ships, all the way down.

If your team didn't have to fight the data stack to get a trustworthy answer, what would you actually build with that time?

Frequently asked questions

What did the Fivetran and dbt merger announce?
On June 1, 2026, Fivetran and dbt Labs closed their merger into one company serving more than 100,000 data teams. They positioned it as the data infrastructure for trusted AI agents, betting that trust in AI is built at the infrastructure layer through open standards and governed data.

Does trusted AI mean no human in the loop?
No. A clean, governed foundation is necessary but not sufficient. Governance does not decide which joins are right for your business or which revenue table leadership actually trusts. That context lives in people, not in the schema. A human in the loop is the quality gate that catches a confident but wrong answer before it ships.

Why is a human in the loop still important for AI data agents?
LLMs are hard to make deterministic. Ask the same question twice and you can get two different queries. When one is wrong you do not get an error, you get a confident answer that is quietly wrong. A person who directs the work and approves what ships catches that before the number lands in a board deck or a pricing decision.

Who is the modern data stack built for?
The merged foundation was designed to be operated by data teams: data engineers to wire it up, analytics engineers to model it, and platform owners to keep it governed. That works for enterprises with a department for this. Mid-market companies with real data problems but no data team are the ones this consolidation quietly leaves behind.

How does OptimaFlo keep a human in the loop?
OptimaFlo runs on the same open, governed foundation: Apache Iceberg and open formats, bring-your-own-cloud, and a governed semantic layer from day one. The difference is who operates it. One data owner gets an AI data team that generates pipelines, writes the SQL, and models the layers, while the owner stays in control and approves the SQL before it runs. No pipeline ships on the agent's say-so alone.

Originally published at optimaflo.io.

The Medallion Architecture, Explained: Raw, Clean, Ready

Evan Rosa — Wed, 19 Aug 2026 17:32:10 +0000

The medallion architecture organizes a data platform into three layers, Raw, Clean, and Ready, that take source data and refine it step by step into trusted, business-ready tables. It is the most common blueprint for the modern data lakehouse, and it is the foundation OptimaFlo is built on. This guide explains each layer in plain English, then shows how to stand one up without hiring a data team.

What is the medallion architecture?

The medallion architecture is a data design pattern popularized by Databricks. It splits data processing into three progressively cleaner layers. You may know these layers by their traditional names, bronze, silver, and gold; we use clearer terms: Raw, Clean, and Ready. Each stage adds structure, quality, and business meaning:

Raw holds data exactly as it arrived.
Clean holds cleaned, validated, joined data.
Ready holds business-ready metrics for dashboards and reports.

The point is simple. You never transform data in one big, fragile step. You move it through three small, reliable ones, and every stage stays queryable and auditable.

The three layers

Raw: untouched source data

Raw is your system of record. Data lands here exactly as the source sent it, with zero transforms and full history. Nothing is thrown away. If a downstream rule turns out to be wrong, you can always reprocess from Raw.

Because Raw keeps everything, the table format matters. OptimaFlo stores every layer in an open lakehouse table format, which gives Raw ACID transactions, schema evolution, and time travel. You can query the table as it looked last Tuesday, not just today.

Clean: cleaned and conformed

Clean is where source data becomes reliable. This layer validates types, removes duplicates, fixes nulls, and joins sources into clean, conformed tables. It is the layer most analysts actually build on.

Clean is also where SQL lives. In a traditional stack this is the dbt layer, written and maintained by data engineers. The transforms are version-controlled and reviewed, because a bad Clean query quietly poisons everything downstream.

Ready: business-ready

Ready is the layer your business sees. It holds aggregated metrics, star schemas, and the tables that power dashboards and reports. Ready tables are usually updated incrementally, so a daily metric refreshes in seconds instead of rebuilding from scratch.

Here is how the three layers compare:

Layer	Holds	Transforms	Typical consumer
Raw	Source data, full history	None	Reprocessing, audits
Clean	Cleaned, validated, joined	Type, dedupe, join	Analysts, data scientists
Ready	Metrics, star schema	Aggregate, model	Dashboards, executives

Why data teams adopt it

The pattern is popular because it solves real problems at once:

Reliability. Failures are isolated to one hop, not the whole pipeline.
Reproducibility. Keeping Raw plus lakehouse time travel means any result can be rebuilt exactly.
Incremental refinement. Each layer does one job, so changes are small and safe.
Auditability. You can trace any Ready number back through Clean to the original source record.

The catch: it usually takes a whole stack and a team

The architecture is elegant. Building it is not. A typical stack stitches together six to ten tools: ingestion (Fivetran), a warehouse (Snowflake), transforms (dbt), orchestration (Airflow), a BI tool (Tableau), and data observability (Monte Carlo). Each one is a contract, a bill, and a thing that breaks at 2 a.m.

It also takes people. Someone has to write the Clean and Ready SQL, wire up the orchestration, and own the schemas. For a data-rich team without a dedicated data engineering function, that is the wall most projects hit.

How OptimaFlo builds the medallion architecture for you

OptimaFlo is one platform that runs the full Raw, Clean, Ready flow inside your own cloud. It is built to remove the stack and help overwhelmed teams at the same time.

LLM-native. Describe the table you want in plain language. OptimaFlo generates the Clean and Ready SQL, you review and approve it, and it ships. The AI writes the data engineering, you keep the judgment.
Open lakehouse foundation. Every layer is an open table, so ACID guarantees, schema evolution, and time travel apply end to end, not just in one tool. No proprietary lock-in.
Bring your own cloud (BYOC). The platform runs in your environment. Your source data is stored in your account, never ours.
The right compute, automatically. OptimaFlo matches the compute to the size of your data: a light local engine for small jobs, your own warehouse as they grow. You never size or manage clusters.
One platform, not ten. Ingestion, transforms, orchestration, dashboards, and data quality checks live in one place.

The result: you can go from your first data source connection to a live, Ready-backed dashboard in a single afternoon. See the getting started guide for the five-minute version, or the architecture overview for the full picture.

What a Clean transform looks like

A Clean model is just SQL: take the Raw table, cast the types, drop the bad rows, and write a clean table. OptimaFlo generates SQL like this, and you approve it before it runs:

SELECT
    order_id,
    customer_id,
    CAST(order_total AS DECIMAL(12, 2)) AS order_total,
    DATE_TRUNC('day', ordered_at)       AS order_day
FROM raw.orders
WHERE order_total IS NOT NULL;

That clean.orders table then feeds a Ready metric, like daily revenue by customer segment, which lands in your dashboard.

Key takeaways

The medallion architecture refines data through three layers: Raw source data, Clean validated data, and Ready business-ready tables.
Its real cost is the multi-tool stack and the data team needed to run it.
OptimaFlo collapses that into one LLM-native platform on an open lakehouse, running in your own cloud.

Ready to build your first Raw-to-Ready pipeline? Start building with OptimaFlo or read the getting started guide.

Connecting an LLM to Your Data Is the 21% Solution.

Evan Rosa — Wed, 19 Aug 2026 17:18:10 +0000

Connecting an LLM to Your Data Is the 21% Solution.

I hear the same question in almost every early conversation: why do I need a platform when I can point Claude at Postgres and start asking questions?

It is a fair question. The connectors are real. Claude wires into Snowflake and Postgres, ChatGPT reaches warehouses over MCP bridges, Gemini sits inside BigQuery. The demo is genuinely impressive.

We also now have public numbers on what happens after the demo.

The numbers

Anthropic measured it on their own analytics workload: "Without skills, Claude's ability to answer analytics questions accurately didn't exceed 21% on our evals." Same model you would connect to your database. Their data, their questions, 21%.

The benchmarks agree. Spider 2.0 is built from real enterprise warehouse workflows: thousand-column schemas, hundred-line queries, multiple SQL dialects. GPT-4o scores 10.1% on it. o1-preview reaches 17.1%. The same models clear 85% on the older academic benchmark, which is why the demo feels like magic and the fourth week does not.

BIRD explains the collapse. Every BIRD question ships with a hand-written hint explaining what the fields mean. Remove the hints and GPT-4 falls from 54.89% to 34.88%. Your users do not write hints. They ask "how many active customers do we have" and assume the model knows what active means. It does not. It picks one of your four dozen candidate columns and sums with confidence.

That is the dangerous part. A wrong number does not look wrong. Anthropic names it the silent failure and admits their hardened stack reduces it rather than eliminating it.

What the 74 points cost

Anthropic closed the gap from 21% to above 95%. Not with a bigger model, and not with more data access: they gave the agent grep access to thousands of their own correct past queries and accuracy moved less than one point.

What worked was structure. Governed canonical datasets. A semantic layer where a human owns every metric definition. Lineage. Skills that encode how a careful analyst works. An eval harness watching all of it. Four layers, built and maintained by one of the best data teams in the world. I wrote about who gets to build that scaffolding when the post first landed.

The other vendors built the same conclusion into their products. Snowflake restricts its own MCP server to semantic views because raw schemas lack the meaning an analyst needs. Google wraps Gemini in a Knowledge Catalog and a Looker semantic layer and calls the bundle the product. The connector is the interface; the governed layer underneath is what they sell.

What a connector never builds

Accuracy aside, there is a category error in the pitch. A connector reads tables. Your data problem is that nobody is building the tables.

The connector will not land your sources in a warehouse. It will not model Raw into Clean into Ready. It runs when you open a chat and stops when you close it: ChatGPT sessions drop their state on disconnect and run nothing on a schedule. It watches nothing overnight. It re-learns your business every session, because chat memory is not a semantic layer.

And the plumbing itself is on you. Anthropic archived its reference Postgres MCP server, the one without query timeouts, row caps, or column blocklists, behind a plain warning: no security guarantees. It still gets about 312k installs a month, mostly from people wiring up exactly the setup in the pitch.

Where I land

OptimaFlo runs on these same models. You bring your own Claude, GPT, or Gemini key. I have no argument with the engine.

What we sell is the 74 points: the governed datasets, the semantic layer, the pipelines, the quality checks, and the eval discipline that Anthropic staffed a team to build, shipped as a product one data owner can run, on open Iceberg tables in your own cloud. A human approves the SQL before it touches your tables. The chat interface is in there too. It is the last step, and it is the easy one.

If your warehouse is already modeled and governed, a $20 chat seat on top of it is a great deal, and I say so in our side-by-side comparison. If nobody is building that warehouse, the seat has nothing to stand on.

The 21% is what the model brings. The rest is the job. Come see how we do it, or kick the tires in a 7-day pilot.

Apache Iceberg in Your Own Cloud, Without the Overhead

Evan Rosa — Wed, 19 Aug 2026 16:36:57 +0000

You do not need a data team to run Apache Iceberg. That used to be the catch, and it is no longer true. A single person can create, query, and maintain Iceberg tables today, because managed platforms took the hard parts off your plate.

So the interesting question is not whether you can run Iceberg. You can. The question is where your data lives while you do it, and what you trade away for the easy path.

Two ways to run Iceberg in 2026

There are two real options, and they pull in opposite directions.

Managed services. Platforms like Snowflake run Iceberg for you. They own the metadata catalog, the storage optimization, and the governance. You focus on pipelines and analytics, and one person can do it. The easiest on-ramp by far.

Self-managed open source. You host Iceberg on your own cloud object storage, like AWS S3 or Azure Blob, and query it with engines like Spark or Trino. This is the path that introduces operational overhead. Someone configures IAM, stands up the catalog, and keeps it running. That someone is usually a data engineer.

Both paths give you real Iceberg. The difference is what you give up.

The tradeoff nobody names: convenience versus control

Managed Iceberg is convenient, and the convenience has a price. Your tables and the optimization around them live inside the vendor's platform. You query open data, but the operational center of gravity sits with them.

Self-managed Iceberg is the opposite. The data stays in your own account. It stays portable, so any engine can read it and you are not tied to one vendor's roadmap or pricing. You pay for that freedom in setup and upkeep, which is why most small teams never choose it. The control is worth it. The overhead is the wall.

That leaves a gap. What if you want the control of self-managed Iceberg, in your own cloud, without paying the operational tax that normally comes with it?

Where OptimaFlo fits

OptimaFlo is built for exactly that gap. It runs the open, in-your-cloud version of Iceberg, and takes the setup work off you.

Your data lands in your own cloud account under a bring-your-own-cloud model, stored as open Iceberg tables across the medallion architecture: Raw source data, Clean modeled data, and Ready business metrics. The tables stay yours and stay portable. Here is what OptimaFlo takes off your plate.

Catalog and access setup, handled at connect time

The first hurdle in self-managed Iceberg is plumbing: standing up the catalog and wiring the cloud permissions so engines can read and write safely. OptimaFlo provisions that when you connect a source, so you do not hand-configure IAM roles or run a catalog server yourself.

The SQL, written by AI

Iceberg gives you durable tables. It does not write the transforms that fill them. You describe the table you want in plain language, OptimaFlo generates the Clean and Ready SQL, and you review and approve it before it runs. You keep the judgment and skip the hand-coding.

The right engine, picked for you

Iceberg separates storage from compute, so the same tables can run on different engines. OptimaFlo picks for you: small jobs on a light, cheap engine, larger ones on your warehouse. You never size a cluster.

Who this is for

You have data in your own cloud and a reason to keep it there: portability, governance, or just not wanting a vendor to hold it. You like the open, self-managed model, but you do not have an engineer to stand up catalogs and wire cloud permissions. That is the person OptimaFlo is built for. You get the control of self-managed Iceberg with an operational load closer to a managed service.

Key takeaways

You do not need a data team to use Iceberg. Managed services already make it a one-person job.
The real choice is convenience versus control: managed keeps your data in a vendor's platform, self-managed keeps it open and yours but adds operational overhead.
OptimaFlo removes that overhead for the in-your-cloud path: catalog and IAM at connect time, AI-generated SQL, and automatic engine selection.

Want open Iceberg in your own cloud without the setup work? Start building with OptimaFlo or read the getting started guide.