What I didn’t expect, when I started writing this part, was that the answer to where does that pod run would change under me in a few weeks.

What showed up this summer

Since August, a wave of products has launched that are, underneath, the same thing. The most visible are Grok Bot, Muse, and Instinct. An agent that runs around the clock on a computer the vendor operates, with a browser, an email connection, a calendar, a way to pay for things, and memory that carries over between sessions. Each started from a different wedge: one out of a social network, one out of a family of consumer apps, one out of a text thread. They’re all heading to the same place: an agent with full control of a machine, doing what a person at a computer does, whether or not anyone is watching.

None of this is new to the founders I know who have been running their own version of it, on a Mac mini or a rented server, since the spring. What’s new is that it’s packaged. The closed products are a more mature version of the same idea, with the rough edges filed off, the connectors pre-wired, and someone else patching the box.

The difference from the chat assistants most people use is not intelligence. It’s who starts the work. A chat session begins when a person opens it and ends when they close it. These agents invert that. They check the mail at seven, notice the schedule changed at two, chase the vendor, and come back the way a good executive assistant does, with the one thing they need from you to keep going. Approve this. Pick one of these two. The person stops being the operator and becomes the one who unblocks.

I’ve been a heavy user of Muse since a few days after it launched, and I had a fair comparison ready. Earlier this year I’d built my own agents for family logistics: the calendar, the school and club emails, the reminders, all driven by cron jobs I maintained. So I ran the same use case through both, side by side. The product experience is much smoother. It handled the schedule changes and the reminders at least as well as mine did, and it took me out of the maintenance work entirely, which is the part I hadn’t valued properly until it was gone. Within a week it had replaced them.

The infrastructure is the same

If you look past the packaging, every one of these products is the same seven layers, and so is every open framework that does the same job.

• A machine that persists.

• A harness on it, the scaffolding that turns a model into something that wakes up, checks things, and keeps state.

• Memory.

• An identity, the address and accounts the agent acts through.

• Connectors to the tools.

• A broker that decides what the agent may do.

• A model.

One detail changed how I think about the price tags. I asked the agent I use what it was running on. Two cores, eight gigabytes of memory, a small disk, a stock Linux. That’s the smallest machine any cloud provider sells, five to twelve dollars a month. Nobody is paying for the machine. They’re paying for the other six layers, assembled, and for not being the person who maintains them.

Which is why I don’t think build-versus-buy is the interesting question here. It blurs what is going on. The question worth asking is what the closed products won’t let you do, and why.

Closed agents and open agents

The agent layer is now splitting the way the LLM model layer did. There are closed setups, where the vendor owns the machine, the harness, the memory, the identity, and the model, and you use it on their terms. And there are open setups, where the same seven layers run on something you control and any model or agent can plug in. The memory in an open setup doesn’t have to be a folder of files, either. It can be a database, or a repository under version control so every change to what the agent knows is tracked and reversible. How to structure that memory is a topic of its own, and we’ll go into it properly later in the series.

The closed ones share one constraint that isn’t a bug. None of them will let another agent in. Grok Bot runs only xAI models. Muse runs only Meta’s. Instinct is proprietary end to end. This is structural, not temporary. Every one of these companies is competing to be the entry point, the thing you open first and the thing everything else routes through. Letting a competitor’s agent onto the box would give away the position they’re spending the subsidy to win.

And the entry point is worth a great deal to them because of what accumulates there. Every correction you make to the agent’s work, every preference it learns, every account it opens under an address on their domain. That’s the layer that compounds. It’s also the layer that makes leaving expensive. Some of them will let you export the memory as a plain file, which is worth doing regularly. I did, and what came back was one file: facts and workflow rules, already filtered by the agent’s own judgment about what mattered. It was accurate. It was also all I could see. I have no view of how it will organise that memory when the data grows, what it will keep and drop when the context is mixed, or which of the tasks it runs on its own it will prioritise when they conflict. That’s not a complaint about the product. It’s the nature of the arrangement: the memory is managed for you, and therefore out of your control. And the correction history, the accounts, and the identity stay theirs unless you built it otherwise.

The open side is further along than most people assume. OpenClaw is the infrastructure, Hermes is the closest thing to a product, and there are already projects that skip shipping an agent altogether and simply run the agent subscriptions you already pay for as the bots. The agent is a worker you can swap. The setup is what you keep.

I use several agents side by side. Each is wired better into something than the others, the way people are, and the best one for a given job has changed every few months. That’s the argument for the open setup in one sentence. In a closed product, you get one agent, on its terms, until you leave. In an open one, the newest agent plugs into the same memory, the same identity, and the same keys the day it ships, and the old one goes without taking a year of context with it.

I don’t think one side wins this. Open and closed models have ended up side by side, and I expect the same here: closed agents for the person who wants it to work on day one, open setups for anyone who needs to choose their agents and keep their memory. For a business, that second description is usually the right one. But the closed products are ahead today on the things that matter most to someone who isn’t technical, and that’s worth being honest about.

What the closed ones are teaching

The closed products are the spec for what an open setup should have, and each has solved one layer well.

