The Agent Didn't Get Smarter. The Context Did.

The most revealing moment in OpenAI's Data Agent launch wasn't the demo. It was the Q&A. Almost nobody asked about the agent.

---

The questions nobody asked

When OpenAI launched its Data Agent in ChatGPT Work this month, the demo did what demos do: a question in plain English, a warehouse query underneath, a dashboard at the end. It connects to Snowflake, BigQuery, Redshift, Databricks and the rest, and OpenAI says the internal version already serves more than 3,500 of its own employees across roughly 70,000 datasets.

Then the floor opened, and the room ignored the agent.

The questions we heard were all variations on the same theme:

• How do you handle the setup underneath: context, data quality, governance, accuracy?
• How much of your data team's time now goes to reviewing analyses run by people who don't know the mechanics beneath them?
• How do you validate that the agent returns reproducible logic across self-service queries?
• How do you keep the semantic layer current as the business changes?

Not one of those is a question about the model. Every one is a question about the layer between the agent and the answer.

OpenAI's answer was the tell

OpenAI's own response confirmed it. As described in the Q&A, the internal team built a context layer around the agent and maintains roughly 200 vetted question-SQL-answer pairs, re-running them to catch drift when the data or the definitions move. Accounts of the internal build describe the same shape: table-usage patterns, human annotations, meaning pulled out of pipeline code, institutional knowledge from docs and chat, memory of user corrections, and live warehouse lookups when the stored context runs out.

Notice what is missing from that list. There is no "we waited for a smarter model." The team that has the best models in the world spent its effort on context and evaluation, and it still has not published a public accuracy benchmark for the product.

That tells you where the difficulty lives. The agent is becoming the commodity. Every serious vendor can call a frontier model, generate SQL, and render a chart. What separates a right number from a wrong one is everything the model is told before it writes the query.

A better model will not fix a wrong number. Context will.

Same question, two ways

Here is what that looks like in practice. Take one of the most ordinary questions in any company: "What was revenue last quarter?"

Both queries are syntactically perfect. Both run without error. Both come back with a confident number and a tidy chart. Only one of them is what the CFO means by "revenue," and nothing in the schema tells the agent which one.

The first answer isn't a model failure. The model did exactly what it was asked with what it knew. The failure is that nobody wrote down that revenue is net of refunds, that is_test = true accounts don't count, and that this company's Q4 ends in September. That is business context, and it lives in people's heads until someone captures it.

The agent didn't get smarter between the two answers. The context did.

What "knowledge" means at Wren

That layer is exactly what we build. We call it knowledge: the business context your team already carries, written down once and reused on every answer.

In Wren AI, knowledge sits on top of the MDL context layer and is made of plain, reviewable pieces:

• Glossary terms: what "active customer," "churn," or "ARR" mean here, not in a textbook.
• Metric definitions: revenue is net of refunds, excludes test accounts, and reports on the fiscal calendar.
• Business rules: which tables are the source of truth, which regions roll up where, which statuses count as closed.
• Vetted question-to-SQL pairs: the same idea OpenAI described, so a known-good query is reused instead of regenerated.

Every answer Wren produces is grounded in that knowledge before the SQL is written, so a fresh hire, a sales lead, and an AI agent calling Wren over MCP all get the $92,780, with the same definition, for the same reason.

Two properties matter for the questions asked at that launch:

1. It is reproducible. The definition of revenue is a file, not a prompt. Ask the question a hundred times, in a hundred phrasings, and the same knowledge applies. That is what makes self-service analysis reviewable instead of a new audit every time.
2. It stays current. Knowledge is versioned. When finance changes how a metric is defined, the change lands as a readable diff, gets reviewed like code, and applies everywhere at once. With Git Sync, that history lives in a repository you own, in Markdown and YAML you can read, diff, or take with you.

Thirty seconds of what that means day to day: the context layer as plain files in a Git repo, with every change tracked, reviewable, and revertable.

Where to spend the next quarter

If your team is evaluating data agents right now, the launch Q&A is a decent checklist. Skip the model comparison and ask the vendor the questions the room asked:

• Where does business context live, and who can read it?
• How do you prove that two people asking the same question get the same logic?
• What happens to every past answer when a metric definition changes?
• Can we take the context with us?

Models will keep getting better, and every vendor will get the same upgrade on the same day. The context is the part you build, the part that compounds, and the part that makes the number right. We wrote about why we rebuilt Wren around an open context layer for exactly this reason.

See how Wren's knowledge closes the AI context gap. Book a demo and bring your hardest metric definition.