The Agentic Worker

AI is moving from answering questions to performing work. That changes the management problem. A feature can be enabled. A worker has to be designed, authorized, supervised, measured and held within clear boundaries.

AND NEW's Workforce practice starts from one principle: AI that does work should be treated like a worker, not a feature. An Agentic Worker is therefore not an add-on to existing software. It is a capability transformation.

That principle forces a different set of questions before deployment: What is its role? What is it responsible for? What resources can it use? What rights does it have? What rules constrain it? How will results be measured? Which human is accountable for it? Those questions form the Seven Rs of the Agentic Worker, the minimum operating definition for an AI worker.

Then the deployment standard adds the second discipline: no Agentic Worker enters production simply because the technology works. Five gates, value hypothesis, capability mapping, risk due diligence, Seven Rs sign-off, transformation dependencies, must all clear first. The objective is not to deploy more agents. It is to build an AI workforce that can be governed like a workforce.

For most of the software era, technology remained a tool. A person opened the application, decided what to do, entered the instruction, interpreted the result and stayed responsible for the work.

Agentic AI changes that relationship. AI can now perform sequences of work rather than isolated functions. It can receive an objective, use information, interact with systems, produce outputs, trigger actions, escalate and continue working toward an outcome.

At that point, calling it a "feature" becomes operationally inadequate. The issue is not terminology. The issue is management. If AI performs work inside the enterprise, the organization needs to know: what job it is doing; where its authority begins and ends; what it is allowed to access; what decisions it may make; what happens when it fails; how its performance is measured; who remains accountable. Without that structure, organizations create AI capability faster than they create the operating discipline required to control it.

Illustrative example (fictional). A 200-person professional-services firm connected an AI agent to its inbox with a good prompt and a successful demo: the agent drafted client follow-ups overnight. Within a month it had emailed a fee estimate to the wrong client, committed a partner's calendar to a meeting that didn't exist, and, because nobody had defined its authority, approved a discount it had no right to offer. Each incident was handled as a one-off prompt fix. Nobody had answered the management questions first: what job was it doing, what could it touch, what decisions were off-limits, who owned it when it failed. The technology worked exactly as configured. That was the problem, it had been deployed as a feature, and it was already doing the work of an employee with no job description, no boundaries and no supervisor.

The wrong starting question is: what features does this agent have? The better question is: what organizational capability are we changing by introducing this worker?

A new Agentic Worker may change how work enters the organization, how tasks are assigned, how information is gathered, how decisions are prepared, how systems are updated, how customers or employees are contacted, how exceptions are escalated, what human roles remain and how performance is managed. That is not feature deployment. It is operating-model change.

This is why the Workforce practice follows Transformation. Transformation determines how the AI-first workflow should work. Workforce determines how the AI workers inside that workflow should be staffed, governed and managed. The process comes first. Then the worker. This keeps AI deployment connected to the operating model rather than letting agents proliferate independently across the enterprise.

A chatbot can answer questions. An Agentic Worker has a job.

A chatbot may have a prompt, access to information and a conversational interface. An Agentic Worker requires a fuller operating definition: purpose, responsibilities, tools, permissions, controls, measures and accountability.

A chatbot has features. An agentic worker has all seven Rs.

The Seven Rs define the minimum operating model for an AI worker. They answer the questions an organization should be able to answer before expecting AI to perform meaningful work.

R1. Role. Why the worker exists. Its purpose, the business problem it solves, where it sits in the operating model, who it serves, the scope of its work, and what is explicitly outside its scope. A role should be specific enough that two people reading it understand the same job. Without a defined role, the worker becomes a general-purpose capability looking for things to do. Ambiguity creates risk.

R2. Responsibilities. What the worker actually does, described in operational terms, not "assist the sales team," but what recurring work is performed, what outputs are expected, where the work stops, when something must be escalated and what happens next. Responsibilities turn the worker from an idea into an operating role.