• Muse: the broker. Every action the agent takes is approved by something outside the model, grants are scoped to a connector and a task and expire, and one-time codes and password resets are filtered out of the mail the agent can read. This is the layer the open frameworks are weakest on; OpenClaw’s second major release shipped without sandboxing on by default, and its skills marketplace has already had a malicious skill found in it.

• Instinct: the identity. The agent gets its own email address, so its actions are attributable, it can open accounts as itself, and revoking it is one deletion. The idea is right. The address should be on your domain, not theirs.

• Grok Bot: the reach. The agent can work inside the user’s own laptop. It’s the most powerful thing any of them do, and it collapses the boundary the separate machine existed to provide. Worth having, worth doing deliberately.

• All of them: the habits. One machine per pod, a log a person can read, and coming back for approval rather than asking permission up front. Those transfer directly.

The sequence

So what I’d suggest to an owner is not a choice between building and buying. It’s both, in order.

Rent one now. Feel what it’s like to have something run overnight and come back with one question. Learn the approval habit. Keep the exported memory in a folder you own from the first week.

Then, at the first tell, build your own. The tell is usually one of three:

• You want an agent the vendor won’t allow.

• The data is something you couldn’t explain to a client.

• A second person needs a pod of their own that reads from the same memory.

That last one is where the questions change, and it’s what Part 4 is about.

The 24/7 agent is here, and it’s worth using today. Don’t marry the first one.

Next: the second pod. What happens to memory, keys, and privacy when a team shares them.

→ A group of us are running our businesses through AI agents and sharing what works as we go. If that's you, or you'd like it to be, join the community. The next part goes into the open setups in detail: memory, keys, and privacy once a team shares them. Subscribe if you want it when it lands.

“How many agents should I have, and what should each one do?”

It’s a reasonable question. It’s also, underneath, a question about boundaries: where one ends, where the next begins, what belongs to each.

And it’s the same question companies have always asked about people. Which is the first clue that something is off, because the answer we developed for people is the one thing you shouldn’t copy.

You can’t draw a boundary around a unit nobody has defined

Start with what’s actually running. Inside a single account you might have several different agent types — one model writing code, another doing research, another handling operations — each running many sessions at once. Some finish in a minute. Some own a piece of work for weeks.

Is that one agent? Four? Forty?

Nobody has settled this, and it matters more than it sounds. Because the moment you decide an agent is a discrete worker, you start doing what we have always done with discrete workers.

The boundary most people draw: function

So the roster gets written. A marketing agent. A sales agent. A support agent. Each gets its own scoped memory — marketing data for the marketing one, tickets for support — and they pass work across the lines between them.

It feels organized. It looks like a company.

It is also the org chart, rebuilt in software. And here’s the part worth sitting with: you haven’t removed the cost of all that process and coordination. You’ve transferred it from people to agents. The same gates, the same hand-offs, the same waiting — now paid in tokens, orchestration code and latency instead of meetings and status updates. Cheaper per unit, certainly. Same shape.

Part 1 landed on two things as the real bottleneck: the cost of coordination, and knowledge trapped inside individuals where nothing else could reach it. Neither is an accident of any particular company. They are what a structure built out of fixed functions produces. Functions require hand-offs, and hand-offs are coordination. Functions scope knowledge to a role, and scoped knowledge is fragmented knowledge.

Why we organized by function in the first place

Which raises the question worth asking before you copy it: why did we ever organize this way? The answer isn’t tradition. It’s economics — human economics specifically.

A person takes years to become genuinely good at a domain. Learning is slow, it happens at one speed, and it doesn’t transfer cheaply. Moving someone between domains is expensive: they pay a ramp, they carry a reload cost every time they switch, and for months they aren’t much use. So you park a person in a domain and let that investment amortize over a career. Function is a rational answer to how humans learn. Given the constraints, it was the right design.

Now check those constraints against an agent.

An agent doesn’t spend three years becoming competent at billing; it reads what’s there. Moving it from billing to onboarding costs approximately nothing — no ramp, no reload, no career to manage. Its learning is fast and its context switching is close to free. The two costs that made specialization worth paying for aren’t there.

Agents do have a real limit, and it’s worth being precise: the context window. But notice it’s a different kind of limit. It bounds how much can be held at once for a single task. It doesn’t bound what can be learned over a lifetime, because there is no lifetime — every session starts fresh. You solve a context-window limit with retrieval and good information architecture. You do not solve it by permanently assigning an agent to a department.

So when you scope an agent by function, you’re importing a constraint it doesn’t have in order to solve a problem it doesn’t have. An agent org chart doesn’t fragment context in some abstract way — it manufactures, in software, the exact two things Part 1 named as the bottleneck. Every boundary is a hand-off. Every scoped memory is knowledge trapped where nothing else can reach it.

You’d be rebuilding the bottleneck at machine speed, and paying to maintain it.

The pod, not the department

There’s a better image, and it comes from how modern infrastructure already schedules work.

