AI is coming for your work. Not your job.

If you've been playing with AI tools lately, you've noticed the same thing I have: you can hand over bigger, messier tasks now, and let them run for longer.

That trend is only going to accelerate. More use cases open up, and more of the work becomes automatable.

So does that mean we all get replaced?

Not so fast. But we can't sit still either.

As AI takes on more of the work, and whole products can be cloned overnight, the question lands differently at each level.

How does an operator stay relevant once the work is automated? How does a manager connect leadership's decisions to what operators actually execute? And how does a leader set a strategy a competitor can't copy in a weekend?

In this article I've tried to consolidate what I've learnt: from the companies I've worked with, and the hundreds of hours I've spent building and scaling AI workflows at Elements and for clients.

It's early, so treat these as signals more than a finished map: how the impact is showing up at each layer, operator, manager, leader.

And throughout, I'm trying to name the processes and skills we should all be building, as AI comes for a bigger share of our work.

To see how it's playing out, let's start with the foundational layers of what makes a company today.

The three layers

Just like in every company, you essentially have three layers: leaders, managers, and operators. And the work flows from the top down.

• Leaders set the direction. They pick the goals for the year and define the KPIs.
• Managers prioritise. They turn those goals into OKRs (the activities needed to hit the KPIs), decide what matters most right now, and split their time between managing up (reporting, fighting for budget) and managing down (running initiatives, coaching, project management). They also hire and ramp the team.
• Operators execute. They run the ads, handle the tickets, work the leads, manage the accounts.

So the shape is simple: set direction at the top, prioritise in the middle, execute at the bottom.

What makes someone valuable

Now think about what actually makes someone good at their job. Most of it is never written down.

The salesperson who can tell a serious buyer from a time-waster in the first few minutes. The support agent who knows which complaint is really a billing issue. The ops person who knows one supplier always ships late over summer, so they order early. None of that is in a document. It lives in people's heads, and it's the reason the work gets done well.

That knowledge is the most defensible thing the company owns. A competitor can copy your pricing page in an afternoon. They can't copy fifteen years of someone's pattern recognition.

It's also the most fragile thing the company owns. It's scattered across Slack, the CRM, a dozen tools, and people's heads, and it walks out the door when someone leaves. It gets watered down the moment you try to write it into an onboarding doc, because the doc never captures the subtleties, and people work differently from the way they say they do anyway.

So the move everyone reaches for is to write it down. Companies have always done this. It's called a standard operating procedure, and every org has a drawer full of them. The trouble is that an SOP is a static document. People skim it once, then do the job their own way anyway. It captures the steps but never the judgement, and it goes stale the week after it's written. The knowledge stays in people's heads regardless.

Skills are the second attempt at the same problem.

A Skill is not a document a human reads and reinterprets.

It's something a machine runs the same way every time, with the tools to actually do the work attached. It can hold the judgement as logic and worked examples, it runs consistently, and it improves as one shared artifact instead of forty private interpretations. That's the bet for why it might finally stick this time.

Once portions of the work are codified, they can be pieced together with varying levels of autonomy: from a fixed workflow that runs the same steps every time, to an agent that's handed an objective and works out the steps on its own. That changes the shape of everyone's job.

So the real question is what this means for the people in the org. What changes for the operator, for the manager, for the leader, and how does each of them prepare for it and make the most of the opening it creates? That's the thread I want to pull, layer by layer. Start at the bottom, with the people executing.

The operator runs the same loop all day

Strip an operator's job down and it's a loop:

• Get the information they need. CRM data, tickets, lead lists.
• Work out what to do next. A new complaint, a new lead.
• Prioritise. The most urgent issue, the best prospect.
• Do the actual activity. Diagnose the problem, reach out.

AI changes two parts of that loop first: getting the information, and doing the work.

First, the information comes to you

The old way: a support rep opens Zendesk and reads down the queue one ticket at a time. A sales rep opens HubSpot, clicks into the leads page, and works through each new lead by hand.

