I've spent most of my career in the gap between business intent and technical execution. Program management, digital transformation, enterprise architecture — different titles for the same fundamental job: translating what people know about their work into systems that can act on it.

That gap has always been the real bottleneck in automation. Not integration. Not tooling. The translation.

The people who understood the nuance — the exceptions, the judgment calls, the "we don't usually do it that way, except when…" rules — rarely had the tools to encode it. And the people who had the tools often lacked the context. So the easy stuff got automated, and everything that actually mattered stayed manual.

That's changing. And it's changing for a reason that most automation conversations still get wrong.

The old automation ceiling

Think about how traditional automation works. You identify a repeatable process, map it into a flowchart, define the triggers and conditions, wire up the integrations, and hand it off. The more rigid and predictable the process, the better it works.

The problem is that the most valuable work in any organization isn't rigid. Client reporting that requires understanding relationship history. Proposal drafting that depends on knowing which constraints are real and which are negotiable. Support triage that hinges on recognizing the difference between a frustrated customer and a churning one. Exception handling that only makes sense if you know the politics.

These processes lived in people's heads. You could document them — I've written hundreds of process documents over the years — but the documentation was always a lossy compression of the actual knowledge. And translating that compressed version into executable workflow logic required an automation engineer to interpret what the business meant, which introduced another layer of loss.

The result: most organizations automated about 20% of what they intended to and declared victory. The remaining 80% — the context-heavy, judgment-dependent work — stayed manual, not because it was unimportant, but because the abstraction cost was too high.

Why the equation just changed

Language-based AI systems changed this because they can absorb instructions, examples, policies, and exceptions in a form that's much closer to how business teams actually think about their work.

I've seen this firsthand. In my own workflows, I've built reusable procedures — what some tools call skills or agents — that encode specific ways of working. Not as rigid flowcharts, but as structured natural language instructions with the right tools attached where needed. The procedure knows the context: which systems to check, what format the output should take, which exceptions to watch for, when to escalate versus handle autonomously.

The important thing: I built most of these myself, drawing on my own domain knowledge. Not by writing code or configuring integration platforms, but by describing the process the way I'd explain it to a competent colleague. The AI fills in the execution. I provide the context.

That's the shift. In these workflows, context is the asset. Not the integration logic. Not the API connections. The domain knowledge — the understanding of how the work actually works — is what makes the automation valuable or worthless. And for the first time, the people who hold that knowledge can encode it directly, without waiting for a full engineering build.

Context-heavy work is suddenly automatable

This unlocks categories of work that traditional automation couldn't touch. I'm talking about things like generating client reports that pull from the right sources and frame findings the way a specific stakeholder expects them. Drafting proposals that reflect the actual negotiation position, not a generic template. Reviewing documents against policies that have a dozen edge cases the policy manual doesn't fully capture. Triaging incoming requests using the judgment that only comes from years in the role.

These aren't just productivity wins. They're ways of scaling tacit expertise across an organization. The senior person who knows exactly how to handle a tricky compliance scenario can encode that knowledge into a reusable procedure, and suddenly that judgment is available to the whole team — consistently, at any hour, without the senior person becoming a bottleneck.

I've written before about how context is what separates useful AI work from mediocre AI work. The same principle applies at the organizational level, but the implications are bigger. When the bottleneck was integration, you needed engineers. When the bottleneck is context, you need the people who actually understand the work.

What this doesn't mean

Let me be clear about what I'm not saying, because the hype cycle around this is already getting noisy.

I'm not saying AI replaces automation engineers. Complex integrations, error handling, scale, security — these remain engineering problems. What changes is the division of labor. Business teams can own the what and the why — the context layer — while technical teams own the how — the infrastructure, reliability, and integration plumbing. That's a healthier split than what we have today, where both sides are jammed into the same workflow builder trying to speak each other's language.

I'm also not saying this works out of the box. The quality of the automation is directly proportional to the quality of the context you provide. Vague instructions produce vague results. A procedure that says "review the document for issues" will produce generic output. One that says "check for clauses that conflict with our standard position on liability caps, flag any indemnification language that exceeds the thresholds approved in Q4, and note if the governing law differs from our preferred jurisdiction" will produce something genuinely useful.

This is the same pattern I've observed in individual AI work: the people who invest in making their context explicit get dramatically better results than those who don't. The difference is that at the organizational level, that context represents institutional knowledge that's been accumulating for years.

The real competitive advantage

From a transformation perspective, this shifts automation from a systems problem to a knowledge-to-execution problem. The organization that can operationalize its own context fastest will typically outperform the one with more tools. I've watched this play out in delivery programs: the team with fewer, better-contextualized AI workflows outproduced the team with a sprawling toolkit and no structured knowledge feeding into it.

The differentiator is no longer just connectivity or model quality. It's how well a company can turn its unique context — its policies, its customer knowledge, its operational judgment, its exception-handling playbooks — into repeatable action.

That's a fundamentally different kind of competitive moat than what most technology strategies are built around. It's not about which platform you're on or which model you're using. It's about whether you've done the unglamorous work of making your institutional knowledge explicit, structured, and available to AI systems that can act on it.

The better framing

So the strongest framing isn't "AI replaces automation engineers." It isn't even "AI makes automation easier."

It's this: AI lets business teams productize their context.

The business knows the context. The context increasingly determines the quality of the outcome. And AI now gives teams a practical way to encode that context into workflows without waiting for a full engineering translation cycle.

This is why I keep coming back to context management as the core skill of this era. Whether you're managing context in a single coding session or designing context architectures for agent teams or encoding business knowledge into automated workflows — it's the same fundamental discipline. Make the implicit explicit. Structure it well. Keep it current. Let AI do the execution while humans own the judgment.

The organizations that figure this out won't just have better automation. They'll have turned their hardest-to-replicate asset — the accumulated knowledge of how their business actually works — into a scalable capability. That's not a productivity improvement. That's a structural advantage.