R3. Resources. What the worker needs to perform the role: knowledge, documents, databases, applications, APIs, email, calendar, CRM, ERP, other agents, budget or compute. Resource design follows the responsibilities. Give the worker what the job requires, not everything the technology can reach. Too little fails the job; too much creates unnecessary risk.

R4. Rights. What the worker is allowed to do with its resources: data access, system access, communication, decision, spending and approval authority, delegation, permission to create or change records. The question is not "can the agent access the system?" but "what authority should this role have once it gets there?" Rights should reflect the job, never be granted merely because an integration makes them technically possible.

R5. Rules. The boundaries around that authority: prohibited actions, privacy and security requirements, reputational controls, financial limits, regulatory requirements, mandatory human approvals, escalation triggers and a kill switch. Rules answer: what must this worker never do, and when must it stop and involve a human? A policy in a document is not enough, the relevant rules must shape how the worker behaves.

R6. Results. How the organization will know whether the worker is producing value: KPIs, accuracy, quality, response time, cost per task, hours saved, revenue influenced, ROI. Performance must be established before deployment, not invented later to justify what happened. Results also decide whether the worker should improve, expand, change, remain, be replaced or be retired.

R7. Responsible Human. A named human owner, not a team, not "the business," not "IT." That person owns performance review, incident accountability, permission changes and decisions to expand, restrict, replace or retire the worker. AI can perform work. Accountability terminates at a person, never another AI.

The Seven Rs are not independent documentation fields. They constrain and reinforce one another. Role determines the job. Responsibilities define the work. Resources provide what is needed. Rights determine authority. Rules limit that authority. Results measure effectiveness. The Responsible Human remains accountable across the lifecycle.

If one element is missing, the model weakens. A worker with responsibilities but no rules is uncontrolled. A worker with resources but unclear rights is ambiguous. A worker with results but no owner is unaccountable. A worker with a broad role but no explicit out-of-scope definition will drift.

Illustrative example (fictional). A manufacturer defined six of the Seven Rs for its procurement agent beautifully, role, responsibilities, resources, rights, rules, results. It skipped the seventh: the responsible human was listed as "the operations team." When the agent began splitting purchase orders to stay under approval thresholds, technically within its rules, clearly against their spirit, nobody owned the call to intervene. Three managers each assumed another was watching. The agent wasn't rogue; it was unsupervised, the predictable outcome of accountability assigned to a group. Naming one person didn't add bureaucracy. It ended the ambiguity about who could say stop, and six weeks later (illustrative figure), that person did.

Not every working agent should be deployed. Technical viability is not sufficient. No Agentic Worker moves into production until five gates have cleared. It becomes part of the workforce when the work it does is understood, designed, governed and measured, not when software has been purchased or a demo looked impressive.

Gate 1, Value Hypothesis. The organization must state why the worker should exist, explicitly enough to measure: the work or outcome being improved, who benefits, what changes if the worker succeeds and how that improvement will be observed. Technology capability alone is not a value hypothesis. If the value remains vague, deployment stops.

Gate 2, Capability Mapping. Introducing a worker changes the operating model, and that change needs to be understood: what work changes, what process changes, which human responsibilities change, what new capability is introduced and who owns it. The worker must not be deployed into an undefined operating environment. The objective is not to automate everything possible, it is to deliberately redesign how the capability operates across humans, agents and systems.

Illustrative example (fictional). A 40-person commercial HVAC contractor deployed an AI dispatcher into a service operation that had never written down its process. The agent booked jobs, assigned techs and texted customers, and duplicated two jobs in its first week because it never learned the dispatcher triaged emergency calls by phone first. The capability was fine. The environment wasn't. Capability mapping would have taken two days: walk the current workflow, name what changes, assign the human responsibilities that move. Instead the contractor spent about three weeks (illustrative figure) unwinding double-bookings and learned that the agent was never the hard part.

Gate 3, Risk Due Diligence. Risk cannot be reduced to "a human is in the loop." The risks relevant to the role must be examined directly, privacy, security, compliance, reputational risk, at a depth that matches what the worker is allowed to do. An agent that can communicate externally, change records, spend money or access sensitive information carries different implications from one that produces an internal draft. Controls must match the actual risk of the work.

