V7’s Context Graph connects the evidence across company files

OpenAI's September 21 V7 customer story describes a way to make company documents more useful to AI agents: extract their information into a Context Graph that connects entities, relationships, and cited evidence. For teams whose work depends on joining facts across files, the useful question is whether those connections reduce the effort of finding and checking an answer.

This is a customer account of an existing workflow, not an announcement that every company can switch on the same system today. Its practical value is the design it describes. Adding more documents gives an agent more material. Organizing how those documents relate can help it answer a different kind of question.

From separate files to connected evidence

V7 says its Go platform uses GPT-5.6 Luna to extract information from files and organize it in the Context Graph. The graph connects entities, their relationships, and the evidence behind them. It supports search through MCP, the Model Context Protocol, and repeatable workflows. Other models handle work that requires more reasoning or tool use.

An entity is a particular thing the business needs to distinguish: a company, property, policy, or agreement. A relationship connects it to something else. In document work, that distinction matters because finding two relevant passages does not establish that they refer to the same company or the same version of an agreement.

A graph makes those connections part of the information the system can use. The cited evidence gives a reviewer somewhere to go when a connection needs checking. V7's own product site focuses on document-heavy work in private markets, insurance, and real estate, including diligence, policy review, and lease abstraction.

That structure is different from saving instructions for a recurring task. Our discussion of reusable Copilot Cowork workflows covers how a team can standardize what an agent should do. A document graph instead organizes what the agent can know about the records involved. A useful workflow may need both.

Start with a question that crosses document boundaries

For a team considering this approach, we recommend starting with a real business question whose answer cannot be checked in one file. The question should have a known answer and supporting records that your reviewers are permitted to inspect.

For example, an evaluation could ask which current agreements are affected by a change to one contracting entity. The required work is more specific than finding that entity's name. A correct answer needs to distinguish similarly named organizations, connect each agreement to the right party, and account for amendments that change the relevant terms. This is an evaluation example, not a reported V7 customer result.

Compare that task with the way your team answers it now. Record the documents found, the connections made, and the time a reviewer needs to confirm the result. If ordinary search already produces a short, unambiguous answer, building and maintaining structured relationships may add little value. If the work repeatedly requires people to reconstruct the same relationships across many files, the graph approach has a clearer purpose.

Check the connections as well as the quotations

A citation can accurately quote a document while the answer uses that document for the wrong entity. It can also point to a valid historical record when the question asks about current terms. Those are errors in how evidence is connected and applied, rather than simple transcription errors.

Our recommendation is to make those cases visible in the evaluation. Include records with similar names, a superseded agreement beside its replacement, and a question for which a required relationship cannot be established from the available files. A useful answer should explain what is missing instead of silently filling the gap.

When an answer is wrong, trace where it went wrong. Did extraction miss a field? Did the system join records that describe different entities? Did the final answer ignore a qualification that was present in the evidence? These distinctions help determine whether the next change belongs in document preparation, relationship handling, or answer generation.

This is guidance for evaluating document systems generally. The customer story does not establish that V7 has those failure modes, nor does it provide enough detail to promise how another company's files will perform.

Treat the customer results as a reason to investigate

OpenAI's story reports V7's measurements for document costs, tool use, and difficult graph queries. Those results describe V7's workloads and testing. They do not settle whether your records are sufficiently consistent, current, or accessible for the same approach.

The buying decision should therefore include the work needed to keep the graph useful. Ask how corrections to source files reach extracted information, how a reviewer can challenge a connection, and what happens when a source is removed or a user's access changes. The pages reviewed here do not establish those implementation details; ask the supplier to demonstrate them with the workflow you intend to run.

For the first evaluation, choose one recurring question with difficult but reviewable connections. Keep the existing search process as a comparison, and assess both answer quality and review effort. The point of organizing company knowledge is to make a correct, checkable answer easier to obtain—not merely to give the agent a larger memory.

Sources

• OpenAI: How V7 gives AI agents institutional memory, September 21, 2026. Source for V7's described architecture and model roles.
• V7 Go product overview, accessed September 21, 2026. Source for the document workflows and sectors V7 describes.

The evaluation examples and recommendations are BaristaLabs guidance, not independent measurements of V7.