Protocol InstituteBusiness

Business Protocol Management

Research · practice guide by Rafael Fernández for the group · Markdown for agents

Companies that work well with AI build a few strict rules into their systems and give people and agents wide freedom inside them. Business Protocol Management (BPM) is the practice of finding those rules, building them, and changing them as the business grows.

A hexagonal hard core, with free agents moving around it

1. About this guide

2. Key terms

3. The case for change

The problem

Management grew up around the span of control: one manager directing a handful to a few dozen people and approving decisions one at a time. A small team can now run hundreds of thousands of agents, working at machine speed and around the clock. No manager can supervise that many, and no approval queue keeps up.

Agents also coordinate through whatever they can read and write, whether or not anyone designed it. Two 2026 reports show this:

“The models first found ways to communicate by writing files into the Artifactory package manager. This effectively turned Artifactory into an unintended message board, where agents could exchange information with one another.”

OpenAI, The Hugging Face incident and the road ahead

“We consistently saw a multiagent turf war. All of the models we tested quickly assumed that others were purposefully impeding their work, and began to sabotage others while protecting their own contributions.”

Anthropic, Patterns and problems in multiagent systems

Agents as nodes, with messages moving between them

The response

At this scale, a manager’s reach comes from the environment the agents work in, not from supervising each one. One well-built rule governs every agent that passes through it, whether there are ten or a million. Like guardrails on a mountain road, strict rules in the right places let the business move faster: a team can let an agent act without approving each step, and a partner can connect through an agreed interface instead of a long integration project.

Three Braitenberg vehicles around a light: wired one way a vehicle turns away, wired crossed it charges the light, wired to slow down it comes to rest facing it

Amazon shows the pattern. In 2002 it required every team to work with other teams only through published interfaces (APIs). The interfaces became hard, and each team stayed free to build whatever it liked behind them. The rule slowed teams down at first, then made the company faster and laid the groundwork for Amazon Web Services.

Assumptions to test

The group’s research rests on three assumptions. Each could turn out partial or wrong, and the sessions and case studies test them.

  1. Reading and writing get cheap. Processing documents, forms and rate sheets, and producing software, cost a fraction of what they did.
  2. Agents act, in large numbers. Models take actions, and many copies run at once wherever work is done.
  3. Information flows through models. People and agents increasingly find, read and exchange information by way of AI models and the protocols that connect them.

4. Principles

  1. Keep the hard core small. Every hard rule costs flexibility. Make hard only what everything else relies on.
  2. Put strict rules where teams meet. Interfaces between teams, agents and partners are where reliability matters most: who may move money, what data leaves the company, which checks every output must pass.
  3. Leave the inside of each team free. People and agents doing the work know things designers don’t. Freedom inside the core is where better ways of working are found.
  4. Record the reason at the moment of action. A change can’t ship without its reason, and an agent records the instruction it acted on.
  5. Don’t blame people for what the record shows. Blame produces empty reasons and workarounds. Give credit for surfacing what works as much as for flagging what broke.
  6. Manage tensions; don’t try to settle them. Speed pulls against reliability, sales against finance. A good protocol turns the pull from each side into progress on both.
  7. Change the core by a written rule. Each hard protocol names who may change it, how, and who may stop the work.
  8. Count what didn’t go wrong. Good protocols produce non-events. Measure them next to speed and growth.

5. Roles and responsibilities

Suggested roles. A small company may give several to one person.

6. The three phases

A loop of three phases: See, then Design, then Evolve, and back to See

Phase 1: See

Phase 2: Design

Template: hardness map

An example for a company adopting AI agents. For each protocol, note the tension it manages, where it lives, and who can change it.

Three rings: a small hard core in the middle, soft norms around it, and free work outside
ProtocolTensionTypeWhere it livesWho can change it
Who may move moneySpeed vs. controlHardPayment permissions and limitsFinance lead
What data leaves the companyOpenness vs. confidentialityHardAccess permissions and outbound checksSecurity lead
Checks on every agent outputSpeed vs. qualityHardEvaluation pipelineProduct owner
The shared field logVisibility vs. privacyHardWritten by every system and agentPlatform team
Weekly planningAlignment vs. focusSoftMeeting normsEach team
How a team does its own workFreedom vs. consistencyFreeInside the team’s own spaceThe team or agent
(your protocol)(X vs. Y)Hard, Soft or Free(system, norm or space)(owner)

Phase 3: Evolve

7. Measures

An append-only log: numbered lines, one highlighted

8. Worked example: California water rate data

Signals spreading from a few sources, lighting up the readers they reach

Led by Patrick Atwater and Maxwell Titsworth with the California Data Collaborative

Other cases: construction procurement protocols, working smarter with AI (whose hazards collection separates hard walls, which block an action, from soft walls, which flag it for review), and the Protocol Institute brand kit. All are on the case studies page.

9. How BPM relates to earlier approaches

A crack running across an orderly grid of blocks

Safety-critical industries are the closest model. Airlines and nuclear plants accept that they can’t fully predict their systems, so they manage safety through protocols: confidential self-reporting, investigations that look for causes rather than culprits, checklists, and the right to stop the work. US airlines must now run formal safety management systems (14 CFR Part 5). Changing a protocol changes results in both directions: the WHO surgical checklist cut deaths in its pilot study from 1.5% to 0.8%, and removing the hardware interlocks from the Therac-25 radiation machine led to massive overdoses. Business can adopt the loop without copying its weight. Most business mistakes don’t kill anyone, so companies can learn by trying things inside their free areas.

10. The 2027 program

The group tests BPM through its 2027 focus, AI-native data operations. Sessions run every other Monday at 15:30 UTC from 2 November 2026 and are recorded. Each reads one primary source closely. The themes below are where the program starts; participants shape the readings, guests and cases as it goes.

Ways to take part: offer a talk, carry a case study through the year, log protocols with the protocol watching guide, or suggest or challenge a reading. The full plan is on Sessions.

11. Sources