The new way: you build a connector to those tools, an MCP, so the data comes to where the person already works. The rep asks, in plain language, “what are the three most urgent tickets today and why,” and gets an answer. The sales rep gets a Slack ping about the new lead with the highest average order value, already flagged as worth their morning.

Same data. The person stops walking over to fetch it and starts pulling it on demand from wherever they are. That alone makes the loop faster.

Then the work arrives pre-processed

This is the bigger shift.

The old way: for each ticket, the rep works through the internal procedures, figures out the fix, and slowly gets better at it over months. For each lead, they eyeball the tags and a score and make a call.

The new way: a Skill does the first pass. A Skill is a codified sequence of steps, the team's collective experience written down once so everyone runs the good version. For a ticket, the Skill identifies the issue, works out how to diagnose it, checks whether the internal docs already solve it, and hands a CS agent the context to take it from there. For a lead, it scores it, researches the prospect online, suggests which modules to pitch, and drafts a proposal before the call.

Karpathy has a good rule of thumb for when to make one. If you do something on a recurring basis, or the task is complex, turn it into a Skill the first time you finish it. Then you grant it to the team and give it tool access: browsing to research a prospect, a Zendesk connection, whatever the task needs.

Ramp built an internal marketplace of these, so any employee can add a colleague's Skill to their own stack. That's the shape of it. Work arrives pre-processed, and it gets better every time someone improves the Skill behind it.

The result is real. People ramp faster. Work comes out more consistent. Customers wait less.

So what is the operator actually for?

It's an uncomfortable question. If the Skill does the first pass, what is the operator actually adding?

I think the honest test, the one an operator should ask themselves every week, is this: am I adding something new to the Skill? Am I learning something the system doesn't already know?

If yes, you're valuable, because you're the source of the next improvement. You hit an edge case the Skill mishandled. You found the angle that converted. You spotted why the diagnosis was wrong. That insight feeds back into the Skill, and you just made the whole team better.

If the honest answer is no, that you're passing the Skill's output through with no new signal, then you're doing something a more autonomous loop will do soon, and cheaper.

The value just moves to another layer. The repeatable part of the job shrinks, and the part where you teach the system something new becomes the part that counts.

That tilts the operator layer. The people who keep refining their Skills get them running more autonomously, which frees their time to run more fleets and cover far more ground than before. ClickUp's CEO has talked about new salary bands for exactly this person, a fleet operator on a much bigger scope clearing a million dollars. The same company recently cut 22% of its staff. Fewer people, paid much more. For someone running a solved workflow with nothing new to add, the opposite pressure sets in: that slice of the job keeps thinning, and the move is to climb up the value chain into the parts that still need a human. Most essays on this topic skip that tension. But you can feel it coming, and the test above is how you stay ahead of it.

The insight an operator feeds back has to land somewhere. That somewhere turns out to be the most important machine in the company. It's also where the moat went.

The moat moves into the eval loop

Take a procurement agent. The job is to match what the company needs to buy against a catalogue of vendors, find substitutes when the exact part isn't available, and pull the right specs out of messy product descriptions.

The whole game is getting the output trustworthy enough to act on. That only works if you build the pieces underneath it, in order:

• Trust the input. Clean the catalogue first: strip out duplicate products and vendors so the agent reads something consistent instead of garbage. Nothing downstream is worth anything until this part is solid.
• Run a standard process. A sequence of Skills, and a harness around them that knows which Skill to call when and prompts itself to the next step. Substitute detection, then spec extraction, then matching.
• Evaluate the output objectively. A golden dataset of known-good matches labelled by people who actually know procurement, plus the thresholds the output has to clear. You score each run against it, often with an LLM as the judge. Without it, you can't tell a good run from a bad one.
• Handle the output by score. Good enough to act on? Needs a human check? A second pass? A fallback when the agent can't find a match? Each outcome routes somewhere, and you decide where.
• Fold the learnings back in. Every loop throws up edge cases the agent got wrong. Those go back into the golden dataset and the Skills, so the next iteration is sharper. That's the part that compounds.

