After OpenAI File Search: hand evidence to your team

OpenAI File Search can help an agent answer questions about uploaded contracts, policies, and product documents. The next person on the team still needs to know which source supports the answer, whether someone accepted the conclusion, and which version should guide future work.

Copying an answer into chat leaves that handoff fragile. Writing it straight into a business record may give a retrieved passage more authority than it deserves. A useful handoff connects the evidence, the proposed change, and the record the team actually accepts.

File Search can provide retrieval while Busabase holds structured records and their change history. Your application or agent must explicitly coordinate those steps and map the output between the two systems.

Preserve the response layers separately

OpenAI’s File Search guide describes a hosted Responses API tool that searches uploaded vector-store files using semantic and keyword search. Prepare the files and indexing first, then enable file_search with the appropriate vector_store_ids.

The response can contain a file_search_call item and a message with file_citation annotations. Extract file_id, filename, and citation position from the structured annotations. A displayed footnote number is a presentation detail; it is a poor substitute for a stable source identifier.

Search results are not returned by default. Request include: ["file_search_call.results"] when your application needs the retrieved material for review. Citations associate an answer with files; returned results help a reviewer inspect supporting passages. Neither establishes that a passage supports every assertion in the generated answer.

Give evidence and conclusions their own records

A practical starter setup is one Folder containing an Evidence Base and a Conclusions Base. Reuse an existing business table for conclusions when it already owns the relevant facts.

In Evidence, use a short title as the primary field. Add file identifier and filename as text, source location as a URL, relevant passage as long text, collection time as a date, and response identifier as text. A source location should lead to an original that the team is allowed to open. An OpenAI file_id is not a public download URL.

In Conclusions, store the question, current conclusion, a relation to evidence, business status, and responsible person. One conclusion can cite several evidence records. Business status describes the team’s decision; in_review, approved, and merged describe the lifecycle of a proposed record change.

Preserve a source version or content digest when the source system provides one. Files can be replaced without changing their human-readable names. Keeping the original location and collection context gives later reviewers a way to identify what informed the decision.

Read before proposing a change

Before writing, look up the existing conclusion and read its current version. Decide whether the result adds support, corrects a previous conclusion, or answers a different question. A stable topic identifier helps prevent each scheduled run from creating another near-duplicate record.

Give a connected agent an instruction such as:

Read this File Search response, its structured citations, and the returned search results. Find the existing topic in the specified Evidence and Conclusions Bases. Associate each proposed assertion with its supporting passage and file identifier. Preserve contradictory material. Read the current conclusion and version, then propose only supported field changes and return the proposal link.

This instruction assumes the application has actually connected the required tools. Busabase MCP provides a connection surface; OpenAI file access and Busabase record access still need their own permissions. Access to one system does not grant access to the other.

Make waiting for review explicit

Busabase Change Requests preserve the proposed changes and their commit history. A proposal-only changeRequest credential causes writes to wait for review. A writer with write access may merge a CR as soon as it is created. Use the proposal-only permission, or explicitly request autoMerge: false in a supported call, when this handoff must wait for a person.

The reviewer should compare proposed field values with their evidence, check whether the source remains applicable, and inspect contrary passages. If another actor updated the record while the proposal was being prepared, recheck the baseline before accepting the change.

Approval and merge are separate states to verify. After merge, reread the canonical record and check both the conclusion and its evidence relations. The broader division between retrieval and accepted records is explained in agent memory, knowledge bases, and systems of record.

Define what the next run reads

Routine execution should read the merged conclusion and linked evidence. Read pending proposals only within an explicitly scoped review process. If acting also requires a business status such as confirmed, enforce that condition separately; merged data alone does not authorize an external action.

When the source changes, retrieve again and compare it with the accepted conclusion before proposing an update. After an ambiguous timeout, inspect the original proposal and current record before retrying. Retaining response and topic identifiers makes recovery easier and reduces duplicate creates.

Start with one real question

Choose a question with an accessible source, an existing team record, and a clear decision owner. Check that indexing has completed, citations resolve to the intended material, pending writes behave as expected, and a later read returns the accepted version after merge. Keep sending messages and taking business actions under their existing authorization.

Once this manual cycle works, expand the source collection and automation deliberately. The useful outcome is a decision that another person or agent can inspect and continue using with its evidence intact.