Your AI Strategy Won’t Work If Everyone’s Job Stays the Same

Look at what people are expected to do

You’ve made rebuilding the business everyone’s second job.

Deliver this quarter’s numbers. Keep the operation running. Attend the same meetings and produce the same reports. Somewhere in between, learn unfamiliar technology and figure out how to transform the function.

Look at what you’ve actually asked people to do. Their targets, calendars, and incentives still reward the work you want them to replace.

If you want AI to change how the enterprise operates, change what people are expected, equipped, and rewarded to do. As agents start acting on their behalf, give those people the authority and controls to lead the work.

AI role redesign means changing the work a person owns, the decisions they can make, and how their contribution is measured as AI takes on tasks. The job description has to catch up with the work.

The CEO’s instruction needs to change someone’s week

The ambition to rebuild the enterprise while it runs has to reach people’s actual working lives.

Here’s the instruction I’d ask a CEO to give:

We are reimagining how this company operates, starting with our people and our organization.

Every executive owns that change inside their function. This week, work with your teams to identify something each person can start changing. Make room for them to do it. Give them the tools, access, and support they need.

We will discuss progress every week. Show what you tried, what changed, what failed, and what you need from the rest of us.

If your team has no time for this, your first job is to decide what they can stop doing.

That instruction needs to survive the next customer escalation, budget discussion, and quarterly planning cycle. Otherwise people will reasonably conclude that improvement is optional whenever the old work gets busy.

Give people a first win they can feel

Start with the work people already wish they could stop doing.

Sit with someone on Monday and ask them to show you what consumed their time last week. Where did a customer wait? Which information did they chase? What did they copy between systems? What decision could they have made sooner?

Then ask what they could achieve if that work stopped consuming their day.

Choose one specific opportunity. Name the person responsible, the support they need, and what you expect to see by the end of the week. For something larger, the first commitment might be a working test against a small, controlled set of cases.

Give them training that helps with that task and pair them with someone who can build alongside them. Everyone should be able to contribute to rethinking their work. They don’t all need to become software engineers.

A useful first win gives someone a reason to explore the next opportunity. They’ve seen a frustrating task change and can judge the result for themselves.

Check that the old work actually stops. If someone still has to recreate the result manually before they trust it, there’s more work to do.

Take something off the calendar

“Find time to experiment” is a lazy management instruction.

Name what people can pause. Cancel a recurring meeting that produces little value. Suspend a report nobody acts on. Defer a lower-priority activity for two weeks.

For a concentrated push, bring the people who understand the work together with the people who can help change it. Give them access to someone who can make decisions while they’re together. A question about an approval or data source shouldn’t turn a morning’s work into three weeks of messages.

Where the change is substantial, assign dedicated capacity. The executive needs to own the trade-off with the team’s existing commitments. Employees shouldn’t have to absorb it through longer hours.

Review the work every week

Give each part of the weekly routine a clear job:

Nobody should need to spend Thursday making slides to prove they experimented on Tuesday.

Keep connecting the activity to business outcomes. Ten new agents tells you little about whether customers get answers sooner, missed revenue is being recovered, or a neglected problem finally has someone working on it.

Ask what still needs manual correction and whether another team has inherited extra work. A faster step can create a slower handoff.

Change the reward for doing this well

People notice what earns a promotion.

If managers gain status through headcount, reducing the work their team needs to do can threaten their position. If someone automates a painful process and receives nothing beyond additional work, their colleagues get a clear message about the reward for trying.

Put improvement into performance reviews. Ask what unnecessary work the person eliminated, which customer, or business outcome improved and who else became more effective because of what they built or shared.

Reward substantial impact with substantial opportunity, progression, and compensation. Give managers credit for building a more effective function, including when that means a different team structure.

At the same time, stop equating busyness with contribution. Manually producing the same report every week shouldn’t automatically earn more recognition than making the report unnecessary.

The expectation is continual improvement. A great account manager may still manage accounts a year from now. Leadership should be asking why the same avoidable administration, delays, and customer frustrations remain.

Rewrite the job when the work changes

When someone removes a substantial part of their workload, their manager should discuss what responsibility comes next.

Which customer problem can they now own? What has the team postponed because nobody had capacity? What could this person build, improve, or lead?

Update the job description. Remove obsolete responsibilities and agree on the new outcome, decision rights, and support. Revisit their goals as the role evolves.

“You’ll get to do higher-value work” is a bullshit promise unless someone can explain what that work is and help them get there.

Give the next responsibility substance

Consider an account manager who spends less time assembling customer information. Their next responsibility could be investigating recurring service problems before renewal. That requires time with the service team, a clear way to escalate problems, and a measure of whether those problems are resolved.

Putting “be more strategic” in their objectives doesn’t give them any of that.

Be honest about the personal impact

This is personal too. Expertise, identity, and confidence are tied to work people have spent years learning. Have the conversation with the individual and invest in their ability to succeed at the next responsibility.

Some roles may shrink or disappear. Be honest about decisions and uncertainty, and look deliberately for places where people’s knowledge can create value. Don’t promise that every person will automatically get a better job.

