I’m going to risk an ‘Old Man Yells at Cloud’ moment here: every year, I spend time collecting and summing gross wages by state for workers’ compensation and retirement account audits. It’s complex. It’s rule-based. It’s error-prone. And it adds absolutely nothing to my business except compliance with regulatory requirements. I’d love to be able to automate it but the systems I need to interact with seem designed specifically to prevent exactly that.
This is the miserable reality of automation. It’s hard and half the time the effort to automate something is worse than just gritting your teeth and doing the work manually.
But here’s the thing – if I’m struggling with this as someone who’s been building technology systems for decades, imagine what’s happening across your organization. Your finance team, your HR people, your operations staff – they’re all drowning in repetitive work that adds zero strategic value to your business.
I call this “toil.” And it’s expensive in ways that don’t show up on your P&L until you realize your talented people are spending their time on tasks that scale with your revenue but not with your capabilities.
Your most expensive employees are doing work that doesn’t create value
My wage reporting eats up a February day every year for a small firm. Scale that across an enterprise with hundreds of employees, multiple states, and you’re talking about weeks of effort annually. Not for innovation. Not for customer relationships. For compliance paperwork.
Or consider payment authorizations. If you’ve worked with a vendor for years, why does your AP clerk still need to manually authorize every invoice? Below a certain financial threshold with trusted vendors, you’re just creating friction where trust is already established.
These are examples of what I call “statutory toil” – work mandated by regulations or internal policies that must be done but adds no strategic value. It scales with your business size but doesn’t scale your capabilities.
The real cost isn’t the individual task. It’s what your people aren’t doing because they’re buried in this repetitive work – opportunity cost. Every hour spent on toil is an hour not spent on customer relationships, product innovation, or market opportunities.
If you’re doing something five times, automate it (but read the fine print)
The five times rule is simple: if you’re doing something five times, automate it.
But through painful experience, I’ve learned this rule has critical exceptions. Take occasional, lower-frequency tasks. For something like retrieving an unemployment insurance rate notice – which happens maybe once a quarter – the time invested in building reliable automation often isn’t worth it.
Monitoring and detecting failures in automation can require more effort than performing the task manually. If your automation breaks and you don’t catch it, you’re worse off than if you’d just done the work yourself.
High-transaction rate automation makes the most economic sense. If you’re processing hundreds or thousands of transactions, the upfront investment pays off. But for occasional tasks, the cost-benefit calculation changes dramatically.
The frequency matters. The stability of the process matters. And critically, whether you can trust the automation to work reliably matters.
The roadblocks that make automation miserable
Before you can even apply the five times rule, you need to understand what’s working against you.
First, there are the technical barriers. Passwords, CAPTCHA, security questions, multi-factor authentication – all designed to keep bots out, which means they’re also designed to keep your automation out. Tools like Cloudflare actively thwart automation attempts using behavioural models. AI systems are now being deployed specifically to detect and block automated access.
Second, many sites don’t have the decency to offer public APIs; many regulatory sites only have an API for document submission with no ability to run a transaction and receive results. This forces you to rely on web automation that scrapes websites, and that breaks constantly because web pages change. You’re building on sand.
Third, regulations often require a human in the loop. Know Your Customer (KYC) laws, anti-money laundering (AML) requirements – these aren’t going away. They slow automation to the speed of government processes, which is to say, not very fast at all.
But the real barrier – the one that keeps me up at night – is trust.
The trust problem
When you automate a process, you’re not just delegating a task. You’re delegating authority. And that delegation comes with risk.
Think about what could go wrong: bank accounts drained, paying for things you didn’t authorize, agreeing to contracts you never approved, starting automated collections processes, triggering a tax auction for your property.
Every bad pattern you can think of can be automated.
Technologies like Microsoft Replay for Windows and Google Auto Browse raise serious questions about where credentials live. Google’s approach keeps credentials local on your machine, which is safer. But other models store secrets in the cloud, and in the current political and security climate, that makes me nervous. I have a personal fear of external data seizure and cyber threats.
The fundamental question is this: How do you grant autonomous systems the authority to act on your behalf without creating catastrophic risk?
You need to understand everything an automated system is permitted to do. Discover, retrieve, modify, transact – each requires different levels of trust. You need clear boundaries. You need the ability to kill a rogue automation. You need strong transactional semantics and contracts around what automated systems can do. You need authentication, authorization, and audit trails.
Guardrails aren’t just nice to have. They’re extraordinarily important, especially in regulated industries.
These same trust and governance questions apply whether you’re automating internal processes or preparing for customers’ AI agents to transact with your business. The risk calculus is similar. You’re defining what autonomous systems can do, establishing boundaries, and building safeguards against failure or compromise.
Working through these questions internally builds the muscle memory you’ll need for the broader shift toward agent-driven commerce.
When automation makes sense: high repetition, clear rules, acceptable risk
Given these barriers and trust constraints, how do you decide what’s actually worth automating?
Automate when the process has high repetition with clear rules. The workers’ compensation audit I mentioned is complex but entirely rule-based. Collecting gross wages by state and summing them – no judgment required. Payment authorizations below certain thresholds with established, trusted vendors. Unemployment insurance queries that happen quarterly with identical steps.
Automate when the process is error-prone when done manually. Manual data entry across multiple systems. Copy-paste operations where mistakes compound. Calculations that must be verified multiple times. My full-day audit process is a perfect automation candidate precisely because errors are costly.
Automate when the process creates scalability bottlenecks. If doubling your business size means doubling headcount for non-value work, that’s a problem. If tasks prevent people from doing strategic work, automate them. If work must be done before anything else can proceed, it’s a bottleneck worth addressing.
Automate when the process has an acceptable risk profile. Internal processes where you control all the actors. Transactions where the downside of failure is limited. Processes with good rollback or correction mechanisms.
When automation doesn’t make sense: instability, judgment, bad data, weak governance
Don’t automate when the process is unstable. Frequently changing web interfaces. Processes that haven’t been standardized yet. Systems that are themselves in flux. Web automation frequently breaks due to continuously changing web pages – I’ve experienced this more times than I can count.
Don’t automate when it requires human judgment on trust. Evaluating trustworthiness or reliability. Decisions involving context that’s hard to codify. Situations where “it depends” is the real answer. Anything where you need to assess whether to trust a counterparty.
Don’t automate when the data is bad or inconsistent. Poorly parsed, unstructured documents from OCR. Inconsistent data formats across systems. Missing or contradictory information. Automating processes based on bad or inconsistent data is highly problematic.
Don’t automate when the trust framework isn’t in place. If you can’t clearly define what the automation is permitted to do, don’t do it. If you don’t have the ability to stop it if it misbehaves, don’t do it. If the audit trail doesn’t exist to understand what happened, don’t do it. If the consequences of failure are severe, don’t do it.
Five diagnostic questions to identify what’s worth automating
Here’s a practical framework for deciding what to automate:
Frequency test: Does this happen often enough that errors or delays compound?
Rule test: Is this truly rule-based, or does it require judgment about trust, context, or relationships?
Scalability test: If we doubled in size, would this process require proportionally more people?
Risk test: If this automation failed or was compromised, what’s the worst that could happen?
Trust test: Can we clearly define and limit what this automation is permitted to do?
Take my payment authorization example. Below a certain financial threshold with trusted vendors, eliminate the approval process entirely. But note the preconditions: trusted vendors, below a threshold. That way the trust relationship is established, and the risk is bounded.
The workers’ comp audit: rule-based, high effort, error-prone, done annually. And importantly, the trust framework is clear. You’re collecting your own data, performing calculations according to regulatory requirements, and producing a report. The automation isn’t making decisions about who to trust; it’s just executing defined steps.
You need three things before you can automate anything effectively
Companies must establish solid data and APIs that support CRUD (create, read, update, delete) transactions and have clear trust and permission frameworks in place.
First, clean and accessible data. You need one operational data store with current information. Consistent formats across systems. No contradictory data that requires human interpretation.
I’ve seen very large financial services companies where they had multiple data stores and they didn’t agree. Depending on which service you’re asking, you get a different answer to your question. There was no way they could say “this is our unified vision of the customer” because they have multiple operating units and contradictory information spread all over.
Second, well-documented APIs and protocols. Reliable interfaces between systems. Agent-enabled workflows are dependent on open protocols that function reliably and internal systems that can talk to each other programmatically. Technologies like Google’s Universal Commerce Protocol (an open-source standard that enables AI agents to interact with merchants) and the Model Context Protocol (another open-source standard that eagles AI models to connect with external tools and databases) represent steps in this direction.
Third, trust and permission frameworks. Clear definitions of what automated systems can do. Authentication and authorization mechanisms. Audit trails that show what happened. The ability to revoke authority when needed. You have to decide whether or not it’s permitted, given the intersection of what the agent’s trying to do and who they represent.
These three pillars – data, APIs, and governance – are the same foundation you’ll need whether you’re automating payroll processing or preparing for AI agents to complete transactions with your business on behalf of customers. Being “agent ready” requires exactly this infrastructure.
The work you do to reduce internal toil directly prepares you for the broader technological shift toward autonomous agents. We explored this in depth in How to prepare your business for the agentic web, but the key insight is this: the same capabilities that enable efficient internal automation are what make you ready for agent-driven commerce.
By focusing on internal automation first, you’re building trust frameworks and governance models in a controlled environment where you understand all the actors and can manage the risk. This experience is invaluable because (very) soon you’ll need to extend similar trust to external agents acting on behalf of customers.
Why this matters more now than it did two years ago
Product cycles have dramatically accelerated. Work that was once planned for five or three years is now measured in months or weeks. Making predictions beyond three months is difficult.
Businesses are reducing their workforce at a faster rate than they are automating tasks. The pressure to do more with less is increasing, which makes toil even more expensive.
Being automation-ready will soon become table stakes for competition.
There’s massive capital flowing into AI and automation platforms – companies like Anthropic, Google, Microsoft, xAI, and OpenAI are building agent creation platforms to solve fundamental automation problems.
But before you can take advantage of any of these technological advances, you have to address the foundational issues. Data quality. Inconsistent processes. Access and authentication. And above all, trust frameworks.
Start with your lowest-risk, highest-toil work
Here’s a practical path forward.
Identify statutory toil first. Compliance requirements that must be done but add no value. Unemployment insurance reporting, workers’ comp audits, multi-state regulatory filings. These are often perfect candidates because they’re rule-based, unavoidable, and the trust framework is clear. You’re processing your own data for regulatory purposes.
Map your friction points in established relationships. Where do trusted relationships require unnecessary approval steps? Vendors you’ve worked with for years. Trust is already established, so you’re just eliminating process overhead.
Focus on internal processes first. Internal agents have a lower risk profile because you know who all the people involved are. The transactions you run internally are different from external ones. Build your trust frameworks and governance in a controlled environment. This experience translates directly when you need to establish similar frameworks for external agents.
Start where failure is recoverable. Don’t begin with high-stakes, irreversible transactions. Choose processes where you can roll back or correct mistakes. Build confidence in your automation – and your ability to monitor and control it – before expanding scope.
Build the foundation as you go. You need clean data in one operational data store. Documented APIs for internal systems. Clear governance about who (or what) can authorize what. Strong audit trails and the ability to stop automations when needed.
The decision you can’t delegate
Defining intent and defining outcome are extremely important, and that’s not something you can outsource.
Only you can decide what work is strategic versus what’s toil. Which processes constrain your growth. What level of risk is acceptable for automation. Where you trust machines and where you need humans. How much authority you’re willing to delegate to autonomous systems.
The companies that will succeed with automation won’t be the ones with the fanciest AI platforms. They’ll be the ones that have clearly defined what their automated systems are permitted to do, built the guardrails to enforce those boundaries, and created the audit trails to understand what’s actually happening.
The five times rule isn’t really about counting to five. It’s about developing the discipline to ask: Is this work that makes us better at what we do, or is it just toil that scales with revenue but not capability?
And critically: Do we trust an automated system to do this work, and have we built the safeguards to contain the risk if something goes wrong?
You need to address your data, your APIs, and your governance: the key capabilities that reduce toil today and prepare you for whatever automation technologies emerge tomorrow. But you also need to address the trust problem.
Because as I learned through painful experience, a lot of the challenge to automation is trust-based.
Learning to make these trust decisions internally– where to automate, how to bound risk, how to monitor and control autonomous systems – builds the organizational muscle you’ll need as automation becomes more pervasive and as external agents begin transacting with your business.
Start by identifying your highest-toil, lowest-value, lowest-risk work. Ask not just whether it can be automated, but whether it should be. Whether you can clearly define what the automation is permitted to do, and whether you have the guardrails to prevent catastrophic failure.
That’s where automation delivers real ROI without creating existential risk. And that’s where you begin building the capabilities that will define competitive advantage in an increasingly automated world.
Rick Garvin is a Managing Director at Ten Mile Square. He has worked to scale technology businesses for 35+ years and performs product and technology assessments and technology acceleration for growth-oriented technology companies. If your digital transformation has hit a wall, a conversation with Rick is the first step toward uncovering the root causes strangling your ROI. Schedule a discovery call.