Superintelligence for Two Locations: Shared Memory, Separate Permissions

A two-location business can run one superintelligence layer: a shared set of AI agents that draw on common memory, tools and operating rules, while each site keeps its own permissions, records and approval path. The right starting scope is one useful role, the memory and tools that role needs, explicit limits on what it may change without sign-off, and one success criterion per site. Sharing only helps where the two locations truly work the same way, so the design begins by separating what is common from what belongs to one place.

Key takeaways

• Share what is truly common to both sites, such as policies, product definitions and standard procedures.
• Keep staff records, local customer history, supplier contacts and site inventory scoped to the location that owns them.
• Start with one role and the smallest set of tools it needs, not a company-wide agent with broad access.
• Give each site a named approver and a written rule for what the agent may change without that approval.
• Measure success with one criterion per site and review permissions on a fixed date.

Why two locations change the design

A single site can get by with informal memory. The owner remembers the supplier schedule, the manager knows which regular customer prefers a certain table, and the team fixes small inconsistencies by talking to each other. A second location breaks that habit. Menus, opening hours, staffing rules, delivery windows and local promotions begin to diverge, and an agent that answers from one undifferentiated memory will eventually give one site the rules of the other. The failure is rarely the model. It is that nobody decided which facts belong to the company and which belong to a specific place.

The design question is therefore not how to connect everything. It is which knowledge is one fact for the whole company, and which knowledge has an owner at a specific site. Answering that question before any agent is built is the cheapest step in the project, and it usually reveals whether a shared layer is worth building at all for the process in question.

Decide what is shared and what stays local

Use the following split as a working draft. Some items will not fit neatly, so mark the uncertain ones and settle them with the site managers.

• Shared across both sites: company policies, brand voice, definitions of products and services, standard operating procedures, and the internal glossary the team uses.
• Local to one site: staff rosters and schedules, site inventory counts, local supplier contacts, local customer history, and site-specific availability notes.
• Shared with local overrides: procedures that are mostly identical but carry a documented local exception, such as a different cleaning schedule or a longer appointment buffer at one location.
• Not shared with the agent by default: payroll, personal data about staff, banking details, and contracts signed for one location only.

Every item needs an owner, meaning the person who can approve a change to that fact. For shared knowledge this is usually the owner or a head office lead. For local knowledge it is the site lead. Without named owners, the shared memory fills with conflicting notes, and nobody can tell which one is current. The map of layers in Draw Your AI Stack: A One-Page Architecture Map for Leaders is a useful place to record these owners before you connect any tool.

Give each site its own memory boundary

Shared memory and local memory should be stored separately and combined only at retrieval time. When a question arrives, the agent should search the shared library and the records tagged to the site where the question was asked, or to a role that has been explicitly granted access to several sites. A manager at the first location should never receive the second location's inventory counts because the agent happened to find them in a convenient place.

This is a retrieval design, and it matters more than the size of the memory. Tag each document with its location and owner, keep the shared library short and reviewed, and require the agent to say which source it used. When an answer depends on a local note, the answer should show that dependency. This habit makes errors visible: if a recommendation cites a note that nobody has reviewed for a long time, the reviewer can spot the staleness immediately.

Keep the context the agent receives small and relevant. Loading every document from both sites into every conversation increases the chance that a reply mixes facts from the wrong place. The principles of [context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) describe why a narrower, well-chosen context usually produces more reliable answers than a large one.

Scope tools and permissions for each site

Memory is only half of the picture. The tools an agent can call, such as a booking system, a stock sheet, a shared inbox or an accounting export, determine what it can actually do. Give each tool a scope per site. Read-only access to one location's stock is a different permission from write access to a shared ordering system, and the two should never be granted together by default.

Avoid a single master credential that the agent uses for every site. Instead, the agent should act with the access rights of the person or role it is serving, and anything not explicitly granted should be unavailable. This follows the general guidance in the [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html), which favors denying access by default and limiting each grant to what is needed. Each grant should then have a named reason, so the later permission review is a reading exercise rather than an archaeology project. The steps for that review are set out in How to Run a Permission Review for Your AI Agents, Step by Step.

Write actions deserve their own rule. Drafting a supplier order for a site manager's approval is a different permission from sending the order. Decide, for each tool, which actions the agent may take alone, which require a human approval, and which it may never take. Put that table in writing before go-live, because it is the document you will check when something goes wrong.

Keep records and audit trails separate by location

Each action the agent takes should leave a record that states which site it concerned, which user or role requested it, which sources it used, which tool it called and whether a person approved it. Observability practice treats this kind of structured trace as the basis for diagnosing any system, and the same trace is what a site manager needs when a reply looks wrong. The concepts in the [OpenTelemetry observability primer](https://opentelemetry.io/docs/concepts/observability-primer/) are a good reference for what to capture.

Keep records split by location as well. A combined log is acceptable for the central operations team, but a site lead should see only the entries for their own site unless the company has decided otherwise. Set a retention period for each type of log and test it. A useful test is to ask a simple question and check that the log answers it: what did the agent do for the second location last week, and who approved each change?

Records also support the review cycle. When the agent's permissions, sources or approval rules change, the change should be logged with its reason and its approver. This is what allows the two locations to trust the shared layer over time, because they can see how it changed rather than discovering the change in a surprising reply.

A starting scope for two sites

Illustrative scenario: an owner runs two cafés and wants help with weekly supply orders. The agent reads each café's stock sheet, compares it with a shared list of standard items, and drafts an order for each site. It sends each draft to that site's manager for approval. It may not place an order, change a supplier contact or edit the shared item list. Success is measured per café: the manager approves the draft with only minor edits, and the stock sheet is updated before the draft is produced.

The starting checklist for a two-site deployment is short:

• Name the one role, its users at each site, and the things it must never do.
• Split the knowledge into shared and local, with a named owner for each item.
• List every tool the role needs, with the read or write scope for each site.
• Define the approval step for every write action and the person who holds it.
• Choose one success criterion per site and a date for the first review.
• Set the log retention and the permission review schedule before go-live.

Be Human designs, implements and operates this kind of layer as a managed service. The first engagement defines the single role, the memory and tools it needs, the approval boundaries and an observable success criterion. Managed operations then cover monitoring, recurring evaluations, integration maintenance, permission review and controlled changes, so that the shared layer does not drift away from the rules each site depends on. The service is delivered remotely in English or Portuguese. Staff at both sites also need a clear way to use the agent, and How to Get Your Team to Actually Use an AI Agent covers that side of the rollout.

If you want to find the first task worth handing to an agent across your two sites, take the free Be Human AI diagnostic.

Frequently asked questions

Can one AI agent serve both locations? Yes, a single agent can serve two sites if its memory is tagged by location and its tools are scoped per site. It should answer company-wide questions from shared sources and local questions from the records of the site that asked. Separate permissions and logs keep one location's data out of the other location's answers.

Should each location have its own agent instead? Sometimes that is the better choice. Separate agents are simpler when the two sites differ widely in procedures, staff or systems, but they duplicate maintenance and tend to drift apart over time. A shared agent with a local layer usually suits two sites that run the same core process with a few documented differences.

How much access should a site manager have to the shared layer? A site manager should be able to read shared knowledge that affects their work and propose changes to it, while approval for shared facts stays with one named owner. Their access to another site's records should be none unless the company has explicitly granted it. Review those grants on a fixed schedule, not only when a problem appears.

What should we measure in the first month? Choose one observable criterion per site tied to a real task, such as the share of drafts approved with only minor edits or the time a routine check takes. Also track whether the agent cited a stale or incorrect source. Review the criteria and permissions together on a set date before you expand the agent's scope.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.