Illustrative scenario. A twelve-location network puts an AI agent in front of customers. Six weeks later there are twelve versions of the agent: every location has tweaked the instructions “just a little”. One grants refunds at 45 days, another quotes summer hours in November, a third uses first names with a customer the brand always addresses formally. Nobody did anything strange. The same decision got made twelve times, and nobody actually made it.
The thesis in one line: in a multi-location network you don't choose which agent to buy, you decide what gets configured once and what gets adapted per location. The first you centralize, no debate; the second stays local, but as data, not as a copy of the agent.
AI for franchises and multi-location businesses: what do you configure once, and what do you adapt per location?
You configure once everything that defines how the agent behaves: decision rules, limits on what it can grant, tone, permissions, when it escalates to a person, and how it's evaluated. You adapt per location what really changes from one place to another: local catalog and prices, hours and holidays, the team each case goes to, local regulation and language. The question that orders everything else is simple: does this difference exist for a real business reason, or out of the location's habit? Only the first one earns a parameter.
What do you always centralize?
- Decision rules. Refund windows, maximum discounts, what can be promised and what can't. If every location has its own version, a customer who switches locations switches brands. How to write them is covered in the instructions of an AI agent.
- Permissions. Which systems the agent touches and how far. A permission granted at one location for convenience becomes a permission granted at all of them the moment someone copies the setup. The criteria are in the permissions of an AI agent.
- Tone and voice. It's what the customer recognizes as the brand. Define it once, test it once.
- Evaluation and logging. The same test battery for every location and a single place to see what the agent did. Without that you can't compare one location with another.
- Escalation. The rule for when the agent stops and hands over is central; who it hands over to at each location is local data.
What gets adapted per location (and how, without copying the agent)?
Local things come in as parameters the agent looks up, not as a different version of the agent. The difference sounds small and changes everything: a parameter is updated in one place and the change is visible; a copy has to be chased down.
- Catalog, prices and availability, which already live in each location's system or in the central one. The agent reads them; it doesn't remember them.
- Hours, holidays and temporary closures, with an expiry date so summer hours don't outlive the summer.
- People and escalation channels: who gets the case at each location, and through what channel.
- Local regulation and terms. What can be said or promised changes by place. In a network that spans countries, this is a parameter per market, never a figure or a rule copied from one to another.
- Language and form of address, when customers at one location expect something different.
One agent for all locations, or one per location?
The reasonable starting point is one agent with per-location configuration. One agent per location is only justified when the differences stop being parameters. The trade-offs, no makeup:
- One agent with per-location configuration. A policy change reaches every location at once and is evaluated once. The cost: a central error spreads across the whole network the same minute, and per-location configuration demands discipline about who can touch it and who reviews it.
- One agent per location. Each location adapts as it likes and a failure stays at home. The cost: twelve versions to maintain, twelve evaluations, twelve places where a rule can be out of date, and a year later you no longer know what each one does.
- A hybrid by country or by format. One agent per market or per type of location (store, clinic, workshop) with the shared part kept in common. It's the middle ground when regulation, language or systems genuinely change by group.
Keeping that set alive is an ongoing function, not a project you hand over: who updates, who reviews, and who answers when a location drifts. That's what scaling from 5 to 100 agents is about.
How do you roll it out without locations feeling it as something imposed?
- Start with two different locations, not the most convenient one. A big one and a small one, or one that sells and one that delivers a service. If the design holds up for two different cases, it holds up for the rest with adjustments.
- Give each location an owner with bounded power. They can change local parameters (hours, team, promotions); they can't change the central rules. If they need a rule changed, they propose it and it's decided once for everyone.
- Make visible what's central and what's local. One page with the two lists. Most conflicts with locations come from nobody knowing where their margin ends.
- Review drift, not every answer. A periodic sample per location is enough to see who departs from the rules and why.
In a franchise there's also a layer that isn't technical: what the contract lets the franchisor impose on the franchisee and what it doesn't, and who answers to the customer if the agent gets it wrong. That's settled with the contract and legal advice, not with a prompt. What you can do from the design side is make it clear who owns each rule, as laid out in governing AI agents in the company.
How do you measure it per location?
With the same test battery at every location and results split by location. The reading is direct: if a failure shows up at just one location, it's a local configuration problem; if it shows up at several, it's a central rule to fix. Without that split, a central error looks like a local anecdote and a local error looks like an agent failure. The general framework for ordering who controls what is in governance and control of AI automation.
When should you NOT centralize?
When the locations are, in practice, different businesses: a recent acquisition with different systems, another brand, another audience, or regulation that changes what the agent may say. Forcing one common agent there produces an agent that serves nobody. It also doesn't pay off with two or three identical locations: configure one agent well and copy the result by hand while that's manageable. Centralization is paid for in discipline, and that discipline only pays off once the number of locations makes the alternative unsustainable.
The line to take away: don't ask how many agents you need, ask how many versions of your rules you're willing to maintain. If the answer is “one”, everything else is a parameter.
Note: this article uses no third-party figures. A franchise's contract terms and local regulation depend on each case and each country; get legal advice before deciding what to impose on each location.