What would protocol-centric consulting look like?

What would it mean to sell this? To find out, we spent two days building a landing page for an independent advisory network that draws on the group's research, at protocolvision.org. It is a draft, shared for feedback. The research here stays open and unpaid; the advisory is separate.

Writing a page that an operations lead reads in a minute turned out to be a good test of the ideas. Four things changed along the way.

Start with a question, not a service. The page opens with "Your business runs on protocols. Can you see them?" Every section ends with a question a reader can take back to work, such as "Which handoffs, approvals and permissions does your work actually depend on?" Seeing protocols is the first thing a client gets, before any advice.

The hard core looks shared. When we tried to show what "hard" means, the same eight protocols kept coming up: signing authority, spending limits, payment approval, access rights, change control, data out, output checks, and an audit trail. Most companies seem to have all eight, enforced to different degrees. This is a proposal, not a finding, and we'd like members to challenge it.

Risk and opportunity are the same object. The section on risk shows agents slipping around an approval step that can't keep up. The section on opportunity shows teams and partners building things nobody planned on top of a hard interface. Both are about the same thing: the few rules at the seams. A gap in the hard core is where an agent gets through; a well-made interface is where others build.

The first engagement can run on the client's own assistant. The page's main button copies one line for ChatGPT or Claude. The assistant reads the practice guide, asks a few questions and writes a short protocol report. It then offers an anonymised summary, which the reader checks before sending. The consultant starts from the client's own words, and nothing confidential leaves without consent.

How this differs from earlier consulting

Each earlier wave of management consulting sold a different thing.

• Re-engineering redesigned every process from the top, once. Protocol-centric work changes a few rules at the seams, leaves the inside of each team free, and keeps amending.
• Strategy work delivers a plan. The deliverable here is a set of rules that run in systems, each with an owner and a written way to change it.
• Process mining maps the steps people and systems actually take. The question here is narrower: which of those steps must hold every time, and which can stay free?
• AI agencies build agents toward a target. Protocol-centric work shapes the environment those agents act in, so it still holds when there are ten thousand of them.

Even the advisory's own setup tries to follow the practice. It is a network of independent consultants, not a firm, with one rule every engagement keeps: a field log from day one, shared with the client.

Open questions

• Is the hard core really shared across sectors? Does a water utility have the same eight as a construction firm or a software company?
• Can useful advice start from an anonymised summary, or does protocol vision need someone watching the work in person?
• Who takes a cut? A consultant paid by the day has a reason to make the hard core bigger. The practice says to keep it small. How should an engagement be priced so the incentives line up?

Bring answers, objections and counter-examples to the sessions, or reply with a blyg of your own. The page is at protocolvision.org, and a version with a stronger architectural look is at protocolvision.org/v2.