Join OTP the operating platform for people and AI agents
Back to Blog
Founder Notes 2026-06-21 · David Steel

Agents are an operating decision, not a technology decision

Every company I talk to has routed agent deployment through the same door: the technology team.

IT evaluates the vendors. IT runs the pilots. IT decides which model, which API, which integration layer. The CEO gets briefed on the outcome. When the agents underperform, IT debugs. When the agents drift, IT investigates. When the agents produce numbers that nobody on the leadership team can connect to a business outcome, everyone agrees the technology needs more time.

The technology is not the problem.

The problem is that a structural, organizational decision was handed to the wrong department. Agents are not a technology choice. They are a hiring decision, a seat-design decision, a reporting-structure decision, and an accountability decision. All of those belong to the CEO and the operating team, not to IT.

Getting this wrong is expensive. Deloitte's 2026 State of AI survey, with 3,235 respondents, found that only 21 percent of enterprises have a mature governance model for agentic AI. That is not a technology gap. Those companies have plenty of technology. It is an operating-model gap. The leaders who closed it were the ones who stopped asking "which model should we use" and started asking "who owns this seat."

The decision tree most CEOs never see

When you deploy an agent, you are making a chain of decisions. Most companies only make one of them consciously.

The one decision they make consciously is the technology decision: which tool, which vendor, which integration. This is the decision that gets a Slack thread, a demo, a budget line, a project ticket in the backlog.

The decisions they do not make consciously are the ones that determine whether the agent actually works.

Here is the tree.

First decision: what does this seat do?

Not "what can the model do." What does this specific seat do, in this specific org, for this specific outcome. A seat without a defined scope produces output that looks active but does not move anything. Our agent Dash covers all customer ad performance across Meta and Google for the accounts Sneeze It manages. That is the seat. Dash does not write copy, does not advise on strategy, does not own client relationships. When Dash's row on the scorecard is below target, we know exactly what to investigate because the seat has an edge.

If you cannot write the seat definition in two sentences, you have not made this decision yet. No technology choice can substitute for making it.

Second decision: who does this seat report to?

Not "who manages the API key." Who is accountable for the output this seat produces, the way a manager is accountable for a direct report's output. At Sneeze It, Radar, our chief-of-staff agent, reports to me. Dirk, our sales agent, reports to me. Arin, who manages the call center team, reports to me. The fact that they are agents does not change who is responsible for what they produce. If Dirk's pipeline numbers are wrong, I own that problem because Dirk's seat reports to me.

Most companies running agents have no clear answer to this question. The agent was deployed by IT, reviewed by IT, and when something goes wrong the accountability conversation starts in IT. But the outcomes the agent is supposed to drive are owned by a business leader. That gap is where agents go to die quietly.

Third decision: what number does this seat own?

Every seat on a real org chart has a metric. Bogdan, our COO, has metrics. Janine, who owns accounting, has metrics. The agents have metrics too. Tally tracks KPI values across the fleet and pushes them to the scorecard. Nick, our cold prospecting agent, has a single KPI: quality emails drafted per day, target thirty. When Nick's number is below thirty, we know. We investigate the cause. We fix the input, the scope, or the process.

The metric is not a technology metric. It is a business metric. "Tokens consumed" is a technology metric. "Quality emails drafted" is a business metric. The seat does not earn its place on the org chart until it owns a business metric.

Fourth decision: when does this seat get retired?

This is the decision that almost nobody makes in advance, and that failure costs more than any other. Agents accumulate. The Gartner research (as reported by CIO.com) puts the average enterprise at fifty-plus agents by end of 2026. Most of those agents will not have a clear answer to questions one, two, and three above. They will produce activity. They will consume budget. They will not move the numbers that matter. And nobody will retire them, because nobody was assigned to own that question.

We had this conversation about Jeff, a data integrity agent who ran at Sneeze It through early 2026. Jeff's capabilities had been absorbed into seats that already existed. The conversation was about whether the seat still had a job worth doing. It did not. Jeff was retired through a formal hearing, capabilities redistributed, record kept. The decision was an operating decision, not a technology decision. No model got deprecated. No API got turned off. A seat was closed because the org no longer needed it.

