Redesign Jobs With AI Agents: A Practical Guide to Clear Roles

To redesign jobs with AI agents, start from the work, not the job titles. List the tasks in one process, then decide which the agent prepares or executes, which a person reviews, and which a person alone approves or owns. Write that split down as a short role description for the agent and an updated one for each person it touches, so every task has one doer, one reviewer and one accountable owner.

Key takeaways

• Redesign around tasks and decisions, not around whole jobs. Jobs change as a result, but they are not the unit you move.
• Every task needs four things named: who does it, who reviews it, who approves it, and who owns the outcome.
• Move tasks to the agent only when the input is clear, the good output is recognizable, and a mistake can be seen and reversed.
• The agent's permissions should mirror the approval boundaries you wrote down, not the other way around.
• Roles stay clear only if you review the split on a schedule, because the work, the agent and the people all keep changing.

Why do roles get blurry when an agent arrives?

Most teams add an agent to an existing process and change nothing else. The agent starts producing drafts, summaries or completed steps, and people keep doing their old work plus a new, unwritten duty: checking what the agent did. Nobody decided that this checking was part of anyone's job, so it lands on whoever notices.

The blur usually shows up in a few recognizable ways:

• Two people review the same output, and a third assumes someone else did.
• A person redoes the agent's work from scratch because they do not know what it was allowed to decide.
• When something goes wrong, the conversation is about whose fault it was instead of whose decision it was.
• Experienced staff spend their time on corrections while the judgment work they were hired for waits.

None of this is a technology problem. It is a job design problem that the technology exposes. An agent is a participant in the process, and a participant without a defined role creates the same confusion a new hire without one would. If you want a model for writing that role, the article on writing a job description for your first AI agent role covers the agent side in detail. This guide covers the human side and the boundary between them.

Which tasks should move to the agent, and which stay with people?

Sort at the level of the task, one process at a time. Pick a process that matters but is not your most sensitive, and break it into the steps a person actually performs today, including the invisible ones such as checking a second system or asking a colleague.

Then run each task through this decision guide:

• Is the input clear and the good output easy to recognize? If yes, the task is a candidate for the agent to do.
• Does the task depend on judgment about a relationship, an exception or company values? If yes, a person keeps it. The agent may prepare background, but it does not decide.
• Is a mistake easy to see and easy to undo? If yes, the agent can act, and a person samples the results afterward.
• Is a mistake costly, visible to a customer or hard to reverse? If yes, the agent drafts and a person approves before anything leaves the building.
• Does the task require authority, such as signing, committing budget or changing terms? If yes, it stays with a named person.
• Does the agent have the data and tools to do the task today? If not, do not move it yet. Fix access first, or leave it with people.

The last question is the one teams skip. An agent that lacks the right context will produce confident, plausible and wrong output, and the review burden lands on people. Memory, documents and tool access are part of the role, not extras.

Expect a mixed result. Most tasks will not move entirely. The common pattern is that the agent takes the first and last mile (gathering, drafting, formatting, logging, follow-up) while a person keeps the decision in the middle.

What are the four kinds of responsibility to assign?

Blurry roles usually come from treating responsibility as one thing. Split it into four, and assign each separately for every task.

• Doing: who or what produces the output. This can be the agent, a person, or both in sequence.
• Reviewing: who checks the output for quality before it is used. Review can be full, sampled or exception-based.
• Approving: who has the authority to let something go out, be paid, be sent or be changed. Approval is a decision, not a glance.
• Owning: who answers for the result of the whole process, including the cases where the agent was wrong. Ownership always belongs to a person.

Two rules keep this honest. First, the agent never owns anything, because accountability cannot be delegated to something that cannot be held to account. Second, the person who approves should not be the only person able to see what the agent did. Logs and visible history are what let approval be a real decision rather than a formality.

These boundaries should then be mirrored in what the agent is technically allowed to do. If a task requires a person's approval, the agent should not hold the permission to complete it alone. Authorization guidance such as the [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) recommends least privilege and deny-by-default access for exactly this reason. The practical routine for checking it is described in how to run a permission review for your AI agents.

A step-by-step plan to redesign the role

Use this sequence for one process at a time. It fits in a few working sessions with the people who actually do the work.

• Step 1. Name the process and its outcome. Write one sentence on what a good result looks like and who receives it.
• Step 2. List the tasks as they happen today. Ask the people doing the work, not their managers. Include checks, handoffs and workarounds.
• Step 3. Sort each task with the decision guide above. Mark it as agent does, person does, or agent prepares and person decides.
• Step 4. Assign doing, reviewing, approving and owning for every task. One name or one role per cell. If you cannot fill a cell, the design is not finished.
• Step 5. Define the review mode for each agent task: every item, a sample, or only exceptions the agent flags. Decide what the agent must do when it is unsure, which should be to stop and hand off, not to guess.
• Step 6. Write the new role descriptions. One for the agent, covering purpose, tools, memory, limits and escalation. One page for each person whose work changed, covering what they stopped doing, what they now review and what they now decide.
• Step 7. Set an observable success criterion and a review date. Choose something the team can check, such as turnaround on a defined kind of request or the rate at which reviewers send work back. Then run the new split as a pilot before making it permanent.

