Shared context needs clear boundaries

Useful AI work depends on context: the brief behind a request, the decision that changed a deadline, the guidance that explains how a company handles a situation. Giving an agent more information also means deciding whose information it may read and who may receive the result.

Treat shared context as a publishing decision. Someone should be able to explain what was shared, why it is useful and which audience is allowed to use it.

Name the audience first

A personal conversation, a project brief and a company policy have different audiences. Putting them in one search experience does not make their permissions interchangeable.

Before adding material to a shared knowledge collection, name its intended readers. A project team may need a working brief that the rest of the company does not. A company guide may contain an approved lesson from that project without including the discussion that produced it.

Give someone responsibility for that decision. A folder title such as “team knowledge” is not enough to establish that every document inside it is suitable for every team member or agent.

Give the task the context it needs

Start with the work the agent has been asked to do. Identify the sources necessary to complete it, then check whether the person or agent doing the work has permission to use those sources.

Access to a document and permission to pass its contents to another audience are separate questions. A summary can still reveal a private fact. Rewriting the fact does not make it appropriate to share.

At Lodge, we design around personal, project and company context having distinct boundaries. An agent should receive context authorized for its actor, task and run. Summaries and search indexes should respect the source's access, revision and deletion rules too.

Publish a useful lesson deliberately

Imagine an account team preparing guidance for handling a common onboarding delay. One team member has private notes about a particular customer. The project drive holds an approved process document. The company needs a general guide that other teams can follow.

The first step is to choose what belongs in that guide. The project owner could approve the process steps and remove details tied to the customer's circumstances. Someone responsible for the wider audience then reviews the proposed guide before publication.

The resulting guide should identify its owner and source. An agent helping another team can work from that approved version, subject to its access rules. It should not need the private notes or assume that publication of the guide opened access to the whole project.

Keep context current

Sharing has a lifecycle. Guidance gets replaced, projects close and people change roles. Record who maintains a shared document and how readers can tell which version is current.

When a source changes or access is removed, ask what happens to summaries and other copies derived from it. Include those copies in the review instead of assuming the original document is the only place the information exists.

A useful starting exercise is to choose one shared brief and answer four questions: who owns it, who may read it, which tasks may use it and what happens when it changes. If any answer is unclear, settle it before widening access.

Our security principles provide more context for thinking about company authority and access. Clear boundaries give teams a concrete basis for deciding what to share next.