Yesterday, OpenAI published a fascinating article about their internal data agent — a custom AI system they built to help employees explore and analyze their massive 600-petabyte data infrastructure. While it's not a product they're selling, the article reveals something far more valuable than any new model release: the fundamental principles that make AI applications actually work.
You can read the original article here: https://openai.com/index/inside-our-in-house-data-agent/
One insight from that article stopped me in my tracks. They wrote: "Schemas and query history describe a table's shape and usage, but its true meaning lives in the code that produces it. Pipeline logic captures assumptions, freshness guarantees, and business intent that never surface in SQL or metadata."
This single paragraph contains the key to understanding why some AI products feel magical while others feel frustrating. It's not about model capability. It's about context and intent.
Let me explain.
The Problem OpenAI Was Trying to Solve #
Inside OpenAI, an internal stakeholder described a common frustration: "We have a lot of tables that are fairly similar, and I spend tons of time trying to figure out how they're different and which to use. Some include logged-out users, some don't. Some have overlapping fields; it's hard to tell what is what."
This isn't a problem that a smarter model solves. GPT-5 won't magically know which database table to use if it doesn't have the right context. The solution OpenAI found was to feed their agent not just metadata about tables, but the actual code that generates those tables, internal documentation from Slack and Notion, and human annotations from domain experts.
When the agent could read the pipeline code, it suddenly understood what "daily active users" really meant — which users were counted, which were excluded, what timezone was used, how fresh the data was.
This is the core insight: AI's ceiling isn't determined by model intelligence. It's determined by context quality.
Two Pillars: Context and Intent #
If I had to reduce AI product design to its essence, I'd say it comes down to two things: helping AI understand the full context, and helping AI infer the user's true intent.
These two concepts are deeply connected. Context is what allows AI to correctly interpret intent. And intent is what determines which context actually matters.
Let me unpack each one.
Context: More Than Just Conversation History #
Most people think of context as "what was said earlier in the conversation." That's part of it, but it's the smallest part.
Think about it this way. When someone asks an AI "What's the DAU?" — the conversational history might tell you they're working on a report. But that's not enough. The AI also needs to know which product's DAU, how DAU is defined in this company, whether the data includes test accounts, how recently it was updated, and whether there are multiple similar metrics that might be confused.
OpenAI's breakthrough was recognizing that real context comes in layers. There's metadata — the basic description of what data exists. There's code — the logic that actually produces the data. There's documentation — the human explanations of why things work the way they do. And there's institutional knowledge — the tribal wisdom scattered across Slack threads and meeting notes.
When you only give AI the metadata, you're giving it the "what." When you add the code, you're giving it the "how." When you add documentation and annotations, you're giving it the "why."
Most AI products today only work with the "what." That's why they often feel shallow.
Intent: Beyond What Users Say #
Here's something linguists have known for decades that AI product designers often forget: what people say is not the same as what they mean.
If someone says "This room is cold," they're not making a meteorological observation. They're asking you to close the window or turn up the heat. The literal content is a statement about temperature. The actual intent is a request for action.
This gap between literal meaning and true intent is where AI products often fail. The user asks "What does this code do?" and the AI explains the code. But maybe the user's real intent was "I want to modify this code but I'm afraid to break it." A truly helpful AI would recognize that and offer guidance on safe modification, not just explanation.
I find it useful to think about intent on two levels. There's task intent — what output does the user want right now? An explanation, a recommendation, some code, a decision? And there's goal intent — what is the user ultimately trying to achieve? Save time? Reduce risk? Learn something? Make a confident decision?
Many AI products only address task intent. The great ones address goal intent.
The Information-Theoretic View #
There's a deeper way to understand why context matters, and it comes from information theory.
Every time a user sends a message to an AI, that message carries uncertainty. The same words can mean different things in different situations. "Apple" could be a fruit, a company, or a reference to a movie. Without context, the AI has to guess among many possibilities.
Context reduces this uncertainty. Each piece of relevant context narrows down the space of possible meanings. When you tell the AI you're discussing tech stocks, "Apple" suddenly has only one plausible interpretation.
This is why the OpenAI team found that adding pipeline code dramatically improved their agent's accuracy. The code didn't just add information — it eliminated entire categories of ambiguity. The AI no longer had to guess what "active user" might mean because it could see exactly how the calculation was done.
From this perspective, the job of an AI product designer is to figure out which context most efficiently reduces uncertainty about user intent. Not all context is equally valuable. The best context is whatever maximally disambiguates what the user actually wants.
The Pragmatic View #
Information theory tells us why context helps, but it doesn't tell us what intent really is. For that, we need to think about language differently.
Philosophers of language distinguish between semantics — the literal meaning of words — and pragmatics — the meaning in context of a particular conversation and situation.
When your friend says "Nice weather we're having" during a thunderstorm, the semantics are about pleasant weather. The pragmatics — the actual meaning — is sarcasm about how terrible the weather is.
AI products that only understand semantics produce responses that are technically correct but miss the point. AI products that understand pragmatics produce responses that feel genuinely helpful.
The OpenAI data agent does something clever here. When an analyst asks "Can I use this table?", a purely semantic interpretation would yield a yes or no answer. But the agent, because it has read the code and understands the context, might respond: "Yes, but note that this data has a 2-hour delay, which might matter for your use case."
That "but" is pragmatics in action. The agent understood that the real question wasn't just about permission, but about suitability. It anticipated a concern the user didn't explicitly express.
Designing for Context and Intent #
So how do you actually build products that handle context and intent well?
Start by mapping the context landscape for your domain. What information exists that could help the AI understand user requests? For a data product, that might be schemas, code, documentation, and usage patterns. For a writing assistant, it might be the user's previous work, their stated preferences, and the context of what they're writing for. For a coding tool, it might be the full codebase, commit history, and issue tracker.
Then ask: how much of this context can be gathered automatically versus requiring user input? The best AI products are ones where context flows in naturally, without the user having to explain everything from scratch each time.
Next, think about intent at both levels. What are the common task intents in your domain — the immediate outputs users want? And what are the deeper goal intents — the reasons behind those tasks?
Design your interactions to clarify intent when it's ambiguous, but do so efficiently. Don't interrogate users with twenty questions. Find the one question that most reduces uncertainty. Or better yet, make a reasonable assumption and let the user correct you if needed.
Finally, build trust through transparency. When the AI acts on inferred context and intent, show its reasoning. Let users see what assumptions were made. Make it easy to correct misunderstandings. The OpenAI agent does this by explaining its reasoning alongside its answers, so users can verify the logic rather than blindly trusting the output.
Why This Matters More Than Model Improvements #
There's a reason I think the OpenAI data agent article is more valuable than a GPT-5 announcement would be. Model improvements are incremental. They make AI a little smarter, a little more capable. But they don't change the fundamental architecture of how AI applications work.
Understanding context and intent changes everything. It tells you what to build, how to structure your product, where to invest your engineering effort.
If you're building an AI product and spending all your time on prompt engineering, you might be optimizing the wrong thing. The bigger lever is often context engineering — figuring out what information the AI needs and how to get it there.
The companies that win in AI will be the ones that build the best context pipelines, not the ones that write the cleverest prompts. They'll be the ones that deeply understand their users' intents, not just their words.
A Framework for Practice #
Let me leave you with a simple framework I use when thinking about AI products.
For any AI feature, ask four questions:
First, what context does the AI need to do this well? Map out all the sources of relevant information — user data, domain knowledge, external facts, conversation history. Then figure out how to make that context available.
Second, what intents might users have when using this feature? Think beyond the obvious task intent to the deeper goal intent. What are they really trying to accomplish?
Third, how will the system handle ambiguity? When context is incomplete or intent is unclear, should it ask for clarification, make an assumption, or present multiple options?
Fourth, how will users verify the AI understood correctly? What transparency and correction mechanisms exist?
These four questions — context, intent, ambiguity, and verification — form the core of AI product design. Everything else is implementation detail.
Closing Thought #
We're at an interesting moment in AI. The models are becoming commoditized. Everyone has access to GPT-5-class capabilities now. The differentiation is moving up the stack, to how you structure context and how you understand intent.
The OpenAI data agent article is a window into how one of the leading AI labs thinks about this problem internally. They're not relying on model magic. They're doing the hard work of organizing information, understanding their users, and building systems that bring the right context to bear at the right moment.
That's the work that matters now. And it's work that requires deep thinking about your specific domain, your specific users, and your specific data. No foundation model can do it for you.
The age of "just use GPT" is ending. The age of thoughtful AI product design is beginning.