Production agents need institutional context

OpenAI published Inside OpenAI's in-house data agent on 29 January, and the bit I found most interesting was all the stuff around the model. The agent pulls from metadata, table lineage, historical queries, human annotations, code, internal documents, remembered corrections and live inspection, and access follows the user's existing permissions. That's a lot of maintained context for something that looks like you just type a question in.

Most organisations thinking about an internal agent have some of those pieces already, but they're spread across different systems and owned by different people. A model can guess what a table is from its columns. It can't reliably know that a field leaves out a certain kind of transaction, or that a metric's definition changed last quarter. That sort of thing lives in pipeline code, operating notes and people's corrections, so throwing every document you've got into retrieval doesn't really fix it. I'd want each context record to say what it describes, where it came from, who owns it, when someone last checked it and who's allowed to retrieve it.

Ownership is the awkward one. Say a column called active_customer comes out of exclusions and time windows that only show up in the pipeline code. The data team owns the schema, finance owns what "active" means and engineering owns the code that works it out. If nobody owns the combined description, the agent can hand back a definition that's technically current and still wrong for how the business uses it. OpenAI describes using code-level definitions to enrich what its agent knows about tables, and I think the same idea works outside analytics: if the agent says a figure refreshes daily, you should be able to click through to the source that says so.

Permissions have to travel with each source too. The retrieval service should check the current user's access before it returns a document, a table description or a saved memory, and caches need the same check (a cache built under a broad service account can quietly get around everything else). One way to test it is to ask the same question as two different roles, then remove someone's access and ask again to see whether old embeddings or memories still leak the answer.

Saved corrections have a similar problem. They stop the agent repeating a mistake, but they can also keep a workaround alive after the underlying system has changed. A correction should record the original issue, the fix, its source, who approved it and where it applies, and the person making it should be able to see whether anything was actually saved and how to remove it. Before connecting another source, I'd write a few lines for it answering these questions:

• What questions is it meant to answer?
• Who owns its meaning and its access rules?
• How will the agent notice it's gone stale?
• What can a reviewer click through to?
• What happens to saved context when someone's access is removed?

That's what I'd take from OpenAI's write-up if you're building an internal agent: most of the work is in the context around the model, and it only stays useful if someone owns each source, permissions follow the user and corrections can be seen and undone. So I'd answer those questions for one source, try it on one narrow task, and only widen retrieval once a reviewer can click through to where each answer came from.