Step 6 is where most of the clarity comes from. People accept change more easily when the page says what they no longer have to do. The companion piece on getting your team to actually use an AI agent goes deeper on the human side of that conversation.

What does this look like in practice? An illustrative scenario

This is an illustrative scenario, not a client case. Imagine a distribution company whose order desk has three coordinators. Each handles incoming order emails, checks stock, confirms delivery dates, chases missing details and updates the order system. Today all three do everything, and the most experienced one is the informal fixer for odd cases.

After sorting the tasks, the team decides this:

• The agent reads incoming order emails, extracts the order details, flags missing fields and drafts a reply asking for them.
• The agent checks stock and proposes a delivery date, using the same rules the coordinators use.
• A coordinator reviews every proposed confirmation for new customers and samples confirmations for established ones.
• Any change to price, payment terms or a delivery promise outside the standard window is a decision for a named senior coordinator. The agent can only prepare the case.
• The operations manager owns the process outcome and reads a short weekly summary of what the agent handled, what it escalated and what reviewers corrected.

The coordinators' jobs become clearer, not smaller in a vague way. One now owns exceptions and customer relationships. One owns review quality and the written rules the agent follows. The third rotates between both. The old fixer role is now formal: it is the person who maintains the rules for odd cases, which is where that knowledge always lived anyway.

Notice what did not happen. Nobody was told to supervise the agent in general. Each person has specific things to review, specific things to decide, and a clear place to send what does not fit.

How do you keep the new roles clear over time?

A role split is a working agreement, and it drifts. The agent gets new tools, the product mix changes, a reviewer leaves, a manager starts approving things by habit. Plan for that from the start.

• Watch the review itself. If reviewers approve nearly everything without comment, either the agent is reliable enough to move to sampling, or the review has become a rubber stamp. Look at actual corrections before deciding which.
• Treat boundary changes as formal changes. If the agent should take on a new task or lose one, write the request, name the approver and record the result. The approach in how to request and approve changes to a managed AI agent works well here.
• Collect friction from the people in the roles. They notice the unclear handoffs first, and they will tell you if the questions are asked in the right way.
• Keep humans practiced. If people only ever see exceptions, they can lose touch with the normal case. Rotating who handles standard work now and then helps keep judgment sharp.
• Re-read the split on a fixed date. A short quarterly review of who does, reviews, approves and owns each task is enough for most teams.

Frameworks such as the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) put the same idea in broader terms: clear roles, human oversight and regular review are part of managing an AI system, not an add-on. For a small or mid-sized company, a one-page role map and a recurring review date is a reasonable way to start.

It also helps to prefer simple designs. Guidance on [building effective agents](https://www.anthropic.com/engineering/building-effective-agents) from Anthropic recommends starting with the simplest workable setup and adding complexity only when it earns its place. The same holds for role design: a few clear tasks with clear owners beat a sprawling arrangement nobody can explain.

How does Be Human handle role design?

Be Human treats role design as part of the first engagement, not a separate change management project. The engagement defines one useful role for the agent, the memory and tools it needs, the approval boundaries around it and an observable success criterion. The task split, review modes and owner assignments are written down alongside the agent's configuration, so the human roles and the agent's permissions describe the same boundaries. In managed operations, Be Human monitors the agent, runs recurring evaluations, reviews permissions and makes controlled improvements, while your people keep the approvals and the ownership. The service is remote and delivered in English and Portuguese.

Frequently asked questions

Who should own the agent inside the company? A named person with authority over the process the agent works in, usually the operations or department lead, not the person who set it up. That owner approves boundary changes, reads the regular summary and decides when the agent takes on more or less. Day-to-day reviewers can be different people, but ownership should sit with one name.

Will redesigning roles around an agent change headcount? Role design and staffing are separate decisions, and this process does not require one to follow the other. What it does is make visible which tasks people now do, which they have stopped doing and where their judgment matters most. How a company uses that information is a management decision, and it is better made with a clear picture than a vague one.

How many tasks should we move to the agent at the start? Fewer than feels ambitious. Choose one process, move the tasks that pass the decision guide cleanly, and keep the rest with people until the review data shows the agent is reliable. Expanding later is easy when the first split is documented; untangling a large, unclear one is not. The article on proof of concept, pilot or production explains what each stage should prove before you widen the scope.

Do people need new training for their changed roles? Yes, but it is narrower than a general AI course. People need to know what the agent can and cannot do, what they are now responsible for reviewing, how to correct it and how to escalate. Practical, role-specific sessions run before the agent goes live work better than broad awareness sessions, and they should be repeated when the split changes.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.