An existing company becomes agentic by redesigning work before redrawing reporting lines. Pick one product or service process, give a person responsibility for its outcome, train people to build and supervise bounded agent work, and keep experts responsible for hard decisions. Once the new process is working, choose where builders report and which jobs have changed. Do not decide the headcount from a diagram of what agents might do.
This is a transition plan, not a forecast that every company will have the same roles. McKinsey’s 2026 State of Organizations report finds that 53% of leaders expect AI mainly to support people in the next one to two years; 25% expect autonomous agent teammates. Companies need a way to move from the former toward the latter without asking staff to trust an untested org chart.
Before you start
Choose one process with a willing business owner, a manager and employees who run it today, and an expert who can review risky decisions. Collect its baseline and confirm you can inspect failures without exposing sensitive data. Do not start a staffing plan from a demo.
1. Map the work before the jobs
Take one end-to-end workflow, such as customer onboarding, a product release or contract intake. Draw every handoff from request to result. Mark who can access what, where an error reaches a customer, who approves a commitment, and how an exception is fixed. Establish a baseline: elapsed time, rework, service quality, cost and the time people spend on coordination. Leave the law and privacy checks in place. Expect: a map with a human owner, an escalation path and baseline measures for every risky step.
Then classify each step: keep a human decision, delegate a bounded step to an agent, automate it with ordinary code, or remove the step entirely. The goal is not to add an agent at every box. McKinsey’s analysis of agentic organizations argues for outcome-aligned teams and redesigned processes; Microsoft’s Work Trend Index calls the dynamic flow of people and agents a “Work Chart.” Neither replaces the reporting chart used for hiring, pay and accountability.
2. Give current people a route into the new roles
The new generalist is a product builder when the outcome is a product, or a service builder when it is a business process. A product builder can move from customer problem to prototype, reviewed production change and measured adoption. A service builder maps the workflow, builds automation, handles fallback and measures the service after launch. Neither gets a free pass on engineering, legal or security review. A recent post by Elad Zoarets (in Hebrew) asks why companies add an AI specialist while old PM and engineering handoffs remain. The builder role is one answer.
This is more than a made-up title: ShipBob’s AI Product Builder job covers discovery, specs, prototypes and production-ready pull requests. Emplifi’s Agentic Builder job places builders inside business functions, with a small central group for shared standards. These postings show possible roles, not evidence that every company should copy them.
A specialist expert has two jobs in the new structure: take the cases that need depth, and make the repeatable parts of that depth available to others. A legal lead can review unusual agreements and publish a contract-drafting skill with approved clauses and an escalation rule. An engineering leader or CIO can review architecture and publish a production-change skill with tests, logging and rollback rules. A skill is a reusable set of instructions, examples or scripts for an agent and its human operator, as Anthropic and Microsoft describe. Version and test it; it cannot approve a contract or confer professional authority.
| Current seat | Train toward | Keep the human check |
|---|---|---|
| Product manager, engineer, designer | Product builder or expert reviewer, based on ability and interest | Customer bet, architecture, accessibility and release |
| Operations analyst or service owner | Service builder or exception owner | Service quality, sensitive data, customer escalation |
| Legal, security, engineering or design specialist | Deep-case expert and owner of tested, reusable skills | High-risk review and standards |
| Functional manager | Outcome sponsor, builder coach, capacity and exception manager | Hiring, pay, trade-offs and incident accountability |
Expect: each affected person can see a possible route into the new work and the reviews that remain human. The table offers paths, not a forced conversion. A strong designer need not become a full-stack builder to remain valuable. Design must still test the actual user experience; marketing must still validate claims and demand; engineering must still maintain production standards. McKinsey’s product-development analysis expects responsibilities to blur but warns that junior apprenticeship needs redesign.
3. Train the managers and employees on real work
Start with a paid pilot, not a slide deck or a requirement to learn at night. A manager and a current employee work with a builder on an actual process. They learn to frame a result, limit agent access, test output against a known case, spot a failure, escalate it, and stop the workflow. Give them time to practise and a named specialist to consult. Assess the work they can do, not how many prompts they have written.
Managers need a second track. Instead of counting tickets or output volume, they set the outcome, decide which tasks may be delegated, coach people on review quality, monitor exceptions, and explain changes to the team before a new role is assigned. McKinsey’s change-management research found 48% of surveyed US employees said they would use gen AI tools more often with formal training. Its technology-workforce analysis recommends a skills-based inventory and development rather than filling a static list of titles.
The training should end with a demonstrated result: the employee can run and inspect the workflow, explain the failure path, and improve one measure without breaking another. Teach juniors on generated work too: reviewing a test against a real bug, interviewing a customer and checking an agent’s claim are ways to build judgment. If those exercises disappear along with routine tasks, the company runs out of future experts. Expect: employees can run, inspect and recover the pilot workflow, while managers can explain its results and exceptions.
4. Make a hiring and redundancy decision from evidence
First list tasks removed, new tasks created, and the capabilities each team now needs. Offer current employees a fair chance to train and apply for the new work; publish the criteria and the time allowed. Reassign people to unmet customer work where possible. Hire externally when the gap requires expertise the company cannot build in time, such as security engineering, accessible design or production agent reliability. A new label is not proof of a capability gap.
If measured, sustained automation leaves less work even after redeployment, a company may have to eliminate roles. That decision belongs to its human leaders and HR/legal process, under local employment law and agreements, not to an agent or a promised percentage from a report. Check whether quality, exceptions, growth and training capacity still require people before cutting. The World Economic Forum’s 2025 Future of Jobs survey projects substantial reskilling and redeployment worldwide; it is not a headcount target for your company. Be specific with affected employees about timing, criteria, support and appeal, rather than calling every cut “reskilling.” Expect: a documented skills inventory, training and redeployment offers, and a human-led staffing decision tied to measured demand.
5. Choose the org chart that fits the work
Option A: embed builders in departments. This fits a product or service area with steady demand and a manager who can own the result. Product builders sit with product; service builders sit with service or operations. Experts remain accessible across units.
Option A, embedded builders. Department leaders manage their builders and own outcomes. Expert leads across legal, engineering, design and security handle hard cases and maintain reviewed skills. A shared platform supplies identity, access, logs and evaluation to every department; the dashed support tier is not a new reporting line.
The upside is speed and context. The failure mode is departments building incompatible stacks or managers treating expert review as optional. Standardize identity, evaluation and audit logs before multiplying builders.
Option B: a shared builder group in operations. This fits uneven demand across several departments. Builders sit under an operations or transformation leader and work with named business sponsors. State Street’s agentic builder posting shows one version of a central group working across business functions under risk controls.
Option B, shared builders. Business owners in product, marketing, service and finance own outcomes and exceptions; builders report through an operations or transformation leader and partner with a named business owner for each workflow. Independent expert leads review hard cases and publish skills. The common platform supplies access, logs and evaluation. In the diagram, solid lines show reporting and dashed lines show partnership or support, not dual management.
This is easier to staff early, but it can become the old central ticket queue. Set a handover date and a named department owner who will maintain each new service. Move builders closer to departments when demand becomes steady.
Option C: outcome teams after the pilot works. A company with several proven end-to-end processes can group builders, relevant product and service people, and specialist access around customer journeys. The outcome leader owns staffing and metrics; the central platform owns shared controls; experts remain independent reviewers of high-risk work.
Option C, outcome teams. Each customer journey has an outcome leader, builders and the product or service people needed to deliver its result. Expert guilds across legal, engineering, design and security retain independent standards and hard-case review; the shared platform owns identity, access, logs and evaluation. The lower support tier serves both journeys; dashed lines mean shared support, not reporting.
Do not start at option C because it looks modern. It needs stable outcomes, management capable of coaching broad roles, and a way to resolve conflicts between journey leaders and experts. The reporting chart and the work chart can differ during the transition; neither should hide who is accountable. Expect: every builder knows their manager, every workflow has a business outcome owner, and every high-risk case has a reviewer.
When the pilot breaks
- The agent produces plausible but wrong work: pause the affected step, send cases to the named human reviewer, add the failure to the evaluation set and rerun the test before expanding access.
- Builders become a central ticket queue: assign each workflow a business owner and a builder, agree on a handover date, and move steady demand closer to the department.
- The time savings disappear into rework: compare lead time, defects and exception hours with the original baseline. Narrow the delegated task or restore the human step if quality drops.
What the company looks like after the transition
The mature version has fewer handoffs, not necessarily fewer people. Builders own the full result, agents carry bounded repetitive steps, specialists handle hard work and maintain trusted skills, and managers coach people and run the exception loop. The CEO can see service quality, cost and customer outcomes next to audit and incident measures. Some areas will still be mostly human. Others may run routine cases automatically with review at the risky boundary.
Run a 30-day pilot, then compare the baseline on lead time, defects, customer outcomes, cost and time spent fixing agent output. Ask the current staff whether they can maintain it without the pilot team. Expand only when the result holds for real exceptions. BCG’s 2026 marketing survey found 42% of sampled CMOs still use generative AI for discrete assistance and about 8% have campaigns with multiple autonomous agents. That is one function’s sample, but a useful reminder: a transition is measured in working processes, not in the number of agent boxes on a chart.
Further reading
- AI-First Operations topic hub: the current collection of operations articles. A dedicated topic pillar has not been built yet.
- AI Is the New Electricity: First Substitute, Then Reimagine: why a new tool pays off only when the surrounding work changes.
- When to Use Multi-Agent Orchestration: when multiple agents are worth their coordination cost.
- Agent Evaluation Frameworks: how to test work before delegating more to agents.
- AI Workslop Is an Org Design Problem: how unclear handoffs turn generated work into more work for someone else.
- Human-in-the-Loop AI Approval That Actually Binds: make human review a real boundary rather than a checkbox.