In a Kubernetes cluster the unit isn’t the container. It’s the pod — a small group of containers brought up together because they need to work on the same thing. They’re deliberately heterogeneous: they do different jobs and complement each other. They share context by design, because that’s the point of being in the same pod rather than scattered across the cluster. And the pod is temporary. It exists for the workload, then goes away, and the next workload gets a pod composed differently.

Nothing about that is organized by function. There is no marketing node.

That’s the shape worth borrowing: start with the problem, assemble the capability around it, finish, disband, recombine differently next time. First the problem, then the team. I see it in the teams I work with well before anyone writes it down as policy — the project that got done by one person and a few agents instead of a staffed cross-functional group, the team that formed around a customer problem and quietly dissolved afterward without a reorganization.

And the interesting part is that humans and agents belong in the same pod. A question comes up; the people and the agents it needs come together around it, working from the whole context rather than a slice scoped to their function. They solve it. Then the composition changes, because the next question needs something different. One pool of capability containing both kinds — not a human org over here and an agent roster over there.

What the person in the pod is actually for

Which raises the obvious objection: an agent absorbs the whole context in seconds and a person cannot, so “the pod works from the whole context” is true for one half of it and impossible for the other.

Part of that is a misreading — the pod holds the context, not each member. In a cluster, containers share a volume; that doesn’t mean each one reads every file. Nobody expects the person to out-read the agent.

But the better answer is that reading was never the job. Two things are, and both scale.

Authorization. When an agent acts on something real — signs into an account, touches a system, spends money — somebody has to be accountable for that action. This is where the tooling has actually landed: credentials get delivered just-in-time, the agent never sees the secret, and a person approves the moment of access. Notice what that is and isn’t. The human isn’t checking the agent’s work. They’re answering a narrower question — may this act happen here — and that question takes seconds, not a review cycle. It’s the highest-value human-in-the-loop moment precisely because it’s the one that can’t be delegated: accountability doesn’t transfer to something that can’t be held responsible.

Outside context, and the standard. The agent’s world is everything written down. The human’s world is the part that isn’t — what the client said and then didn’t say, the hesitation in the room, the thing that only surfaces on the third call. The person brings that in; the agent turns it into something the organization keeps.

And then the piece that decides whether any of this scales: the human defines and improves the criteria by which work gets judged — not the judgment of each output. What counts as done. What we’d never ship. Which failure matters. Set that well and the evaluation runs without you, and gets sharper each time you correct it. Try to personally assess every result and you’ve made yourself the review gate — the exact bottleneck Part 1 was about, wearing a new costume.

That’s the line I’d hold. The human is not in the pod to out-work the agents, and not to approve their homework. They’re there to be accountable for what the pod is allowed to do, to supply the context no system has, and to keep sharpening the definition of good.

Two honest limits. This holds where failure is felt; where it’s silent or delayed — security, compliance — “the client seems happy” is not evidence, and you need real expertise in the loop. And writing good criteria is its own competence, not the same skill as reviewing work, and not what most organizations have spent the last decade promoting people for.

When the pod is the unit

That’s the shift worth naming, and it’s larger than anything about agents. The unit of organization stops being the team and becomes the pod.

For most of the last century the unit was the standing team — a group defined by function that persisted whether or not there was a problem in front of it. Almost everything we call coordination exists to serve that arrangement: status meetings, alignment sessions, reporting lines, the quarterly ritual of demonstrating the group should continue to exist. A permanent structure needs constant maintenance just to stay pointed at something.

Make the pod the unit and most of that machinery has nothing left to hold onto. A pod exists because a problem exists. It has no headcount to justify, no lane to defend, no reason to persist past the thing it was assembled for. Which leaves exactly one thing worth coordinating on: whether the problem got solved.

When the unit is temporary, results are the only durable measure of it. You don’t have to install that, or launch a program to encourage it. It falls out of the structure.

So the question was never how many agents you need, or which function each one belongs to. It’s what the problem is, who — human or otherwise — should be in the room for it, and whether the thing actually got solved.

I’ve heard a version of that from almost every org leader and business owner who has made good progress on AI adoption. Earlier this year, the energy ran in the other direction — a big wave of chasing AI-tool adoption: usage dashboards, internal leaderboards, what percent of the team was on Claude or Cursor by Friday. Lately some of the more advanced companies have started to pull back. Uber is the clearest public example: after driving AI usage to nearly every engineer, it capped per-engineer spending when it couldn’t connect all that usage to the business actually moving faster. The pullback isn’t because adoption was a mistake — it’s that they’ve already claimed that fruit, and found it was the straightforward part of the puzzle. Driving adoption isn’t nothing; it’s just one piece, and the easier one. The harder parts are still sitting there untouched, which is why the usage charts can climb while the business moves at the same speed it always did.

I’ve spent time on both sides of this. I know how organizations and their processes were built in the pre-AI era, and I’m now building — and helping others build — toward AI-native. From that seat, the gap is hard to miss. So the pullback doesn’t surprise me.

What companies actually compete on now

For the last twenty years, “going digital” was mostly about getting things online — information online, process online, data online. That race is largely over; most companies finished it. The next decade looks different. What increasingly separates companies isn’t who has the data. It’s how fast they can learn, decide, and execute.

