2026-09-29

Why It’s Time To Start Building an Org Chart for Your AI Agents

A man works at a whiteboard in front of a board room of colleagues.
By Jason Cottrell, Founder & CEO, Orium
5 min read

A few weeks ago I sat down with Rick Watson, Shawn Mandel from Dentalcorp, and Anatolii Iakimets from KIBO for a Watson Weekly webinar that Rick opened with a simple question: how much should a company spend on agentic AI? Nobody gave him a number.

Now, it would be easy to assume we were dodging the question. Service providers and vendors shying away from setting expectations for potential customers, and brands hesitant to reveal the scope of their investments. But that wasn’t what was happening. None of us gave him a number because the question itself needs to evolve. The answer that matters isn't a number on a budget line. It's whether you know who owns each agent before you turn it on.

Agents need an org chart, not a budget line

Every company already has an answer for how it manages people: who they report to, how they're onboarded, what happens when they leave. Almost no one has that answer for software, and agentic AI is the first category of software that really and truly needs one. An agent that can take action on your systems isn't just some script running in the background. It's closer to a new hire, and it needs the same basic questions answered. Who does it work for? Who signed off on what it's allowed to touch? Who's accountable when it gets something wrong?

Shawn made a version of this same point from Dentalcorp's side of the table in the webinar: with a small team supporting more than 650 dental practices, he doesn't get a dozen shots at this, so he's stopped treating agent deployments as pilots. Each one has to be designed as a step toward a platform from day one, with a real business sponsor and clear enough permissions and data access that the next use case can build on it. That's treating the new challenges as an org chart question before ever assuming they’re a technology question.

Five controlled agents beat a hundred unmanaged ones

I said during the recording that I'd rather see a company running five agents on tightly permissioned, auditable access to its systems than one running hundreds with no controls at all, and I stand by it. I’m bullish on the reality of hundreds and even thousands of agents operating inside an enterprise in the very near future, but just because I believe that’s where things are headed, doesn’t mean I believe that’s the best way for a business to be thinking today.

The instinct to count agents—to treat a bigger deployment as a more advanced one—is the same instinct that used to get companies to brag about lines of code. It was a bad proxy for progress then, and it's a bad proxy now.

Anatolii made the sharper version of this argument in the same conversation: buyers should press vendors on audit logs and human review with the same energy they bring to evaluating use cases, rather than being impressed by raw agent counts. That's the right instinct, and it's one I'd extend further— the count itself should be a yellow flag, not a selling point, until you know what's actually governing those agents.

Budget for the vendor to get you 80% of the way, and plan to finish the last 20% yourself

That math only works if the use case is narrow. The projects I've seen go wrong are the ones that try to do too much at once— companies that commit something like $20 million to a single general-purpose agent meant to handle everything, which is exactly the shape of a project that doesn't finish. The harder architectural problem isn't building one agent well, it's building the governance and ownership structure that holds up when a business isn't running one agent, but hundreds or thousands of them, each with its own scope and its own line of accountability.

A vendor can get you most of the way on a well-scoped problem. But no vendor shows up already knowing your business well enough to hand you a finished, fully governed deployment — that last stretch gets worked out jointly, refined against the processes and judgment calls specific to your business. Budgeting as though a vendor will finish that work alone is how these projects stall.

Shawn's read on this, from the buyer's side, was pragmatic rather than cynical: most agentic pitches hold up fine until he asks for a demo and an actual engagement plan, and that's usually where they start to come apart. Not because vendors are dishonest, but because the category is genuinely young—barely ten months old by his estimate—and nobody builds mature enterprise software in ten months.

What this means this week

If you're evaluating agentic AI right now, three questions will tell you more than any spend estimate:

  • Who owns this agent, and what does onboarding and offboarding look like for it?
  • What is it actually permissioned to touch, and can you audit that?
  • What specifically is the vendor scoping out of the first 80%, and who's finishing the last 20%?

If you can't answer those, you're not ready to talk about budget yet.

Why we treat this as infrastructure, not a pilot

This is also why Orium and the MACH Alliance keep pushing the same framing: agentic AI is an infrastructure decision, not an experiment you run to see what happens. Getting this right isn’t about spending the most or building the most agents. That’s an easy way to bask in the false comfort of meaningless stats. But the ones who decide—before they spend anything on agents—who's in charge of what they build, will lay the foundations for long-term success.

Popular Articles