Fund curiosity and make the boundaries usable

Give people an experimentation budget, approved tools, and a sandbox they can actually access.

Tell them which data they can use, what they can connect, and where to get help. The instructions need to be understandable without requiring an employee to learn the company’s security architecture first.

Allow room for personal learning projects too, using permitted tools and non-sensitive material. Someone may become comfortable with AI through a problem they care about outside their daily responsibilities.

A learning experiment doesn’t need the investment case of a production deployment. Once a team proposes putting AI into a business workflow, it needs a named owner, a clear outcome, and controls appropriate to the actions it will take.

Make that transition explicit. Tell the team what evidence and approvals it needs, who decides, and where to go when the decision stalls.

Every agent needs a human with authority

As agents start doing the work, the human’s responsibilities change.

“Human in the loop” is incomplete. Clicking approve doesn’t establish that anyone understands or manages what is happening. The human needs to set the objective, delegate authority, assess performance, and intervene when necessary.

That responsibility continues after launch. The question of who owns an AI workflow after the pilot belongs in the person’s role and workload.

Before an agent takes its first production action, its owner should be able to answer:

• What is it responsible for achieving?
• Which systems, records, and actions can it access?
• What requires approval?
• How will I know whether it succeeded or failed?
• How do I stop it, and who helps me recover?

“My agent did it” leaves the business with exactly the same problem to resolve.

Accountability needs practical control behind it: visibility into actions and results, notification of meaningful failures, and an accessible way to pause execution. The owner doesn’t need to debug every technical problem. They need to recognize trouble, contain it, and get the right help.

Build controls around the actual work

Consider a hypothetical agent helping resolve a customer service failure. It gathers account history, coordinates a repair, and prepares a credit.

Work through the failure scenarios before it goes live. What happens if it selects the wrong customer, issues the credit twice, or can’t confirm whether the repair was booked?

Decide what stops, who is notified, what the customer needs to hear, and who can authorize restarting the workflow.

Enforce permissions in the systems executing the actions. Set approval requirements around consequential decisions, keep records of what happened, and check that the intended result occurred. Our guide to permission-aware enterprise agents works through how the requester’s authority, connected account, and business approval fit together.

A model shouldn’t be able to override a boundary because it generated a plausible reason.

Human review also needs to be useful. Show the reviewer the relevant customer, proposed action, supporting information, and consequence. Sending a hundred vague approval requests creates an overwhelmed person who has little basis for a decision.

Build these controls with the people doing the work. They know where a seemingly small mistake can leave a customer waiting or send money to the wrong place.

Make failures safe to surface

Some experiments will fail. Production workflows will encounter situations the team didn’t anticipate.

Make it clear that reporting a problem quickly is expected and supported. If every mistake becomes a career incident, people have a reason to hide problems or avoid meaningful experiments.

When something fails, contain the impact, communicate with the people affected, and establish what happened. Then improve the workflow, test, or control that needs attention.

There’s a meaningful difference between an unexpected failure within agreed boundaries and knowingly ignoring those boundaries. Leadership should respond accordingly.

Give teams a usable route into production

Central technology, security, and risk teams need to provide the environments, permissions, and support that let business teams act confidently.

Make approved approaches reusable. Publish the route from experiment to production and review where teams get stuck. If every workflow requires the same approval argument to be reconstructed from scratch, the central team will keep answering the same questions.

The tools also need to reach the work people are trying to change. Someone reconciling records across several applications needs reliable ways to inspect and act in those systems.

That’s where Monarch fits. Its Product Graph maps application behavior available to the connected account, including operations below the documented API surface that discovery captures and verifies. Those operations give agents a way to carry out work across applications.

The business still supplies the policy, decides which records are authoritative, and gives people responsibility for the result. Access to an operation doesn’t decide who should be allowed to use it or what the person’s job becomes afterward.

Start with one person’s Monday

Before the next week begins, sit down with someone on your team and agree on five things:

1. The work they’ll change and the customer or business problem it should address.
2. What comes off their calendar to make room.
3. The tools, access, and practical help they’ll have.
4. What they’ll show next week, including anything that failed.
5. When you’ll revisit their responsibilities and goals if the change works.

Then follow through when the old workload pushes back. As work disappears, update the role and the reward. As agents take action, give their human owners the controls and support to lead them.

If that first opportunity involves work across enterprise systems, talk to us about a scoped Monarch pilot. Bring the person who understands the work and the manager who can make room to change it.

Frequently asked questions

What is AI role redesign?

AI role redesign updates a person’s responsibilities, decision rights, goals, and support as AI changes their tasks. It includes removing obsolete work and agreeing what the person will own with the capacity that becomes available.

How should managers make time for AI adoption?

Choose a specific improvement, then explicitly pause, remove, or reassign existing work. Provide approved tools and practical help, and review a working result each week. Substantial changes need dedicated capacity and revised commitments.

Who should be accountable when an AI agent takes action?

A named human should own the business outcome, supported by the teams responsible for software, data, and controls. They need visibility into results, clear approval boundaries, and the authority to pause work and get help when it fails.