That’s the shift most adoption plans underestimate. AI isn’t only changing how individual employees work. It’s changing how the whole organization runs.

The biggest cost has flipped

Think about what used to be scarce and expensive: building things, R&D, getting information. Those are exactly what AI is making cheap — content, analysis, software, research, all dropping in cost by the month. What’s scarce now sits one level up: management attention, how well the organization coordinates, the quality of its decisions, the speed of its execution.

Building keeps getting cheaper. The hard part is the coordination around it — and that’s what the next era of competition turns on.

This is why pouring AI into the existing org doesn’t move the top line. You speed up the one part that was already getting cheaper — the building — while everything around it stays exactly as slow as before. The new speed runs straight into the old coordination and piles up there.

What “AI-native” actually means

Strip it down, and an AI-native company is one where the absolute core of how the organization functions — its operations, execution, scaling, and cost structure — is built around AI, not bolted onto a structure designed for a world without it.

Most companies aren’t there, and that’s fine — it’s a spectrum, not a switch. At the far left are companies barely using AI at all; that’s the starting line, and plenty are still standing on it. Past that, three markers matter:

AI-augmented — tools on top. Everyone’s using the tools — Claude, Codex, Cursor, Copilot. Getting even this far is real work; rolling tools out across a whole company is genuinely hard, because change is hard. But the processes are still designed around how people work, and the knowledge is scattered — so the tools can’t yet show what they’re worth. This is the augmented end: AI bolted onto an organization built for a pre-AI world.

AI-redesigned — rebuilt around AI. Process and organization rebuilt around what AI can actually do, and visibly faster for it — roughly where most of the AI labs themselves operate today. Worth being precise here: even at this stage, people are still at the center of execution — steering the work, judging it, owning the calls. The speed comes from the redesign, not from removing the humans.

AI-native — built on AI. The far end — what some are calling the one-person company. The core of how the organization runs is built entirely around AI: it carries most of the decisions and execution, while people focus on bringing in outside signal and steering the whole system.

The line that matters runs between the first point and the rest. The augmented end treats AI as a tool layered on top of the existing process. The other end rebuilds the organization around it. That is the key difference between AI adoption and AI transformation.

And notice how little of that line is about token consumption — about how much AI you use. It’s about who owns what, where decisions actually get made, and where the company’s knowledge lives.

Why most companies are stuck at the augmented end

And here’s the answer to the puzzle I opened with. The reason adoption isn’t showing up as speed is that most companies are parked at the augmented end — tools bought, everyone using them, and the potential still bottled up.

It isn’t a technology problem. MIT’s 2025 study of enterprise AI found that 95% of generative-AI pilots delivered no real return — and concluded the gap wasn’t model quality but organization.

The list of blockers is long — the usage charts are just the tip. Below the iceberg waterline sit incentives that reward usage over outcomes, a culture where everything waits on approval, context scattered across a dozen tools, and more. Two of them are load-bearing:

The process was built for pipeline. Reviews, approvals, alignment meetings — all designed around how humans coordinate, not around what AI can do. Push AI into that, and you get small patches, not a step change.

The knowledge is trapped in individuals. The experience and judgment that actually matter live in meetings, chat threads, and people’s heads. AI can’t reach any of it, so its output stays generic.

The gap, in other words, isn’t the tools. It’s the process and the knowledge.

The way across

Moving off the augmented end starts in one place: getting the organization’s knowledge out of scattered heads and meetings and into something durable — a corporate second brain that captures the company’s decisions, experience, and judgment, and feeds them continuously back to the AI. That’s the foundation the rest stands on. When the organization can actually learn — not just type faster — the speed finally reaches the top.

How to build that second brain — what to capture, how to structure it, how a single decision becomes something reusable — is what I’ll be writing about across the rest of this series.

When I shared on how AI-native orgs look like in part 3 — the way the work is reshaping, why this moment isn’t really about switching chairs between IC and manager. A friend of mine cracked back:

“Many of you want to become Director or VP. Well — now you’ve got hundreds of AI agents to manage.”

A joke — with enough truth in it to reveal the reality: everyone is now expected to show up at their N+ level. At the AI-native edge, the top companies have moved the hiring bar — job descriptions now call for "a proven track record of stepping into 0 to 1 environments." Pedigree weighs less than evidence now.

Most career advice for this moment still tells you to ship more, run sharper alignment meetings, manage up harder, introduce better processes. AI is folding all of them. Investing more there is investing in the past.

So — how do you prepare?

What follows is a way to think about it. A framework for where to put your finite time and attention. The rubric goes stale fast because your management is playing the same catch-up you are.

Three altitudes — how you see the work, how you see your time, how you see yourself. None of these are in the rubric. Some are unwritten rules— what calibration rooms quietly value without naming. The AI era is just weighting them more heavily, and pulling them down to apply at every level.

How you see the work

The first shift is from seeing yourself as an executor of pieces to seeing yourself as a problem framer.

Most of us were trained to wait for the problem to arrive defined, then execute. Your leader figures out what to do; you make it happen. That made sense when coordination was expensive and decisions were scarce. AI made coordination cheap. The easy decisions got cheap too. What’s harder now isn’t shipping the work — it’s framing the problem in the first place. Mapping where the bottleneck actually lives. Deciding what to build that the system can absorb.

