A job description for a Business Protocol Lead

Companies putting AI agents to work keep finding out they don't quite know how they work. The rules that decide what can happen (who can approve a deal, how much can be spent, who can see what, what data can leave) are tangled up in habits, inboxes and people's memories. Some of them hold the business together. Some are leftovers. Some don't exist yet, and agents are very creative in finding these gaps.

Security, finance and legal usually write these rules, but just as many emerge informally: a new tool like git, Notion or Slack quietly sets its own standards. Few people are looking for the hard protocols that define a business. Many more are looking at processes, products and go-to-market strategy, all of which agentic loops will soon reshape. Someone needs to look at the work with fresh eyes, find the rules that keep the business sustainable and the ones that help it thrive, then design and evolve the infrastructure that enforces them and opens new channels of growth. That is a new job, for someone equally curious and protocol-savvy.

Below is a sample job description for this emerging role, the Business Protocol Lead. It combines parts of operations management, DevOps, innovation management and forward-deployed engineering, pointed inward at one function at a time. Some highlights:

It's a field role. The main job is to find out, not to optimize: follow deals, read agent traces, sit with the people who carry the exceptions in their heads. The map that comes back is then compared with the official approval and process flows.
It treats agents as instruments, with risks and opportunities. Agents run into unwritten rules faster than people do. Where they stall, loop or improvise is evidence of where the real protocols are.
It has an experiment plan. Loosen a rule for a month and watch what happens. Harden one and see what gets built on it.
It looks for what becomes possible. A rule that holds is something others can build on: a pricing interface a partner can call, an approval a new agent can rely on.
It reports to the COO, not to security or engineering. Its focus is the business as a whole, not only product growth, sales or software security.

The title and the word "protocols" are ours. If your company already has a name for this, keep your word and keep the curiosity. In Business Protocol Management terms, this is the person who sees the protocols before anyone designs them.

Use it freely. Copy it, adapt it and post it; no permission or credit needed. Replace the text in square brackets first. If you hire for this role, or find the template doesn't fit, tell us in #protocols-for-business on the Protocol Institute Discord. What you learn could become a case study.

Business Protocol Lead

[Company] · [Location] · Reports to the Chief Operations Officer

About the role

[Company] is putting AI agents to work across [sales, customer operations and finance], and we've learned that we don't fully know the rules our business runs on. Some are written in policies. Many live in habits, workarounds and people's memories. A few of them decide how fast and how safely we can grow: who can approve a deal, how much can be spent, who can see what, and what data can go to a customer or partner. We call these rules our protocols.

You will be the person who finds them and rethinks them as the business changes with AI adoption. You'll follow the work across teams, document the protocols and tangles it really runs on, and run experiments to learn which should be hard (enforced by infrastructure, the same for every person and agent), which should stay soft, and which new ones would open up things we can't do today. Security, finance and legal decide what the rules say; engineering builds them; you bring back what's true on the ground.

What you'll do

Follow real work from end to end ([a deal, a refund, a new partner, an agent's first week]) and map the protocols it runs on: written and unwritten, enforced and remembered, and the ones people route around.
Read agent traces and logs as field notes. Where agents stall, loop, ask for help or improvise, find the rule they ran into and whether it's real.
Keep an open map of our protocols that anyone at [Company] can read and correct, showing what's hard, what's soft and what nobody is sure about.
Choose with the COO a few questions worth investigating each [quarter], such as "What happens if sales can discount up to [15%] without approval?" or "Which data requests could a partner's agent make safely on its own?"
Design and run experiments: loosen a rule for one team, harden one in a system, give an agent a new permission with a limit. Write the hypothesis down first, and share what happened, including when you were wrong.
Look for what becomes possible once a rule holds. Prototype approval, pricing and data-request interfaces that teams, partners and agents can build on, and see who builds what.
Work with security to look closely at each new agent before launch: what it can see, do and spend, who owns it, how to stop it, and what it might teach us.
Treat incidents and near-misses as discoveries. Run blameless reviews that end in a change to a system or to the map.
Review the protocols with their owners every [quarter]. Harden what keeps failing, and soften what slows good work without making anything safer.
Write it up. Share short field notes each month: what you found, what you tried and what changed.

What you'll bring

[3–5] years in operations, revenue operations, internal controls, business systems, research, reliability or platform engineering.
Curiosity about how organisations really work, and the patience to find out first-hand.
A record of turning something you discovered into something a system does: a permission, an approval workflow, a pricing or spending limit, or a release gate.
Hands-on experience running AI agents or workflow automation in production, using [n8n, Workato, an agent platform or model APIs]. You can read logs and agent traces, and you enjoy it.
Experience running pilots or experiments in a live business, including ones that didn't work.
Clear writing. You can describe a messy system so that the people inside it recognise it.
Experience getting security, engineering and sales or go-to-market teams to agree on a rule and its trade-offs.

Nice to have

SQL or Python.
Background in ethnography, service design, systems thinking, audit, or site reliability.
Experience in deal desk, revenue operations or partner integrations.
Experience in [industry].

Your first 90 days

Day 30: a first map of the protocols behind [one revenue workflow, such as quote-to-contract], drawn from following real cases and agent traces, with the three things that surprised you most.
Day 60: three open questions about that workflow, each with an owner, a hypothesis and an experiment to answer it.
Day 90: one experiment run and written up, with before and after, and one protocol hardened or softened because of what it showed.

Details

Location: [office, hybrid or remote]
Compensation: [salary range and benefits]
Hiring process: [stages]
[Equal opportunity statement]