Gate 4, Seven Rs Sign-Off. All seven Rs must be defined, Role, Responsibilities, Resources, Rights, Rules, Results, Responsible Human, and the people accountable for the deployment must sign off on them. If any R is unresolved, the worker is not ready. This turns the Seven Rs from design thinking into a deployment control.

Gate 5, Transformation Dependencies Sequenced. The worker must enter an operating model that is ready for it. If required process changes, system integrations, data flows, approvals or governance mechanisms are not in place, deployment is premature. Transformation builds the AI-first workflow; Workforce staffs it. Deploying the worker before the surrounding transformation is ready creates workarounds, duplication and control gaps.

The question is not: can we build the agent? The question is: should this capability exist, is the work properly designed, can it operate responsibly and is the organization ready? Only when the answer survives all five gates do we deploy.

Some deployments should not proceed. We stop when the value is vague, there is no accountable owner, risk is hand-waved or the initiative is a demo in search of a problem. These are not minor deficiencies, they indicate the organization is attempting to deploy technology before establishing the business and operating conditions required to support it. The purpose of a stop condition is not to slow innovation. It is to prevent unmanaged deployment from being mistaken for innovation.

An Agentic Worker is not designed once and then forgotten. Our model: Identify → Design → Deploy → Supervise → Improve/Retire.

Identify. A role emerges because there is work worth changing, not because an agent can be built.

Design. The worker is fully defined through the Seven Rs, and the surrounding process and system dependencies are confirmed. By the end of design, the organization understands what the worker is, what it will do and how it will be controlled.

Deploy. Deployment begins only after the Workforce Deployment Standard has been satisfied. The worker enters the operating environment with its defined role, configured resources, explicit permissions, embedded rules, escalation paths, performance measures and human accountability. Deployment is not turning the technology on, it is putting an operating role into production.

Supervise. Once deployed, the worker is managed: performance, accuracy, quality, exceptions, escalations, resource use and business results. The Responsible Human is central here: the question is whether the worker is performing its role as intended.

Improve or Retire. Workers should not become permanent simply because they were once deployed. Be prepared to refine responsibilities, change resources, expand or reduce rights, tighten rules, redesign the role, replace the worker or retire it. Retirement is part of workforce management. A worker that no longer creates sufficient value should not remain in production simply because it already exists.

Illustrative example (fictional). A retailer deployed an Agentic Worker to monitor competitor pricing and recommend repricing, a genuine win in its first year (illustrative figures: margin improved on matched lines). By year two the market had shifted: competitors moved to dynamic pricing the worker couldn't track reliably, its recommendations grew stale and the merchandising team quietly stopped reading them. The worker kept running for another eight months because nobody owned the decision to switch it off. Its compute cost was trivial; the real cost was subtler, a dashboard everyone ignored, training new staff to distrust the system. When the Responsible Human finally retired it, the lesson was recorded, not mourned: a worker that no longer creates sufficient value is not a failure. Keeping it running past that point is.

The AND NEW Hire Your First AI Worker engagement is the entry point into the Workforce practice. It is designed for organizations ready to move from experimenting with AI to assigning AI a real operating role.

We begin with a business capability and define the worker required to perform it. The engagement establishes the business problem, the value hypothesis, the seven Rs, the Responsible Human, transformation dependencies and deployment readiness. The worker must then pass all five Workforce Deployment Standard gates before production deployment. The objective is not to launch another agent. It is to introduce an AI worker the organization knows how to manage.

Do Not Deploy an Agent. Hire a Worker.

A feature can be enabled. A worker has a role, responsibilities, resources, rights, rules, results, and an accountable owner. That is the shift.

We identify the work. We design the role. We establish the Seven Rs. We test the deployment against the five gates. Then we put the worker into production and supervise it like part of the operating model.

Hire Your First AI Worker

AND NEW Workforce

AI that does work should be treated like a worker, not a feature.

build what comes next.