When I was a manager venting to a mentor about a product I was frustrated with — the team was capable, but the strategy upstream felt off — her answer wasn’t to influence the product team. It was to fix the product myself. She looked at me and said: stop seeing this as your product team’s problem to solve. See it as if you were the CEO of this product. True ownership isn’t doing the execution. It’s seeing potential, finding creative ways to push forward, and absorbing the failed bets as sharpening for the next. That single shift was what built the cross-functional muscle I drew on for director and beyond.

A staff engineer I worked with at Instacart was already operating this way. We’d been hypothesizing AI-enabled marketing infrastructure to power our growth experiments — obvious now; less obvious a year or two ago. The pushback hadn’t been about vision; people believed in the bet. They worried about the distraction cost — pulling attention from work that already had committed business impact. So instead of pushing for headcount, he spent his weekends hacking out a prototype and testing it with the internal marketing team on limited channels. A few months later, leadership realized we needed this infra — and was pleasantly surprised to find it already in place. The infra he’d built accelerated the bet, and product set the priority.

When you see the work this way, end-to-end ownership stops being a stretch — it’s the natural shape of how you operate. So does pruning processes that no longer serve, and staying close to the customer to hear what the system isn’t telling you. They’re consequences of the framing.

At junior level, this kind of move sometimes gets feedback like stepped on other people’s toes. At senior levels it’s an explicit expectation. How you see the work decides how you show up.

How you see your time

Are you still going by agenda?

Most people in tech are. They let other people’s calendars decide where their hours go. Coordination meetings, alignment syncs, one-off requests, status updates. When you tally up where the day went, most of it went there.

The discipline is treating your time as precious. Sort what’s coordination, what’s one-off, what’s actually building the system underneath your work. The system underneath is what compounds. The other two don’t.

A senior staff leader I worked with operated at the edge of this. He was quiet in bullshit meetings — didn’t perform engagement, didn’t fill silence. He wasn’t very responsive on Slack either. From the outside, easy to misread as disengaged. From the inside, he was spending his real time identifying levers and opportunities. He’d invested in relationship-building with his manager peers and kept his resource asks small. When the moment came, the tiger team formed fast. Significant business impact landed. After it did, he gave credit to the leads who’d sponsored him on resourcing. They moved on to form bigger partnerships.

His promotion discussion was controversial. People who valued coordination and alignment didn’t like him. People who admired entrepreneurship loved him — they could see the enormous value he was going to generate for the business. We ended up making an exception — we wanted to encourage more engineers like him.

The conventional path to promotion rewards broad visibility — being in every meeting, replying fast on Slack, performing engagement. He didn’t reject visibility. He picked where to invest it: targeted trust with the manager peers who’d matter for resourcing, plus the system thinking that produced the impact. The hours he saved from broad engagement bought the time for both. They were the same skill.

Naval Ravikant has reshaped how I think about my time. “Set an aspirational hourly rate” — put a floor on your hours, refuse what doesn’t clear it. “Work like a lion, not a cow.” Most corporate life isn’t even cow-like; it’s a hamster wheel — constantly running, never resting. The hours below the rate are what AI is making cheaper. The hours like a lion are where everything compounds.

How you see yourself

Last comes how you see yourself — who you’re choosing to become in the work.

The conventional path tells you who to be — the role, the next step, what success looks like. It works until you notice you’ve been optimizing for someone else’s definition of you for ten years.

The question AI is making harder to avoid: what would I want to be building inside myself, if no one was measuring? The bets you make and risks you absorb don’t just shape your career. They shape who you become while doing the work.

A pattern keeps surfacing in the women-in-tech communities I was part of. When senior leads look back, the regret that comes up most often isn’t I should have networked harder or I should have been louder. It’s I didn’t take enough risk. Deeper: I let the rubric write my story when I could have been writing it myself.

A few years back, a tech lead I worked with had a promotion path lined up on her team. She walked away to move into machine learning — out of curiosity, not fear of falling behind. The move took courage and potential reset. The transition took real effort. What she didn’t predict: it made her more competent on the job market than the safer-track version of her would have been. The bet on her curiosity paid the most.

Don’t limit your curiosity by your role, title, level, function, or company. AI-native work runs on problem-framing, and curiosity is what helps you see problems worth framing. Walk outside your company. Network. Exchange ideas with people doing different work. You’ll notice you’re not alone. The rubric inside one company looks smaller when you can see the work happening across many.

I know this pattern well. I played the safe card for years myself, afraid of failing — optimized for higher pay and a better title. But I started to ask myself this question in recent years: who am I without the title? This year, AI is forcing many people into the same question.

All we can bring with us is the experience. The titles change shape. The companies change. What stays is what you built inside yourself — and who you became while you were building it.

What folds, what overlaps, what’s fresh

Some tactical examples to guide your framework. The skills above sort into three buckets.

The ones AI is folding — shipping faster, running alignment meetings, managing up, introducing more processes — are what conventional R&D has rewarded most at junior levels. Investing more there is investing in the past.

