Stop the mixing before documents reach the assistant: verify the staff member’s company access, select an authorised company context and restrict retrieval to that company’s approved evidence. Then check that every source used in the answer belongs to the selected scope. A prompt saying “keep companies separate” should support these controls, rather than carry the whole responsibility.
The practical decision is where to enforce that boundary and how to prove it works when two companies have almost identical policy names. This is a focused custom AI agents design problem within AI automation.
Establish the company before searching
Give each company a stable identifier. Display names can change, and subsidiaries may share branding. A document called “Travel Policy” tells you its topic; it does not establish which company owns it or who may read it.
The proposed workflow should obtain company membership from an authenticated access record controlled by your application. If someone belongs to several companies, let them select an active company from their authorised options. Display that selection beside the conversation so they can see which organisation the answer concerns.
A typed request such as “answer for Company B” must not grant access to Company B. Validate the requested switch against the person’s permissions before retrieving anything. If membership cannot be verified, stop retrieval and direct the person to the access administrator.
Also distinguish company access from applicability. Someone authorised to read both companies’ policies may still need the policy for a particular employer, contract or assignment. Where that remains unclear, ask which authorised company the question concerns before answering.
Choose a retrieval boundary your team can inspect
Two proposed designs are worth comparing:
- Separate company collections: the application selects only the authorised company’s document store. This makes the selected search scope easy to inspect, but requires maintaining separate collections.
- A shared collection with mandatory company filtering: every searchable document carries a verified company identifier, and every search applies the authorised scope. This requires dependable tagging and checks that no search path omits the filter.
OpenAI’s file search documentation describes searching uploaded files in vector stores using semantic and keyword search, selecting vector stores and applying metadata filters. These are building blocks; your application must establish the company boundary. Source: OpenAI file search
For a small initial project, separate collections may be easier for a business owner to review. A shared collection may suit an existing document platform, provided the implementation can demonstrate enforcement. Neither arrangement makes an incorrectly assigned document safe.
If the application also stores policy records in PostgreSQL, row security can restrict which rows a role can access. Its documentation identifies important exceptions: superusers and roles with BYPASSRLS bypass those policies, and table owners normally do too. Verify the deployed version and actual service role before relying on this layer. Database controls do not automatically protect a separate search index. Source: PostgreSQL row security policies
Label company ownership before indexing
Use a document register that records company identifier, document identifier, title, policy owner, approval status, version and effective date. Company ownership determines the retrieval boundary; the remaining fields help identify the right evidence within it.
Treat unassigned files as pending review. Do not infer company ownership solely from folder names, logos or a filename suffix. Ask the document owner to confirm ambiguous files before adding them to searchable material.
Shared group policies need explicit applicability. Record which companies they cover and who approved that scope. If a group policy includes different company schedules, consider preparing separately approved company extracts, each retaining a reference to the original. Do not let retrieval silently combine a general rule with another company’s exception.
For duplicates, distinguish repeated copies from conflicting policies. A repeated copy can point to one approved document record. Two documents claiming to be current but giving different instructions need an owner’s decision. Upload order should not decide which policy governs.
Check the evidence before displaying an answer
Enforce the selected scope in the application’s retrieval step. A model-requested company identifier should be checked against the verified context, rather than accepted as authority.
OpenAI’s function calling guide describes a flow in which the model requests a tool call and application code executes it. That execution step is where a custom retrieval function should validate access and reject an unauthorised scope. The guide does not establish company separation for your implementation. Source: OpenAI function calling
After retrieval, check each result’s document identity and company applicability against the register. Reject unexpected results before they enter the answer context. Check citation links too: the user should not receive a link or preview exposing another company’s restricted material.
For company switches, start a fresh scoped conversation or remove previous company evidence before continuing. Apply the same boundary to stored summaries and cached answers. A correctly scoped new search does not resolve evidence retained from the previous company.
Company separation runbook
Use this proposed runbook for a pilot. Assign named owners before testing; it is a workflow specification, not a native product feature.
- Verify access: obtain the signed-in person’s authorised company identifiers from the application’s access records. If unavailable, do not search; refer to the access administrator.
- Select scope: require one active authorised company for an ordinary policy question. Show its name to the user. Clarify unresolved applicability before retrieval.
- Prepare documents: confirm company identifier, owner, approval status and document identity. Exclude unassigned, withdrawn or unresolved conflicting files.
- Restrict retrieval: select the company collection or enforce its mandatory filter. Allow shared policies only where their approved applicability includes that company.
- Inspect evidence: reject results outside scope before answer generation. Require supporting approved evidence for the policy statement.
- Present the answer: name the company and cite the supporting document. If evidence is missing or conflicting, explain the limitation and refer to the policy owner.
- Handle switches: recheck authorisation and remove previous company evidence from the active context and cached response path.
- Record the test: capture selected company, retrieved document identifiers, displayed citations, expected outcome and responsible reviewer. Keep restricted evidence accessible only to authorised reviewers.
Work through ordinary and difficult cases
Consider hypothetical companies Acacia Services and Beacon Trading. Both have an “Expense Claims Policy”. In this hypothetical example, Acacia’s policy gives staff 10 working days to submit a claim; Beacon’s gives 20. These figures are illustrative, not legal requirements or recommendations.
Ordinary question: an Acacia employee asks, “When must I submit my claim?” The application verifies Acacia access and retrieves Acacia’s approved policy. The answer states the hypothetical 10-working-day rule and cites that document. The reviewer confirms that no Beacon document entered retrieval or the answer context. Any decision about a late claim remains with the appropriate human.
Missing context: a shared-services employee has authorised access to both companies but no active selection. The assistant asks which company the claim concerns, without quoting either deadline. If the employee cannot determine applicability, the policy owner resolves it before an answer is offered.
Ambiguous document: a file titled “Group Expense Policy” has no confirmed company coverage. Exclude it from retrieval. The document owner identifies its scope and approval status; the administrator updates the register before indexing it.
Duplicate conflict: Acacia has two apparently current copies with different deadlines. The assistant should not choose whichever ranks first. It reports that the approved evidence is unresolved and refers the question to Acacia’s policy owner. The owner identifies the governing copy, then the search material is corrected.
Unauthorised request: an Acacia-only employee asks for Beacon’s deadline. Reject the requested scope without revealing Beacon’s policy content. An access administrator handles any legitimate access request.
Test similarity and scope changes together
Build paired questions that use the same wording in each company. Include identical titles, abbreviated company names, renamed businesses, shared policies and questions with no company mentioned.
Inspect retrieval results as well as displayed answers. A harmless-looking answer is insufficient evidence if forbidden material reached the model. Conversely, a blocked answer with permitted retrieval may indicate an answer-handling problem rather than a company-boundary failure.
Test a conversation that starts in Acacia and switches to Beacon. Repeat it with a cached answer available, then after removing the person’s Beacon access. Check that permissions are reassessed and earlier evidence cannot supply the next response.
A proposed pilot release rule is to block rollout after any observed cross-company retrieval or disclosure until the cause is fixed and affected cases pass again. Passing these cases supports a scoped release decision; it does not prove every future request is safe. Repeat relevant checks when access mappings, indexing or retrieval paths change.
FAQ: keeping company policies separate
Can we solve this by putting the company name in the prompt?
Use it as an instruction, but enforce access and retrieval scope outside the model. The AI agents versus automation comparison helps distinguish model judgement from fixed workflow rules.
Can authorised staff compare both companies’ policies?
Yes, as a separately designed comparison workflow. Verify access to both scopes, retrieve each independently and label each finding. Do not merge the policies into one instruction. Define this behaviour in your custom AI agent workflow.
What should happen when the correct company has no answer?
Keep the company boundary intact. State that supporting evidence was not found and send the question to that company’s policy owner. Do not borrow another company’s answer. The custom AI agent glossary explains the wider concept.
If your business needs help defining these boundaries, get in touch about a scoped pilot using a small approved library. Before deployment, check current product account, plan and region eligibility for the selected services.