A Framework for Agentic Ops: How to Make a Business Autonomous Without Losing Your Mind
I thought long and hard about making HonestDog autonomous with AI. But long before that, I was building business intelligence dashboards, flows, and automations the old-school way — Zapier, RPAs, VBA scripts. I did it at a five-person e-commerce company, inside Amazon fulfilment centres, and at McKinsey, benchmarking the ops of multi-billion-dollar CPG companies (production throughput, logistics costs) against their industry peers.
One thing has stayed true the whole time: automation is an exercise in complexity abstraction and first-principles thinking. As the tools evolve, the processes have to evolve with them. AI doesn’t change that — it just raises the ceiling on what’s worth automating, and lowers the floor on what you can afford to leave manual.
Here is the framework I now use whenever I assess an organisation’s operations for AI leverage.
Start with bandwidth, not tools
If I were dropped into a business tomorrow and asked to do a 360° assessment on AI-driven ops efficiency, I wouldn’t start by listing tools. I’d start by mapping the current processes and the cost of each in human bandwidth.
Human bandwidth is a function of two things: frequency and duration. Every process you run has a cost shaped like frequency × duration × people involved. AI can attack any of those levers — reducing how often a flow needs to run, shortening how long it takes, or shrinking the number of humans in the loop. In some flows, AI can lead and humans support. In others, the reverse is safer.
The mistake most teams make is asking, “How do we get AI to do what our humans currently do?” That’s the wrong question. The right one is: “Given our goals and the technology now available, how would we redesign this flow to be AI-native from the ground up?” Same outcome, very different system.
Specialised vs general intelligence
When you decide to bring AI into ops, there are two paths: specialised AI tools built for a specific flow (customer support agents, AI SDRs, AI bookkeepers) or general models wired up in-house.
Default to specialised. As a business, your job is to add value to your customers and double down on why you exist — your competitive edge. Specialised tools let you ride the rapid evolution of the model layer without doing any of the work yourself; the vendor absorbs every model upgrade for you.
There are two cases where in-house makes sense:
- The general models have advanced far enough that the specialised tool no longer offers a meaningful edge — at which point the middle man becomes pure margin tax.
- Your unit economics are tight enough that every cent matters, and eliminating the vendor margin is the difference between profitable and not.
Outside of those two, building in-house is usually a vanity project disguised as engineering.
Internal before external
Tackle internal ops before customer-facing flows. The blast radius is smaller, the feedback loop is faster, and you can iterate without a brand cost when the AI does something weird.
Some businesses have customer segments where trust is the entire product — healthcare, finance, anything involving children, anything involving money or pets. In those cases, AI should start as an enabler (drafting, suggesting, prepping) and only graduate to leader (acting on behalf of the business) once the rails are proven internally.
Upgrade vs new build
More often than not, building from zero — with first principles and AI in mind from the first commit — is faster than retrofitting an existing system. Old systems carry the assumptions of their era; the human-shaped process gets baked into the schema, the UX, the permissions model. Trying to bolt agents onto that often costs more than starting clean.
If the existing system is small or recent, upgrade. If it’s older than the AI capability you’re trying to introduce, seriously consider rebuilding.
The 80/20 trap
AI is exciting because you can get to 80% of the result with 20% of the effort. That’s also the trap. Production readiness — the kind that lets you sleep at night and scale without a babysitter — lives in the last 20%. That’s where determinism, error handling, monitoring, and edge cases live. Demos run on the first 80%; businesses run on the last 20%. Budget for it.
The real limitation: complexity
AI still needs human supervision — for safety, and as rails. The deeper problem is what that supervision looks like at scale. Humans are now spawning and managing dozens of AI interns at once, and the rate at which they spawn new ones is accelerating. Bandwidth that was supposed to be freed up is being eaten by orchestration overhead.
This is brutal on an organisation. Complexity grows, entropy follows, and chaos compounds. Complexity kills companies. The countermeasure isn’t more tools or more agents — it’s a dedicated function (a person, a small taskforce, a cultural norm) whose explicit job is to cut complexity and reduce moving parts. Kill the agent that runs once a week. Merge the three half-overlapping workflows. Delete the dashboard nobody opens.
Sometimes, to take three steps forward, you have to take one step back.
And before you automate anything, be honest about whether the automation is worth the investment in the first place. Randall Munroe’s chart is the most useful thing I know on this subject:
Source: xkcd #1205, “Is It Worth the Time?” by Randall Munroe (CC BY-NC 2.5).
The framework, in one paragraph
Map your processes by human bandwidth (frequency × duration). Default to specialised AI tools; only build in-house when the general models have eaten the specialist’s edge or when margins demand it. Tackle internal flows before customer-facing ones, especially in trust-heavy markets. When the existing system is older than the AI capability you’re introducing, rebuild rather than retrofit. Budget for the last 20%. And put someone in charge of killing complexity, before complexity kills you.
If you’re working through this in your own business and want to compare notes, I’d love to talk. You can reach me at hello@sufyanosamah.com or on LinkedIn.