The ones that overlap with what senior leaders have always done well — problem framing, end-to-end ownership, system thinking — have always compounded. The AI era is amplifying them and asking you for them earlier than the rubric measures.

The ones that are new skills to pickup — managing your AI agents like a team, killing meetings and processes that create bottlenecks, taking the venture bets the rubric can’t measure yet — are where the AI-native edge differentiates. Even senior leaders historically didn’t have to invest much here. The era is changing the bar.

Where to put your energy

The energy you’ve been spending — on whether you’ll get promoted next quarter, whether the layoffs will reach you, whether your manager is happy with you, whether you should work harder just to keep the job — that’s fear-driven. It’s what the rubric trains you to care about. It’s not what compounds.

The shift isn’t from fear to love overnight. The fears are real — the rubric still partly governs your runway. But when you notice the rubric is outdated for the work that’s actually coming, you can start to release some of the fear pinned to it. Try using that released energy to pick up something that gives you energy back.

You don’t have to take it all on at once. Build slowly.

The next time you’re choosing between the safe project and the unclear one, notice what you’re optimizing for. The rubric — or the work that’s already coming. One you can’t take with you. The other becomes who you are.

That’s the four-part series. Part 1 on system thinking. Part 2 on the harness. Part 3 on what the org looks like. And this one — what to invest in inside it.

About Amy Wu

I’m an executive and life coach who works with leaders navigating inflection points — including the one AI is creating right now. If you’re sorting through what to invest in for what comes next, I’d love to hear what you’re seeing.

→ Schedule a conversation

A version of this comes up in almost every coaching conversation I have. My answer is the same one I’ve given for years. Find out how your managers actually spend their time, and whether the title is still where influence sits in your company. That depends on stage, on culture, and now on how AI-native the org is.

AI isn’t just speeding up work. It’s reshaping what each role does. The better question is: what does the work look like inside an AI-native org?

In Part 1, I argued the AI era needs leaders who think in systems, not workflows. In Part 2, I described what that system looks like — two harnesses, one around the agents, one around the people. This piece is about what those harnesses actually do, day to day.

Two patterns of work

Inside the harness from Part 2, the work in an AI-native org sorts into two patterns. Both run at once, in different ratios depending on stage and bet.

Pattern one: iterative work on a real, running business. Existing product. Existing customers. Continuous experiments — pricing, onboarding, retention, feature shipping. The bulk of execution.

Pattern two: frontier work. New business line. Big pivot. A hypothesis nobody’s run yet. The bets that decide whether the company gets a second chapter.

A conventional R&D org has many function ladders, each many layers deep, connected by cross-functional review forums between layers. The AI-native version collapses all of it — the ladders merge, the middle layers go, the x-functional forums mostly go too.

In an AI-native org, influence and the decision-making room aren’t gated by a management title — they go to whoever’s running the harness well, owning a problem end to end, or pushing into the frontier. Regardless of Title.

The two harnesses operate differently in each pattern. I’ll take them in turn.

Pattern 1: Iterative work — one person plus an agent team

The shift inside iterative work is simple to name and hard to internalize.

One person, paired with an agent team, drives a piece of work end-to-end. Not “designer hands off to engineer hands off to QA hands off to PM.” One person owns the whole loop — frame the experiment, ship it, measure it, decide what to do next.

Which means everyone, regardless of role, ends up spending more time deciding what to do than doing it. The doing is harnessing the agents. The deciding is what fills the day.

This is where the two harnesses earn their weight.

The agent system harness — mostly IC work

Inside iterative work, the way you use your agents is the load-bearing variable. The difference between an IC who gets ten times more output and an IC who gets the same output as before is almost never which model they’re using. It’s how they’re feeding the model context.

In an AI-native org, every IC ends up managing a small agent team — whether or not the title says so. The quality of what comes back depends on how much of the relevant context you’ve actually gathered before asking, how you’ve structured that context — what’s signal, what’s noise — and how you supervise the output. What you re-prompt. What you accept. What you correct.

What the IC is doing here is management. Delegation. Defining scope. Setting up the system. Reviewing output and giving feedback. Deciding what gets shipped, what gets revised, what gets thrown away. These were always management skills. They’re now essential for anyone working with agents — title or no title. Some of the most effective people I see in AI-native orgs have an IC title and a manager’s day.

This is craft, and it doesn’t transfer instantly from old habits. The ICs running this well are still in their first year of it — learning to manage agents the way they once learned to manage their own attention. The orgs whose ICs are doing this are starting to run circles around orgs whose ICs are still treating LLMs as autocomplete.

The people system harness — mostly leader work

The leader’s harness inside iterative work is the layer above. Two design choices show up over and over.

The first is bottleneck management. Inside an existing org, you already have processes — experiment review, design review, layers of approval. Those processes were built for human throughput. When agents start producing five times more drafts, those review layers tend to become the bottleneck almost immediately. The work doesn’t get faster. It piles up at the choke point. Your job as a leader is not to set a speed goal and walk away. It’s to watch where the system is starting to clog and redesign that layer before it locks.

