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.

The AI-native org asks both. Do only one of these and the org stalls — either the harness rusts, or there’s no next chapter to harness for. Hands in the work, so the harness keeps working. Eyes on the frontier, so the company keeps having a next chapter.

Next: what this means for you, if you're not the leader designing this org — how to prepare, where to invest, what to look for.

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