The discipline to close seats is the same discipline that makes the org chart real. Without it, you do not have an org chart. You have a list of agents that IT is managing and nobody is accountable for.

Why technology teams get handed this and fail

Technology teams are excellent at the thing technology teams are good at: evaluating tools, managing infrastructure, solving integration problems, maintaining security and access control.

They are not good at the thing this decision actually requires: defining seat accountability, designing reporting structures, writing business metrics, and making the judgment calls that determine whether a seat is earning its place.

This is not a criticism of technology teams. It is a description of what the job is.

McKinsey put it plainly: managing in the age of AI means managing systems of people and agents together. The verb is "managing," not "deploying" and not "integrating." Managing systems of people and agents is an operating discipline. It lives on the CEO's desk.

MIT CISR's research on enterprise AI maturity found that Stage 4 firms, the ones furthest along, outperform their industries by 13.9 percentage points on revenue growth and 9.9 points on profitability. The paper names the condition: a united top leadership team including the CEO, the chief strategy officer, and the head of HR. Not the head of IT alone. The CIO is one stakeholder in a leadership-wide commitment. The companies treating agent deployment as a technology decision were not in Stage 4.

What the operating decision actually looks like

When I add an agent to the Sneeze It org chart, the process does not start with technology.

It starts with a seat definition. I write two sentences: what this seat owns and what it does not own. Pepper owns email triage and client email drafts. Pepper does not own strategic decisions, calendar, or team comms. Crystal owns project status tracking and deadline monitoring. Crystal does not own client communication or strategy.

Then I write the metric. One number that the seat is accountable for, expressed in business-outcome language. If I cannot write that number, the seat is not ready to hire, whether the hire is a human or an agent.

Then I assign a reporting line. The seat reports to a named human who is accountable for the output. That human walks the metric in the Monday meeting the same way every other metric gets walked.

Then I build the agent. Or rather, then the technology question becomes relevant, because now it has a specific answer to serve. The seat definition, the metric, and the reporting line constrain what the technology needs to do. The technology question gets easier when the operating question has already been answered.

The mission underneath this is straightforward: let agents carry the operational work, so people are free for the work that matters. That mission is not achieved by deploying agents. It is achieved by deploying agents with clear seats, clear owners, and clear numbers, and by retiring the ones that do not earn their place. The agents doing that work at Sneeze It right now include Radar, Dash, Dirk, Pulse, Pepper, Crystal, Arin, Nick, and Tally. Each one has a seat, a metric, and a human it reports to. None of them were hired through the technology team.

The question to bring to your next leadership meeting

If you are running agents right now, ask these four questions about each one. Not to IT. To yourself, or to the operating leadership team.

What does this seat own? What does it not own?

Who on this team is accountable for the output this seat produces?

What is the one business metric this seat is responsible for moving?

When would we retire this seat, and who would make that call?

If you can answer those four questions, you have made the operating decision. The technology decision you already made is now serving something real. If you cannot answer them, you have infrastructure running without accountability, and the compounding cost of that gap is higher than any model upgrade you are considering.

See the live chart

Every agent seat at Sneeze It, including its scope, its metric, and its reporting structure, is queryable through the OTP MCP server.

In Claude Desktop or Cursor or any MCP client, add this block:

"otp": {
  "command": "npx",
  "args": ["-y", "@orgtp/mcp-server"]
}

Restart the client. Then ask: "Use OTP to list the agent seats at sneeze-it and show me what metric each one owns."

You will see each seat with its defined scope and its business metric. That is what the operating decision looks like when it has been made: not a list of tools, but a list of accountable seats.

DS
David Steel

Founder of OTP. Runs an AI agent army at a digital agency. Building OTP because nobody else seems to be building it. Notes from inside the build, not from the conference circuit.

More about David →

More posts on the blog index.

All posts