The second is end-to-end ownership. Let one person own a problem all the way through, regardless of role. If it’s too big, break it into smaller problems — but don’t break it across two people. Two people on the same problem reintroduces the coordination tax that the agent harness was supposed to release.

These are leader moves. They don’t happen on their own.

Pattern 2: Frontier work — go to the edge

Frontier work doesn’t run on the same harness. It can’t. The whole point is that there isn’t a known pattern yet.

Frontier work has a different shape. People go to the frontier — talk to potential customers, talk to people doing the research, read what’s being published, pull on threads. Frame the problem one way, watch it not work, reframe it. Bring what they’ve learned back to the team. Decide together what to try, what to drop, what to investigate further.

It also doesn’t specialize by role. At the frontier, the questions are too unstructured for “I’ll do design and you do engineering.” Whoever’s nearest the question goes. Whoever has the relevant signal pieces it together.

I’ve been living this myself in the last few months. Outside my coaching practice, I’ve been working inside a startup, where I’ve ended up picking up basic sales, marketing, product, design — none of which were my background — through agents that close the gap. I’m not great at any of it yet. But “great” isn’t the bar at the frontier. The bar is: can the team learn fast enough to know whether this is worth doing? The answer comes from people willing to own a question end to end, not from people defending their lane.

So in an AI-native org, frontier work pulls generalists. Iteration leans on the harness. Both happen at once — and for ICs, this means frontier work is more accessible, not less. The path doesn’t run through a management title anymore. It runs through being the person who’s already pushing toward the question.

What this asks of leaders

If you’re leading inside this kind of org, your job is not to set a speed goal and watch the dashboards. The dashboards will go up. They won’t tell you where the system is breaking.

Two things change.

Get your hands dirty inside the iterative pattern. Don’t manage the harness from above. Pick one experiment your team thinks is worth running and drive it end-to-end yourself. Frame the question, work the agents, sit with the output, push it through whatever review process exists. Within a week you’ll know exactly where the system grinds: which review layer is performative, where context is lost between steps, which handoff doesn’t need to exist. You can’t see this from above; you find it by doing one full lap.

And spend more time at the frontier. The people harness keeps the iterative pattern functioning, but it isn’t the deepest part of the leader’s job. As iteration gets more efficient, the bigger question becomes what new bets the company should be making — the new product line, the pivot, the experiment nobody’s run. That work doesn’t delegate cleanly, and it doesn’t get done if leaders are consumed inside the harness, managing the thing that already exists.

So when someone asks whether to switch into management, or back to IC, my answer is the same now: it’s not about the chair. The room moved, and the work changed shape underneath it. Prepare for the work the new shape is asking for — and which seat you’re in stops being the question.

About Amy Wu

I’m an executive and life coach who works with leaders navigating inflection points — including the one AI is creating right now. If you’re inside an org going through this shift and want a thought partner, I’d love to hear from you.

→ ways to contact me

Some of it is pressure from the top — executives want an AI efficiency story yesterday. Some of it is the quieter kind: the anxiety of watching everyone else move and not knowing if you’re behind. The reality is that nobody knows what success actually looks like yet. So they reach for a playbook.

Wrong instinct. Nothing here is stable enough to write a playbook for. Models change monthly. What worked in Q1 doesn’t hold in Q2. Every “best practices” doc is a historical artifact by the time it ships.

You don’t need a playbook. You need a harness.

What an agent harness actually is

If you’ve ever shipped an AI agent — a system that calls tools and takes actions, not just answers questions — you’ve probably heard the discipline growing up around it: harness engineering, the layer beyond prompt and context engineering. The raw model is powerful but unreliable. What makes it useful in production isn’t the model itself. It’s the layer wrapping it: prompts that set context, tools that extend capability, validators that catch bad output, feedback loops that sharpen it over time, guardrails for when something goes wrong.

That wrapping is the harness. It’s a living system — you tighten it when something breaks, loosen it when you’ve seen it hold, re-tune it when the underlying model changes. The model gets better on its own. The harness is what you build.

The craft you already have

Here’s what clicked for me:

A great manager has always been a harness. You just didn’t call it that.

Think about what a good manager actually does. They set context so the team understands the goal. They connect people to the tools and information they need. They catch problems before they ship. They give feedback that helps the team get sharper. They expand autonomy as trust builds — first supervised, then trusted, then autonomous. When something breaks, they tighten the harness and rebuild trust.

Prompts. Tools. Validation. Feedback loops. Evolving boundaries.

The craft of harnessing isn’t new. The thing you’re wrapping is.

The Four Modes of AI-Native Execution

This is how we harness our team and AI agents at my startup — and the pattern I keep recognizing in the teams I heard feeling it is working. For any piece of work, there are four ways the harness can be set — four modes of how tight the boundary is between human and AI. Most teams are already operating in some version of these. They just haven't looked at it as a system yet.

Human leads, AI assists. The work is novel. The judgment is ongoing. A person has to drive — deciding what questions matter, what good looks like, what’s signal versus noise. AI is a powerful partner during this exploration: it pulls data fast, surfaces patterns, generates options. But a human is in front. Example: pivoting — choosing what to build next; running a feasibility test with a prototype; org and role design.