There's a cost to this that people gloss over. For a while, all of it makes things worse. While the workflow is still ramping up, a human reviews every match the agent proposes, because a wrong substitute means a bad purchase order with real money attached. The agent adds work before it removes any. The cost goes up before it comes down. Knowing when a loop has earned more autonomy, when you can stop reviewing every output and let it run, is the actual job.

Now look at what you've built, and you'll see where the moat went.

What's copyable is the idea. A competitor can see that you run a procurement agent and stand up their own first version in an afternoon. They can buy the same models and wire up the same tools.

What they can't copy is everything that makes yours actually work. The Skills refined against eighteen months of your own edge cases. The golden dataset labelled by people who know your business. The judge rubric you've tuned. The routing you've worked out for when an agent runs on its own and when a human has to step in. The hard-won feel for when a loop has earned more autonomy. That whole apparatus, the refined Skills, the data, the evals, and the process you've built around your people and agents, plus the speed at which you keep improving all of it, is the part that doesn't copy.

So the moat moved. It used to live in people's heads as tribal knowledge. Now it lives in your evals, the proprietary data you accumulate by running the loop, and the process that decides how humans and agents work together to produce something you can trust. All three compound.

And notice who keeps it alive. The operator from a minute ago, the one still asking “am I adding something new,” is the person generating the signal that fills the golden dataset.

Their job security and the company's moat are the same asset.

The operator who keeps learning is how the moat renews itself.

Which raises the obvious question. Someone has to own that golden dataset. Someone has to decide when the loop has earned more autonomy, spot the patterns across every operator's edge cases, and keep the whole thing pointed at what the business actually needs this quarter. That someone is the manager. And their job is about to change more than anyone's.

The case for managers disappearing

There's a popular narrative that the manager disappears. It's worth taking seriously, because a lot of smart people believe it.

The story goes like this. Leaders set direction and own the P&L, so they make the money. Operators do the work, and now each one runs their own fleet of agents, so they cover what used to take a whole team. The middle layer was always there to translate between the two and to coordinate people. Take away the coordination problem and you've taken away the manager. The org flattens to founders and operators, and everyone in between is overhead.

I understand the appeal. If you've only ever seen managers run status meetings and forward emails, removing them looks like pure upside.

But it doesn't survive contact with how this actually plays out.

Why the manager is the part that survives

Three reasons, and they compound.

First, we never reach full autonomy. There's always a residue of judgement, the edge cases the loop can't close, the calls where being wrong is expensive. Someone has to own that residue, and own the decision of how much autonomy each loop has earned. That decision moves every week as the agents get better and the work changes.

Second, autonomy frees up the operator's hands, but it does nothing for their field of view. The person running the work is heads-down by definition. They can't see the pattern across their own twenty edge cases, let alone across the whole team's. Somebody has to lift their head, look across all of it, and notice that three reps keep losing the same kind of deal for the same reason. That perspective is a full-time job, and it's a different job from doing the work.

Third, the churn never stops. People leave. New people join. Skills go stale. The market moves under your feet. Companies are leaky buckets, and somebody is accountable for the bucket: hiring, ramping the new person fast, keeping the team's Skills current. That's not HR's job, and it's not the leadership team's job. It's the manager's.

Put those together and the manager becomes the glue between three things: what leadership wants, the company's accumulated knowledge, and the workforce of humans and agents actually executing.

This is a re-founded role.

The new manager owns evals and curates the golden dataset.

That's a real technical skill most of them don't have yet. They read the output, spot the drift, and fold new learnings back into the Skills. They're also accountable for the plumbing now, working with tech and ops to keep the agent setup healthy and secure as the team leans on it more. It's the same shift the operators go through, one level up: the work moves from running the process to improving it.

Day to day it splits the way it always did, into managing down and managing up.

Managing down, the new manager:

• Observes and evaluates the output of the team's Skills and agents.
• Folds new learnings and edge cases back into the Skills.
• Steers new joiners onto the right setup so they get up to speed quickly.

Managing up, the new manager:

• Logs decisions and market signal into the company's shared brain.
• Pushes for more autonomy across their agents, to widen the team's scope and coverage.
• Fights for the budget to unlock the next initiative.
• Keeps the agent setup healthy, robust and secure as it scales, working with tech and ops.
• Manages the cost-to-autonomy trade-off, pushing more work onto agents where it pays for itself and keeping the LLM bill under control.

That second list only works if there's something to manage up into. A place where decisions, market signal and playbooks actually live. Most companies don't have that yet. It's the missing piece.

The company brain

A company brain is a shared layer that sits between three things: your sources of truth (the ERP, the CRM, meeting transcripts, Slack), your team (playbooks, who can do what), and your agents (the Skills and workflows). Something built on a tool like Obsidian works well, because it's just linked text that both people and agents can read.

A simple structure that connects the dots:

• /decision - where you log the calls you've made and why.
• /market - where you track what's moving in your space and how your ideal customer is changing.
• /client - where you keep a running log of client conversations.
• /playbook - the sequence of Skills and human judgement that delivers a piece of work end to end. Think a go-to-market motion, or launching in a new market.
• /agent - where each agent gets its context block, with instructions on how to use everything above.

An example makes it concrete.

Yesterday you decided to stop charging a five thousand euro setup fee and to run setup for free instead. You made that call for two reasons. A competitor just did the same thing, which is market signal. And you'd lost a run of deals on exactly that fee, which you found by pulling call transcripts and running web research overnight, which is client signal. You logged the decision in the leadership meeting.

Now the sales playbook updates itself. The play for turning a demo into a paying customer used to build a three-tier proposal with day rates for setup. From today, it drops the setup line and adds a coaching cue for the rep: introduce the free setup as a thirty-day offer, early in the call.

One decision, made at the top, propagated all the way down into how a rep runs their next conversation, without a single all-hands to explain it. That's what the brain buys you. It's also where the manager does most of their managing up, by keeping it current.

And the leaders?

From the top, the job changes too, though more quietly.

Leaders get to stay current without sitting in every meeting, through a layer that keeps a live pulse on the core initiatives, the key clients, and the business KPIs. Something like Hermes does this. They check the pulse, and they delegate against it.

Then three things land squarely on them.

They set governance. The red lines: who gets access to what data, which agents can act without a human, where the strict guardrails sit. And inside those lines, they decide how hard to push toward autonomy versus keeping a human in the loop, a judgement call based on where they think the market and the tech are heading.

They decide where the freed-up capacity goes. As more workflows run on their own, the operators and their agents have time back. The leader's job is to work out where that new capacity earns the most: the new market, the new product line, the deeper moat.

And they manage the tensions that don't have clean answers:

• LLM cost against the cost of doing the work by hand.
• Autonomy versus oversight - how much to let agents run on their own versus keeping a human in the loop.
• The moat - where it goes next: what new data to capture, and how to act on it before anyone else.

That last tension is the one we opened with. Codifying your knowledge does flatten the old moat. The leader's job is to make sure a new one is forming at the same time, in the data and the evals that only your loop produces.

So, is AI coming for your job?

For your work, yes. Hand it the repeatable part. What grows back in its place is bigger than what it replaced, and it looks different at each layer.

As an operator, you do less of the repeatable work and more of the work that teaches the system something new. Your value is the signal you add that the Skill didn't already have. Keep adding it and you become a fleet operator with real scope. Stop, and the loop catches up with you.

As a manager, you stop running status meetings and start owning the part that doesn't automate: the judgement on the edge cases, the patterns across the team, the evals that keep the loops honest. You become the glue between what leadership wants and what the workforce of humans and agents actually does. It's a bigger job than before, and a harder one.

As a leader, you spend less time in the work and more time deciding where the freed-up capacity should go, and where the next moat is being built while the old one erodes.

The Skills themselves get copied. What compounds is the loop underneath them, and the people who keep improving it: the operator adding new signal, the manager spotting the patterns and keeping the evals honest, the leader deciding where the freed-up time goes next.

Most companies are barely starting on this, and nobody has it fully figured out, us included.

But the work gets more interesting at every layer, and that's a good enough reason to start.