Superintelligence and Your Workforce: Planning Role Change

Superintelligence, meaning AI that outperforms skilled people across most cognitive work, has no agreed arrival date, so its effect on your workforce today is a gradual shift in which tasks people do, who reviews the work and who answers for it. The sound way to plan is around tasks, accountability and a regular review rhythm, not around a forecast. Companies that do this can absorb capability gains in small, controlled steps instead of reorganizing under pressure.

Key takeaways

• Plan for growing capability, not for a date. Nobody can promise when or whether superintelligence arrives, but agents already take over parts of roles, so the planning pays off either way.
• Roles change task by task. Inventory the tasks inside each role before debating headcount or titles.
• Responsibility does not move to the agent. A named person must still own outcomes, approvals and exceptions, however capable the agent becomes.
• Training shifts toward judgment: reviewing agent work, setting boundaries and noticing when output is wrong.
• Review the plan on a fixed cadence, and widen agent authority only when evidence supports it.

What does superintelligence change for a workforce, and what does it leave alone?

Nobody can tell you when, or whether, systems will exceed people at most knowledge work. Treat any confident date, from an optimist or a skeptic, as an opinion. What you can observe is that agents already handle drafting, triage, research and routine coordination across tools, and that newer models tend to handle more of it with less supervision. That trend is enough to plan around. For a wider way to stage your thinking, see three horizons for superintelligence strategy.

What changes first is the cost of producing a first version of something: a report, a reply, a reconciliation, a plan. When that cost falls, the scarce skills move. Deciding what is worth producing, checking whether it is right and carrying the consequences become the center of many jobs.

What does not change is accountability. Frameworks such as the NIST AI Risk Management Framework and the OECD AI Principles both place responsibility with the organizations and people who deploy AI, not with the system. A customer, a regulator or a court will still ask which person or company decided. Your role plan should make that answer obvious for every task an agent touches.

Context also stays valuable. Why a supplier gets special treatment, or why a client dislikes phone calls, usually lives in someone's head. It only helps an agent if a person writes it down, so knowledge capture becomes part of the job.

Which tasks move first, and which responsibilities stay human?

Job titles are too coarse to plan with. A role called account manager contains dozens of tasks, some an agent can do well today and some it should never do alone. Start by listing the tasks inside each role together with the people who do them, because they know where the real work hides.

For each task, ask these questions:

• Can a mistake be undone cheaply? Reversible work can carry more agent autonomy.
• Does the task touch money, contracts, safety, hiring or personal data? If so, a person approves.
• Does it depend on a relationship or on trust built over time?
• Can someone other than the agent check whether the result is correct?
• Could you explain the decision to a customer or regulator without embarrassment?
• Is the needed context written down, or does it live only in someone's head?

Then sort each task into one of four modes:

• Person only: judgment, negotiation, relationships and any accountability that cannot be delegated.
• Person leads, agent prepares: the agent gathers, summarizes and proposes, and the person does the work.
• Agent drafts, person approves: nothing leaves the building without a named approver.
• Agent acts within limits, person samples and reviews: for reversible, well-defined, checkable work.

Expect tasks to move down this list over time. The point is that each move is a decision someone makes with evidence, not a drift. Anthropic's engineering guidance on building effective agents recommends starting with simple designs and adding autonomy only where it demonstrably helps, which is a good rule for roles too. The OWASP authorization guidance expresses the same instinct from the security side: grant the least privilege that gets the job done, and widen it deliberately.

A step-by-step plan for changing a role

Use this sequence for one role first, then repeat. Keeping the scope to a single role makes the evidence easy to read.

• Name an executive sponsor and a role-change owner. The sponsor protects time and decides trade-offs, and the owner runs the work day to day.
• Inventory the tasks in the role with the people who do them, including the tasks nobody lists, such as chasing, checking and remembering.
• Sort each task into one of the four modes above, and write down why.
• Define the agent's approval boundaries and one observable success criterion, for example that routine requests are resolved correctly without rework.
• Run the agent on that role in a limited pilot, and compare results with the agreed criterion rather than with impressions.
• Rewrite the role description: what the person now owns, what they review, what they escalate and what they no longer do.
• Agree the learning path and the career path with the person in the role, including how the role grows rather than shrinks.
• Set a review date. At each review, decide whether to widen, hold or narrow the agent's authority, and record the evidence.

Treat the new role description as a deliverable. If you skip it, people discover their changed jobs by accident, and trust suffers. For the sponsor's part in this, see what an executive sponsor for an AI project must do.

What does a role change look like? An illustrative scenario

This scenario is illustrative, not a report of a real company. An operations coordinator spends much of the week compiling supplier status from emails and spreadsheets, then chasing late confirmations by hand.

In the first stage, an agent compiles the status and drafts the chasing messages. The coordinator reads each draft, edits it and sends it. The coordinator's time shifts from assembling information to judging it: which delays matter, which supplier needs a call instead of a message.

After several review cycles, the team looks at the record. Routine chasers were almost never edited, while anything involving a contract change was edited often. So they let the agent send routine chasers on its own, with the coordinator sampling a few each week, and they keep contract matters as draft-and-approve. The role description is rewritten: the coordinator now owns supplier relationships, exceptions and a monthly review of where the agent erred.

Later, a more capable model arrives. The team does not switch everything on. They rerun their checks, see what improved, and move one more category of task down the list. The role changed three times, and each change was chosen, documented and reversible.

How should you train people and talk to them about change?

Training should move from operating a tool to exercising judgment. People need to learn how to give an agent clear context and instructions, how to review output efficiently without rubber-stamping it, how to recognize a plausible but wrong answer, and when to stop and escalate. Managers need a further skill: judging work they did not watch being produced. A practical syllabus is in what to teach employees before the agent starts.

Watch for the apprenticeship gap. Junior staff have traditionally learned a business by doing the routine tasks that agents now take over. If you remove those tasks without a replacement, you lose the path by which people build judgment. Plan deliberate substitutes: supervised review exercises, rotations through exception handling, and pairing juniors with experienced reviewers.

Be honest in communication. Do not promise that nothing will change, and do not hint at cuts you have not decided. Say what you know, say what you do not, and commit to a process: people in the role are consulted when its tasks are inventoried, they see the new role description before it takes effect, and the plan is revisited on a schedule. Uncertainty stated plainly is easier to work with than reassurance that later proves hollow.

How Be Human handles this in managed operations

Be Human designs each agent around one useful role, with the memory and tools it needs, explicit approval boundaries and an observable success criterion, so the task inventory above maps directly onto what the agent is allowed to do. Under managed operations, monitoring and recurring evaluations show what the agent actually does, and any widening of its authority goes through a requested and approved change under human control. Permissions are reviewed on a schedule, as described in the quarterly permission review, so a new model can raise capability without silently raising access.

Frequently asked questions

Will superintelligence replace my employees? No one can honestly promise either outcome. What you can do is inventory tasks, keep accountability with named people and change roles in reviewed steps, so that any shift in what the technology can do is met by a decision rather than a surprise.

How often should we revisit the role plan? Use a fixed cadence, such as quarterly, and add a review whenever a major model, tool or permission change occurs. Each review should look at the evidence from the agent's recent work and decide whether to widen, hold or narrow its authority.

Who should own role change, HR or IT? Neither alone. A business leader who is accountable for the outcome should own it, with HR covering role descriptions, consultation and career paths, and IT or the operating partner covering access, monitoring and integrations.

Is this relevant for a small company? Yes, in a lighter form. A one-page list of tasks per role, a short list of what always needs a human decision and a date to review it again give you most of the benefit without any new structure.

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