AI drafts, human judges. The pattern is clearer but quality still needs human eyes. AI does the heavy lifting of a first pass — a draft, an analysis, an implementation. A human evaluates: is this actually good? Does it capture what matters? What’s missing? Example: a performance review draft the manager edits heavily; a comms plan for a product launch; a market analysis.

AI executes, human spot-checks. The pattern is proven. The quality bar is clear. AI runs the work; a human keeps an eye out for drift. Example: code for well-understood, patterned work; operational review preparation.

AI proposes, human approves. This bucket is narrower than it sounds. It’s not for open-ended judgment — that’s mode one. It’s for work where AI has already done the job, but the consequences of shipping it wrong mean a human needs to say “go.” Example: sending a mass customer email; large refunds or vendor payouts above a threshold; regulatory-adjacent submissions where sign-off is required.

Notice what these four aren’t: a classification system. A workflow isn’t “in” one of these modes forever. The mode is the current harness setting for that work right now.

Migration is the real work

Here’s the part most playbooks miss completely.

Take AI-assisted code. Eighteen months ago, most engineering teams had it squarely in AI drafts, human judges — AI generated the code, a human read every line carefully because you couldn’t trust it. Today, for a lot of teams, routine code has migrated toward AI executes, human spot-checks — the model is reliable enough, the review is lighter, and you’re mostly watching for drift. For novel architectural work, it might still be human leads, AI assists. Same technology. Same company. Different modes for different kinds of code — and the boundaries have moved in just eighteen months.

A harness isn’t a one-time design. It evolves — and not always deliberately. A team in AI drafts, human judges can drift into AI executes, human spot-checks without anyone deciding: review started feeling slow, nobody flagged the shift, and the mode on the whiteboard stopped matching the mode on the ground. Teams often think they’re operating in one mode when they’ve quietly moved to another.

This migration — the deliberate kind and the drifting kind — is where system leadership actually happens.

Loosening the harness — moving work toward more AI autonomy — should happen when:

• You’ve seen the pattern work across enough reps

• Your team has developed judgment about what “good” looks like here

• You have a way to catch it when something drifts

Tightening the harness — moving work back toward more human involvement — should happen when:

• The output quality dropped and nobody flagged it

• A model or context change broke something that was stable

• The stakes of the work changed

The real question isn’t whether your team is checking in on AI. It’s whether you can see the judgment your team is quietly adding. Pick one workflow. Ask two or three of the people running it what they override, correct, or rewrite before AI’s output ships. That’s your real harness — not the one on the whiteboard. That gap — between the harness on the whiteboard and the one actually running — is where things start to break. I’ll come back to that in Part 3.

Two harnesses, one craft

Here’s where most leaders stop — at harness #1, the one around AI.

But an AI-native org isn’t just an org that uses AI. It’s one where the shape of work has changed. AI handles a growing share of execution. People operate at higher judgment — strategy, vision, frontier exploration, the work that used to belong to the layer above them. That doesn’t happen on its own. The team needs a harness for it too.

This is harness #2: the one you build to pull people upward into the work you used to do. Same craft — context, tools, feedback, evolving boundaries — aimed at growth instead of execution. Share the reasoning behind decisions so people can make calls at that level. Expose them to the strategic conversations and customer signal that sharpen judgment. Give feedback on how they’re thinking, not just what they decided. Gradually expand the decisions they own.

So the true AI-native leader should be running both migrations at once. AI migrating toward more autonomy. People migrating toward more judgment, freed up by what AI is absorbing below them. Both the same craft. Both evolving.

I’ll say what I’ve been watching out loud. At the CEO and founder level, the recent decisions speak for themselves — aggressive cuts, leaner teams, all-in bets on AI productivity. The pressure is real: boards want an efficiency story, competitors are signaling hard. Harness #1 is getting all the urgency and budget. Harness #2 has quietly slipped off the roadmap. Hire less. Ship more. Prove the AI number is going up. Some of this is strategy. Some of it is pressure wearing strategy’s clothes. Either way, the work of developing the people who actually run the system isn’t happening. I hope there’s a correction coming — once leaders feel the cost.

This is where the real cost hides. Move only harness #1 and the org gets more productive — the team does the same work faster. But the judgment work that would actually move the needle is still sitting a layer above them, untouched. Talent is underused. You get a more efficient team, not a more capable one. A productive org, not an exceptional one. And that’s how you lose. The leaders pulling ahead are running both migrations — turning AI leverage into people leverage, not just into speed.

In Part 3, I’ll dig into why that cost stays hidden — the failure modes I keep seeing when the harness drifts or quietly breaks. You can build the right system and still not know it’s failing, because the metrics most organizations are watching won’t catch it.

Next: Part 3 — how the harness breaks, and what to measure instead.

About Amy Wu

I’m an executive and life coach who works with leaders navigating inflection points — including the one AI is creating right now. If you’re navigating something like what I’m describing and want a thought partner for it, I’d love to hear what you’re seeing.

→ Lets exchange notes