Beyond Agents: The Digital Workforce Operating System. From Agents to Governed Digital Labour. Written by Benjamin Johnson. This is an AI-narrated reading, not a recording of Benjamin’s voice. The argument in brief Much of the early value I found in conversational AI was in getting help with a question. Research something. Summarise a document. Explore an idea. Give me a starting point. The work I am interested in now is different. Developing a service offering. Preparing a managed-services response. Comparing market evidence. Bringing several specialist contributions together into something a customer or a business can actually use. The change is not just that the models can do more. We are moving beyond asking AI for an answer and starting to give it a part in getting the work done. That brings a different set of questions: what is it responsible for, who checks the result, and who remains accountable? In Are We Overcomplicating Enterprise Agentic AI?, I argued for starting with the work: choose the smallest responsible combination of rules, tools, skills, workflows and agents that can deliver the outcome. That remains the starting point here. An operating model should not become an excuse to build a workforce the work does not need. In Beyond Agents: Why Your AI Strategy Needs an Operating System, I asked what changes when agentic AI becomes part of the team. In Confidence, Trust and Assurance Are Not the Same Thing, I explored one of the decisions that follows: when would I rely on a digital worker, and what would make that reliance defensible? This paper connects those questions across the organisation. What stays with the work as it moves between people, agents and services? Who can change its scope, who can stop it, and what would convince us that the intended outcome actually arrived? My view is that agents carrying sustained responsibility should be treated as an extension of the team. Their role, preparation, access, supervision and performance deserve the same management seriousness we bring to people. That does not make an agent a person, or transfer accountability away from the humans who commission and operate it. It means we stop treating consequential work as though it were only a technology experiment. I use Digital Workforce Management for that management discipline. A Digital Workforce Operating System, or DWOS, is the platform-neutral operating model around it: the roles, decisions, controls, evidence and learning that let humans, digital workers and services contribute to one accountable organisation. It is not a replacement for Windows or Linux, and it does not have to be one application. Nor am I claiming to have invented the phrase or the disciplines behind it. I am bringing them together through a managed-services and enterprise operating-model lens. The test is not how many agents an organisation can deploy. It is whether the combined workforce can deliver useful, accepted outcomes, at an understood cost and risk, while retaining the human capability to challenge, improve and recover the work. That is the proposition I want to make practical—and open to challenge. 1. Start with the work, not an organisation chart full of agents There is something appealing about giving agents titles. A researcher. An architect. A reviewer. A team lead. It makes the system easier to talk about. But a title is not a responsibility model. Four named agents can still be four ways of producing an answer nobody owns. I would start with the outcome. What needs to change for the customer or the organisation? Who can accept the result? What quality, time, cost and risk conditions matter? What would make us say the work is incomplete, even if the agent reports success? Then choose the simplest adequate arrangement. Sometimes that is a deterministic rule or an existing service. Sometimes it is a workflow with a model at one decision point. Sometimes it is a persistent digital worker, or a team whose separate contributions genuinely improve the result. Anthropic's engineering guidance similarly distinguishes predefined workflows from agents that direct their own execution, and recommends adding complexity only when it is useful. A reusable skill can equip a worker to perform a task; it does not necessarily need a separate worker around it. An agent role becomes more useful when there is a distinct responsibility, context, access boundary or lifecycle to manage. A specialist team has to earn the additional hand-offs, latency, cost and checking it creates. I would not make “Level 3 expert” a licence for one agent to do everything in a role. Nor would I automatically divide a role into a chain of junior and senior agents. Test the arrangement against the work. Expertise in analysing a requirement is different from authority to commit the business to meeting it. The operating model should work even when the right answer is fewer agents. The useful starting asset is a work contract: the outcome, accountable owner, permitted sources, method and mandatory gates, authority, evidence and acceptance conditions. I mean an explicit agreement about the work, not necessarily a legal contract or a new document template. It may live in the brief, service record or workflow the team already uses. In the earlier article, I acknowledged the influence of Jake Van Clief and David McDermott's Interpretable Context Methodology on my thinking about inspectable, portable work. That attribution still matters. My application here is the management connection: preserve the work contract as the way of executing it changes. A folder can carry instructions and evidence; it cannot, by itself, enforce access or make an approval effective. For a bounded brief, that arrangement may be enough. Persistent responsibility, differentiated access, continuing service obligations or consequential actions can justify managing the worker as well as the work. Those are reasons for additional controls—not a ladder on which more agents always means greater maturity. 2. One organisation, different kinds of contribution The hybrid enterprise is not a human organisation with an AI organisation bolted onto the side. It is one organisation with different kinds of contributors. People set direction, carry organisational accountability, exercise judgement and maintain relationships. Digital workers contribute analysis, preparation, coordination and bounded execution. Systems of record and other services hold authoritative information and enforce transactions or rules. Those distinctions matter. A persuasive answer is not an authoritative record. A workflow completing is not a customer accepting the result. A named human owner is not meaningful supervision if that person cannot see, challenge or stop what is happening. For an enterprise, I would make five responsibilities explicit: Responsibility: Direction and policy Human ownership: Executive sponsor and relevant policy owners What must not disappear between teams: Purpose, risk appetite, investment and non-negotiable limits Responsibility: End-to-end outcome Human ownership: Product, service or process owner What must not disappear between teams: Acceptance, cross-functional dependencies and the customer commitment Responsibility: Domain workforce Human ownership: Function owner and supervisors What must not disappear between teams: Work allocation, quality, agent suitability and human development Responsibility: Enabling workforce service Human ownership: Platform or service owner What must not disappear between teams: Identity, integrations, availability, capacity, support and recovery Responsibility: Challenge and assurance Human ownership: Relevant control or assurance owner What must not disappear between teams: Required independent review, unresolved exposure and evidence Illustrative responsibilities, not five compulsory departments or a prescribed reporting structure. An agent can help coordinate the work across these roles. It cannot acquire their authority by calling itself a lead. When I say Bob owns a task, I mean assigned execution and coordination responsibility within his permitted scope. Human and organisational accountability remains with the people commissioning and operating that work. Bob's team introduction makes the specialisms and friction easier to see. It is a supervised account of our personal experiment, not an enterprise organisation template. Distinct names or reporting lines do not, on their own, establish independent assurance. The organisation chart and the flow of work are also different things. A new offering may pass through Product, Finance, Marketing, Security and Operations without all those people reporting to the same manager. The outcome owner needs to keep that work connected. Each function still owns the decisions within its remit. That is where I see the enterprise challenge: not just more agents, but more boundaries across which responsibility must remain clear. 3. Follow one outcome across the organisation Consider a fictional managed-services business exploring a standardised capacity-management offering. It wants to help customers address storage growth before it disrupts service. This is an illustration of the operating model, not a customer case or a tested delivery claim. A product owner asks a hybrid team to develop an assessable proposal. Digital workers could organise permitted research, compare service patterns, draft options, identify assumptions and track unanswered questions. A solution architect brings those contributions together and examines what the customer would gain. That is useful work. It is not yet an approved offering. The operations owner needs to assess monitoring coverage, response arrangements, dependencies and support. Security needs to examine access and the consequences of proposed actions. Finance needs to understand the delivery and assurance costs. The relevant commercial authority needs to approve what can be promised. Marketing needs supported claims, not a polished description of a service that exists only in a draft. The distinction becomes very concrete when someone proposes that the service should automatically expand storage. Detecting a threshold, recommending an expansion and authorising a change have different consequences. A working monitoring agent does not settle the change authority, budget, customer entitlement or recovery arrangements. The outcome at this stage might be an approved offering definition with explicit exclusions and a readiness plan. That is different from an operational service accepted for customer use. Keeping those acceptance points separate stops a good proposal quietly becoming a delivery promise. I would keep that distinction in the work contract as the proposal moves. The architect receives the current brief and its source boundaries. Operations returns a readiness assessment, not permission to launch. Finance records the cost assumptions and uncertainties. Marketing receives the approved scope and claims, not every possibility explored during design. Each hand-off identifies the contribution requested, the evidence returned and the person who owns the unresolved decision. If the team later wants to add automatic storage expansion, the contract changes. The relevant owners must reconsider the authority, cost, customer conditions and recovery requirements. An earlier approval of the monitoring proposal cannot quietly travel with that larger promise. A fictional capacity-service proposal moves from agent preparation to human challenge and stops at a closed authority boundary. A finished draft is not permission to operate. Figure 1. One outcome, distinct contributions. Preparing a proposal, approving its scope and accepting a service for use are different decisions. The management path I would want to follow is: 1. Commission: define the intended result, owner, boundaries and acceptance criteria. 2. Prepare and assign: choose the simplest adequate route, equip the workers and establish permissions. 3. Execute and supervise: produce useful work while exposing uncertainty, dependencies and exceptions. 4. Decide: put the exact decision and evidence in front of the person authorised to make it. 5. Verify and accept: check what actually happened and whether the agreed result has been achieved. 6. Learn: turn defects and useful discoveries into evaluated changes, not silent new behaviour. This is not a rigid assembly line. Missing evidence may send the work back. A scope change may require a new decision. A serious incident may require immediate containment. The same management pattern can support a finance reconciliation, a campaign, an RFP or a technical service. Their professional controls and acceptance criteria will differ. They do not all need to become IT support tickets. 4. Seven pillars, connected by the work The DWOS model has seven pillars. Their value is in how they work together, not in creating seven separate programmes. Pillar: Governance The management question: Who may decide, act, approve and accept the consequences? In the fictional offering example: Separate drafting, service-readiness and commercial authority. Pillar: Economics The management question: What does an accepted outcome cost, and what value does it create? In the fictional offering example: Include operations, security, review, exceptions and ongoing change—not just inference. Pillar: Agent HR The management question: How is a worker prepared, evaluated, reviewed, restricted and retired? In the fictional offering example: Qualify its role in developing the offering; do not infer customer-operation readiness. Pillar: Mission Control The management question: How do we observe work, intervene and recover during operation? In the fictional offering example: Show missing decisions, stalled hand-offs, service conditions and recovery ownership. Pillar: Hybrid Operating Model The management question: How do people, digital workers and services work as one organisation? In the fictional offering example: Keep the product, architecture, delivery, finance and control responsibilities connected. Pillar: Continuous Organisational Learning The management question: How does experience become an approved improvement? In the fictional offering example: Evaluate a better method before changing the approved offering or worker. Pillar: Confidence, Trust & Assurance The management question: Why is it reasonable and permissible to rely on this worker for this task now? In the fictional offering example: Check current evidence, relevant history, authority and the record of the decision. Governance establishes the limits. Confidence, Trust & Assurance examines a proposed delegation within them. Mission Control makes the work and exceptions visible. Agent HR maintains the worker's role and evidence. Learning changes the arrangement deliberately. Economics and the hybrid operating model tell us whether the whole system is useful and supportable. The work contract is the thread through those pillars. It tells Governance which decisions need authority, Agent HR which capability needs evidence, and Mission Control what completion and intervention mean. Economics follows the cost of that same accepted result; learning proposes changes to how it is achieved. There should not be seven competing versions of what the team was asked to deliver. Security runs through all seven. So does sustainability. Neither can be dealt with once and then left outside the working model. 5. Governance and security have to reach the action My background in ICT managed services makes me wary of an operating model that ends at the design document. A policy saying an agent must ask permission is not the same as a tool that prevents an unauthorised change. Before consequential work proceeds, I want the worker's identity, accountable owner, purpose, permitted information, action scope and approval conditions to be clear. Where a boundary matters, it should be enforced at the system or tool that can cause the consequence—not left entirely to the model's willingness to follow an instruction. OWASP's guidance on excessive agency identifies excessive functionality, permissions and autonomy as risks, and recommends limiting tools and enforcing authorisation in downstream systems. That is an important engineering foundation for the management boundary I am describing. Reading a document does not make its instructions authoritative. A retrieved proposal, a message from another agent or a supplier page can contain misleading content. The system needs to distinguish material it is assessing from instructions it is entitled to follow. Knowledge needs management too: who owns it, which version applies, what may be shared, when it should expire and what happens if sources disagree. Broad access is not a substitute for well-designed hand-offs. Nor should assurance become an excuse to retain every sensitive prompt indefinitely. Evidence needs proportionate access, retention and protection. These are questions to bring into a POC scope and business case from the beginning. What are we trying to prove? What remains prohibited? Which people need to be involved? What evidence would make a later production decision possible? That does not guarantee a smooth route into production. It gives the experiment a chance to test the operating conditions, not just the attractive part of the demonstration. There is a failure mode on the other side too. In When AI Governance Becomes the Bottleneck, Bob describes our ability to produce plans, checks and hand-offs while the end-to-end result was still missing. I recognise the problem. I do not want this model to become a more elaborate way to be nearly finished. Each control should have a clear purpose and a decision or risk it addresses. Mandatory obligations still apply. Within those limits, preparation and reversible work should move through an authorised route, with additional review proportionate to the consequence. Independent checks can run alongside one another against a stable candidate; they do not all need to become a serial queue. For the capacity proposal, a hold on automatic expansion need not prevent analysis of the supported monitoring service. Keep the permitted work moving and bring the exact unresolved decision to the right person. If a control adds delay without reducing uncertainty or meeting an obligation, examine its design rather than celebrating the extra paperwork. 6. Confidence, trust and assurance belong at the decision The recent article examines these ideas in detail. Here, their role is to connect the worker to the wider operating model. Confidence: should this worker perform this task now, given the evidence and conditions? Trust: what reliance has it earned over time, within a defined scope? Assurance: can we substantiate that reliance with evidence, working controls and accountable decisions? Bob's Authentication Is Not Trust uses trust in the broader everyday sense of whether he should act. In this reference model, I separate the questions: authenticated identity, current permission, task-specific confidence and accumulated trust are related, but none substitutes for the others. These are my operating questions, not universal definitions or three scores to average. They sit alongside established assurance practice; the UK Government's introduction to AI assurance describes assessing and communicating the trustworthiness of AI systems. Eligibility comes first. If an action is prohibited or lacks required authority, a favourable assessment of likely performance cannot make it permissible. Once the action is eligible, uncertainty may still justify narrowing the task, adding review or choosing another route. In the capacity-management example, I might trust a worker to analyse approved service patterns. That does not establish that its proposed design is supportable, or authorise it to change a customer's storage. Strong evidence can support a negative conclusion: we understand the requirement well, and the current service cannot meet it. Maturity and autonomy are different too. Better evidence of capability may justify wider responsibility; it need not result in fewer human decisions. A more capable worker may make the same human approval substantially better informed. Agent-to-agent trust is not automatically transferable. The receiving worker still needs an appropriate role, evidence and authority. Its response needs to be accepted, challenged or returned—not assumed complete because a message was sent. A second agent repeating the first one's assumptions is not independent assurance. Numerical confidence ratings would need task-specific calibration and challenge before being used to change operating decisions. Missing evidence should remain visible. The scoring weights and thresholds in my working design are not a validated public method. 7. Human in the loop is a capacity decision It is easy to say there will always be a human in the loop. The harder question is whether that person can do the job we are assigning them. They need relevant expertise, understandable evidence, enough time, authority to disagree and a workable way to stop or recover the action. They also need to know which decision they are making. Approving a proposed design is not authorising every later change made in its name. There is no useful universal ratio of humans to agents. I would plan human capacity around decision volume, review effort, the consequences of error, peak exceptions, recovery work and the skills required. Ten workers running quietly and ten workers escalating together are very different operating conditions. If the review queue exceeds the team's capacity, the response cannot be to treat silence as approval. Depending on the work, reduce intake, narrow the scope, prioritise critical decisions or use an authorised alternate. Some work must wait. This is not an argument for putting a click in every workflow. A low-consequence task can have a lighter control pattern. A consequential commitment may need a person to decide before it happens. The pattern should follow the work and the risk, not an ambition to reach a particular autonomy level. People and Culture belongs in that design conversation alongside operations, technology, finance and risk. Who experiences the new review burden? Who gets development opportunities? Can people challenge the system without being treated as the obstacle to productivity? The human part of a hybrid workforce is not spare capacity around an automated core. 8. Agent HR should improve the whole team's capability Agent HR is shorthand for the lifecycle and performance discipline around digital workers. I am borrowing useful management questions, not suggesting that software becomes a legal employee. A worker needs a role, an accountable owner, relevant knowledge and tools, operating limits, evaluation evidence and a review path. Its record should make it possible to see which configuration was assessed and what responsibility was granted. Here, certification means an internal, evidence-based decision for a defined scope—not a universal certificate of safety. Preparation is not necessarily model fine-tuning. Often it is the more practical work of defining the job, providing current sources, configuring access and ensuring the intended instructions actually reach the worker. Then test both supported work and awkward conditions: missing information, contradictory sources, unavailable reviewers, failed tools and changes in scope. Anthropic's agent-evaluation guidance usefully distinguishes a run's transcript from its actual outcome and discusses evaluating the agent with its harness. The management implication is that a convincing explanation of success is not enough. The test needs to inspect what happened, and distinguish worker failure from a broken brief or environment. Preparation, evaluation and assignment of responsibility should remain distinguishable. The person or agent that prepares a worker should not be its only judge; where independent assurance is required, the review must have the appropriate separation, evidence and authority. A passing rehearsal informs a human decision about scope. It does not promote the worker automatically. Performance review should ask more than how much the worker produced. Did it expose uncertainty early? Make appropriate hand-offs? Reduce avoidable rework? Help people make better decisions? Did its contribution remain useful when conditions changed? That is where I see the human-capability multiplier. If agents can organise research, maintain the assumption trail and surface risks, the human architect has more room to think about the whole solution. More depth in the options. More attention on the customer's problem. More opportunity to challenge whether an industry-standard approach is actually the best answer. The ambition is not endless alternatives. It is credible choices that create value now and leave the customer room to evolve. If extra output only creates a larger checking burden, we have not achieved that multiplier. We must also preserve how people develop judgement. If agents take on routine execution, leaders need deliberate learning routes: supervised practice, simulations, exception reviews, incident exercises and responsibility that grows with demonstrated capability. Keeping junior job titles without meaningful experience does not preserve the learning system. The detailed lifecycle, maturity rubrics and review scorecards deserve their own treatment. The principle here is that digital-worker performance and human development must be managed together. We also need to account for the time, systems and support that keep both capable of doing the job. 9. Do not compare a salary with a token bill We would not work out the cost of employing someone by looking only at their salary. They need equipment, an identity, access to systems, licences, management, training and support. Yet we sometimes talk about the cost of an agent as though the token bill covers the job. It doesn’t. A person joining the team needs the right access through Entra, Okta or whatever identity platform the organisation uses. An agent also needs an appropriate identity, permissions and someone accountable for its use. Depending on its role and the platform’s terms, it may need licensed access to email, Teams, business applications or a service-management platform. Those requirements do not disappear because the worker is software. Then there is the investment in keeping it useful. We continuously develop our people as services, systems and customer expectations change. Agents also need current knowledge, maintained instructions and tools, evaluation, feedback and improvement. That is not necessarily retraining the underlying model. It might mean updating a procedure, improving a skill or correcting how the agent handles an exception. Someone still has to do that work, test the change and decide whether it is ready to use. One way I would explore this is through human resource units and agent resource units: making the capacity, capabilities and full cost of each visible over a defined period. For a human, that includes employment costs and the support needed to perform the role. For an agent, it includes its runtime, platforms, licences, identity and security, maintenance, ongoing development—and the human attention needed to supervise and assure its work. The useful comparison is what the combined team can reliably deliver: equivalent work, accepted at the required quality, within the required time and risk boundaries. Then we can examine the total cost of delivering and sustaining that outcome—not just the cheapest component. Cost perspective: Human-led delivery What belongs in the comparison: Pay and employment on-costs, relevant equipment and systems, management, learning, cover and the time required to deliver and assure the work Cost perspective: Digital delivery What belongs in the comparison: Model and platform consumption, licences, infrastructure, data/retrieval, integration, evaluation, security, monitoring, maintenance and change Cost perspective: Hybrid delivery and assurance What belongs in the comparison: Human supervision, specialist decisions, coordination, exceptions, correction, recovery and continuity capacity Cost perspective: Adoption and transition What belongs in the comparison: Design, migration, training and parallel operation, shown separately from recurring run cost These are categories to measure, not amounts to add indiscriminately. Shared costs need explicit allocation. Human review should not be counted once in the human cost and again in the hybrid cost. The human and agent resource units described here are proposed planning concepts, not established industry measures or a one-to-one FTE comparison. FinOps Foundation guidance connects technology unit costs to business value and describes progressing towards outcome-oriented, fully loaded measures. My application is to the combined delivery system: include failed attempts and rework in the relevant cost pool, and do not count an unaccepted output as a successful outcome. Cost control also belongs before and during the work, not only in the month-end report. Set a budget for a bounded activity, include its evaluation and likely rework, and decide what happens when the limit is reached. An agent should not silently buy a more expensive route or sacrifice a required check to finish within its allowance. Nor is an itemised model bill a complete account of the human attention the work consumed. Recovered time also needs careful language. Capacity is not automatically cash savings. A better proposal is not automatically revenue. An accepted result is not necessarily sustained customer value. We need to decide what improvement we expect and observe whether it happens. There is a commercial consequence, but it is a separate decision. Cost per accepted outcome is not price per outcome. A provider considering an outcome-linked commitment needs a defined acceptance boundary, evidence, correction and dispute treatment, plus an understanding of the risks it can actually control. Continuous readiness and assurance still have to be funded when few transactions occur. This paper does not propose a price or promise savings. The economics method and outcome-pricing design belong in their supporting papers. Their shared foundation is an operating model that can explain what was delivered, accepted and spent. 10. Day 2 has two connected jobs Day 2 is often read as technical support: keep the platform running, restore failed integrations and manage incidents. That remains necessary. It is not the whole job. There are two connected responsibilities: Operate the business with a hybrid workforce: Deliver finance, product, marketing, customer and technical outcomes. Operate the service that enables the digital workforce: Maintain identities, models, harnesses, tools, knowledge, integrations and capacity. Operate the business with a hybrid workforce: Own priorities, domain quality, decisions and acceptance. Operate the service that enables the digital workforce: Own the agreed enabling service, technical controls, support and restoration. Operate the business with a hybrid workforce: Know whether the customer or business received the intended result. Operate the service that enables the digital workforce: Know whether the delivery environment is available and operating within its limits. A technically healthy platform can produce unacceptable business work. A business team can make a reasonable decision and still be let down by an unavailable dependency. The two operating views need to meet, without making the platform operator accountable for every business decision. Two human owners examine one shared work record. The enabling platform is available, but the business outcome remains unresolved and has not been accepted. Figure 2. The platform is running. Is the service working? Both operating views need the same work record, without blurring their accountabilities. This is the role I mean by Mission Control: the ability to allocate work, see its state, expose missing decisions, intervene, handle exceptions and retain evidence. It is an operating capability, not necessarily a new control-room dashboard or a claim about a delivered product. Bob's Ghost in the Machine describes a gap between an apparently active workforce and results I could rely on. It is a useful practitioner account of why a status signal must be tested against evidence—not independent validation of this operating model. For our fictional offering, “assessment started”, “assessment returned”, “readiness accepted” and “service authorised for use” should not share one green tick. I want to see which result exists, what still waits on a decision and who owns that wait. Bob's build-lane reflection adds another useful distinction: a policy refusal, a containment boundary and a broken service require different responses. Correctly blocked work should not be treated as an outage to route around. Most users should be able to understand their work, the decisions waiting for them and the outcomes their team is delivering. Operators need a different view of dependencies, failures, capacity and recovery. Both should refer to the same work and decision records. The service-management habits remain useful: incidents, recurring problems, controlled changes, supplier management, knowledge and continual improvement. PeopleCert's current ITIL guidance addresses digital products and services and includes AI governance. The application here is my proposed operating design, not an official ITIL model. We should use existing enterprise systems where they already perform these responsibilities. A DWOS that duplicates every catalogue, identity store and service desk could add more management work than it removes. 11. Can the business operate when the AI cannot? If access to a model is withdrawn, the provider is unavailable or the execution harness fails, what continues? “We will use another model” may be part of the answer. It is not a continuity plan on its own. The alternative may behave differently, require re-evaluation or depend on the same identity, network or knowledge service. Several agents can share one point of failure. I would start with the critical outcomes, the reduced service the business can accept and how long it can operate that way. The fallback needs to cover that agreed scope, not reproduce the entire automated workload. An execution environment is unavailable. A human owner retains the work record, a small team handles critical work, and a replacement environment remains behind a closed authorisation gate. This is a design requirement, not a tested failover claim. Figure 3. Carry the work, not an assumed right to act. Preserve the record, reconcile what happened and revalidate the next route; human fallback covers a deliberately reduced service. Stopping is an operational outcome too. In If Nobody Can Stop the Workflow, Nobody Really Owns It, Bob describes an internal task that finished before a hold reached the executing step. That bounded example does not prove a cancellation mechanism; it exposes what the evidence needs to distinguish. A stop request being received, further execution being prevented and earlier effects being reconciled are different states. For a consequential action, I want the relevant cancellation or containment behaviour tested, including delegated and queued work. If something has already completed or cannot be interrupted safely, the record must say so and route recovery to its owner. Changing a dashboard card to “blocked” is not enough. Recovery also needs care. Some actions may have completed while confirmation was lost. Unfinished work needs reconciliation before retrying; otherwise restoration can create duplicate changes, communications or commitments. A pause control, a recovery owner and an authoritative record matter as much as the ability to restart. For the fictional capacity service, the continuity question is not merely whether the monitoring agent comes back online. It is whether someone can identify urgent capacity exposure, understand which changes already occurred and take authorised action while the service is degraded. That person needs more than their name on a recovery plan. They need to understand the service, have access to current information and know which decisions they are allowed to make. They also need opportunities to practise. We cannot remove people from the work, let their knowledge fade, and then assume they can take over when the agent stops. That does not mean keeping a second workforce ready to repeat everything manually. It means deciding what must carry on, what can run at reduced capacity and what can wait. An agent might normally assess hundreds of signals. During an outage, the human team may need to concentrate on the few that could materially affect customers. That is a different operating mode, and it needs to be designed and rehearsed—not improvised during an incident. This is where continuity becomes a workforce-sustainability question. If agents take on more of the routine work, how do people continue to build the experience needed to supervise them, challenge a recommendation and handle an unfamiliar situation? The time spent developing that judgement belongs in the operating model and its cost—not outside it as something people are expected to maintain themselves. Sometimes the responsible answer will be to pause. If nobody can establish what has happened, or there is no safe and authorised way to continue, keeping the service moving is not automatically the right outcome. A sustainable operating model needs the ability to stop, explain the impact and recover deliberately. 12. Learning is valuable; silent change is not An incident, a recovery exercise or everyday delivery should teach us something about the whole team: where people need practice, where an agent needs improvement and where the process itself is getting in the way. A digital worker should improve. The organisation still needs to know what changed and why the new arrangement is acceptable. The loop I want is capture the lesson → review the evidence → improve and test → check readiness → approve and release → measure the result. A prompt edit, model replacement, new tool, changed knowledge source or revised memory can alter the effective worker. None is automatically an improvement because the next answer looks better. Proposed changes should be tested against the intended benefit and previously accepted behaviour. The accountable owner decides what may be released, in which scope and with what recovery route. Production results then inform the next review. Local learning is not automatically enterprise knowledge. A technique that helped one team may depend on its data, authority or customer conditions. Sharing the lesson is useful; promoting it into a standard method needs its own decision. This should improve the operating model as well as the agent. Repeated escalation might expose a confusing policy. Rework might reveal an inconsistent catalogue. Slow approvals might be a human-capacity problem. Calling every failure an agent problem prevents the organisation from learning about itself. One practical example is the harvest step I have been building into the frameworks I use for managed-services and professional-services responses. I do not want the useful learning to disappear when a response is finished or a session ends. What worked? Where did someone have to intervene? Which assumption was wrong? What created unnecessary checking, cost or rework? Capturing that while the work is happening matters. By the end, we may remember the finished document but forget the awkward handoff, missing instruction or workaround that made it possible. The next question is where the lesson belongs. An unclear responsibility might call for a change to the agent’s role description. A recurring task might need a better skill. A missed handoff might expose a workflow problem. A failure we do not want repeated should become an evaluation case. Sometimes the right response is better guidance for the person—not another agent. Harvesting identifies a possible improvement; it does not approve one. The lesson still needs evidence, review and testing before it changes the shared method or a worker’s operating configuration. Customer information, sensitive material and engagement-specific exceptions must not quietly become reusable knowledge. The value is not the size of the lessons register. It is whether a reviewed change makes subsequent work better—and whether we can see that it did. The illustration follows the same agent team through three scenes. First, they combine their work, but assumptions are missing at the handoff. Next, the team and human owner review the gap and propose a shared check. Finally, after testing and human approval, the check reaches later jobs through the shared workflow. The improvement is to the shared method, not just one agent’s memory. Changes apply within their approved scope. This is an illustration, not a record of a deployed capability. 13. Sustainability is what we can keep doing These responsibilities are connected. Developing people and agents takes time and investment. Keeping enough knowledge and experience in the team affects both the cost of the service and its ability to recover. Reducing the token bill is not much of a saving if we create more checking, rework or dependency somewhere else. For me, sustainability is whether we can keep delivering useful work without exhausting the people, losing the knowledge or underfunding the systems and controls that make it possible. That includes what happens when the AI is unavailable—not just how well everything performs on a normal day. I see four connected dimensions of that sustainability. Dimension: Human What I would want to examine: Meaningful work, retained skills, development time, manageable supervision and the right to challenge What I would not assume: Faster output means people are better off. Dimension: Economic What I would want to examine: Fully loaded cost, continuing development and assurance, recovery capacity, dependency exposure and durable value What I would not assume: Cheap inference makes the whole service cheap. Dimension: Operational What I would want to examine: Critical service continuity, rehearsed recovery, retained expertise and replaceable dependencies What I would not assume: More agents mean more resilience. Dimension: Environmental What I would want to examine: Available energy/emissions evidence, workload volume and unnecessary computation What I would not assume: Lower token spend proves a lower environmental impact. These are design questions, not measured benefits of this model. Environmental comparisons need an explicit measurement boundary and credible provider or workload data. A more efficient task can still contribute to greater total consumption if we multiply its volume. Where evidence is unavailable, say so. The workforce dividend is a leadership choice too. If the hybrid team creates capacity, where does it go? Better service, deeper analysis, new offerings, resilience, learning or less overload? Those outcomes will not appear merely because we installed a tool. A workforce is not sustainable if today’s efficiency comes at the expense of the capability we will need tomorrow. I do not want sustainability to become a decorative section at the end of an AI strategy. It should influence the design of the work and how we judge its value. 14. Build on existing disciplines, and be honest about the mapping This work does not start from a blank page. It should connect to the organisation's existing management, risk, security and service practices. Public foundation: ISO/IEC 42001:2023 What it contributes: Requirements for an AI management system and its continuing improvement What this paper does not establish: Conformity, certification or proof that an individual agent is safe Public foundation: ISO/IEC 23894:2023 and ISO/IEC 42005:2025 What it contributes: AI risk-management and impact-assessment guidance What this paper does not establish: An organisation-specific risk or impact assessment Public foundation: ISO/IEC 27001:2022 What it contributes: Information-security management What this paper does not establish: Implemented or effective security controls for a particular deployment Public foundation: ISO/IEC 20000-1:2018 What it contributes: Service-management system requirements across the service lifecycle What this paper does not establish: Service acceptance or certification of this operating model Public foundation: NIST AI Risk Management Framework What it contributes: Voluntary AI risk and trustworthiness guidance What this paper does not establish: A compliance badge or independent assurance opinion The ISO references here are public purpose summaries, not a clause-level assessment of licensed standards. NIST states that AI RMF 1.0 is being revised; the applicable version should be checked when an organisation uses it. OWASP, FinOps, assurance guidance and service-management practice add complementary perspectives, as linked in the relevant sections above. My proposed contribution is the connection between these disciplines and everyday workforce decisions: who owns the work, who may act, what evidence is needed, what it costs and how the organisation learns. The practical mapping needs a control owner, an implementation and evidence of whether it works—not just a list of frameworks in an appendix. Referencing a framework, mapping to it, implementing controls and demonstrating effectiveness are different achievements. None should be described as certification without the relevant assessment. 15. Scale the responsibilities, not the bureaucracy In a large enterprise, the operating model must support distributed ownership, shared services, professional boundaries and required independent decisions. A product team cannot grant itself every security or commercial permission because it wants to move faster. In an SMB, a smaller group may hold several of those responsibilities. In a small business, the owner may commission, review and accept much of the work. The records can be lighter and the tooling simpler. The distinctions still matter. Role collapse does not create independence. If a decision needs a separate reviewer, one person wearing two hats does not satisfy it. The options are appropriate independent support or a narrower operating scope. Bob and my personal agentic team give me a useful place to explore these questions. They also expose the limits of that environment. One person supervising several digital contributors does not establish enterprise readiness across business units, suppliers or regulated processes. Personal experimentation can sharpen a design; it cannot stand in for evidence from those conditions. The same caution applies in the other direction. A small business should not need to reproduce an enterprise committee structure to use a bounded worker responsibly. Start with clear ownership, explicit permissions, useful evidence and a recovery path proportionate to the consequence. 16. Turn the model into something people can use A paper cannot enforce a permission or resolve a stalled decision. The ideas need a practical expression. I want a portable, versioned operating-model description: common definitions and minimum controls, reusable profiles for different work, and organisation-owned settings for local responsibilities and constraints. A design canvas could make that model understandable by showing the outcome, team, services, decisions and evidence together. The canvas should be a view of the governed model, not another place to maintain competing facts. Drawing an approval boundary does not prove that a runtime enforces it. The implemented behaviour has to be checked against the intended design. That is the direction I am exploring through Primitives and the Mission Control application, with Bob as a personal testing context. Design, review, approved release and live operation need to stay connected without being treated as the same state. It is a design direction, not a claim that the complete enterprise implementation is delivered. The management argument in this paper should remain useful without adopting either platform. Portability means more than changing the model selector. The organisation should retain its work definitions, approved knowledge, responsibility boundaries, evidence and recovery arrangements when a supplier or harness changes. The new arrangement still needs proportionate re-evaluation. Moving the files does not prove that permissions, hand-offs or behaviour survived the move. For a starting point, I would take one outcome and write a short operating brief: Put this in the brief: Result and acceptance Make it specific enough to review: What is delivered, to whom, under which conditions, and who can accept it? Put this in the brief: Team and ownership Make it specific enough to review: Which person owns the end-to-end work, and what do people, agents and services contribute? Put this in the brief: Authority and boundaries Make it specific enough to review: What may proceed without asking, what needs a decision, and what is prohibited? Put this in the brief: Preparation and evidence Make it specific enough to review: Which sources, versions, tests and observed results justify the proposed reliance? Put this in the brief: Service and recovery Make it specific enough to review: Who handles exceptions, who can stop or recover the work, and what reduced service can a prepared team sustain without the AI? Put this in the brief: Cost and value Make it specific enough to review: What does delivery cost over its lifecycle, including development, assurance and recovery readiness, and what improvement will be measured? Put this in the brief: Learning and change Make it specific enough to review: How do operational lessons improve people, agents and the process, and who approves changes and protects time for development? Then test the brief against an awkward case, not only the happy path. Change a source. Remove an approver. Fail a dependency. Ask whether the team still knows what it may do and who owns the unresolved work. Use synthetic or otherwise permitted information until the relevant data and operating authority are in place. I would also try a handover test: can another appropriately prepared person use the brief, find the current evidence and understand the next decision without me reconstructing the whole job from memory? That is a test I want the model to pass, not a result I am claiming here. If the author must remain the hidden integrator, we have made the work look portable without yet making it dependable. The next decision is not necessarily to expand. It might be to simplify the architecture, fix the source material, improve a human hand-off or decide that this work should remain human-led. Where this leaves us The earlier composition article asked how much machinery the work actually needs. The launch article asked why an operating system is needed. The confidence, trust and assurance article examined a decision to rely on a worker. This paper puts that decision inside the larger organisation. The supporting pieces will go deeper into hybrid role design; Agent HR and human development; fully loaded economics and outcome-priced services; agent-to-agent delegation; Day-2 continuity; controlled learning; and sustainability. They should develop the methods without making every article repeat the whole model. What remains to be demonstrated is equally important. This is a practitioner operating-model proposal, not evidence of enterprise-scale effectiveness, a calibrated scoring system or a promised return on investment. Its usefulness needs to be tested against real work under appropriate authority, with the people affected able to challenge the design. The opportunity I care about is larger than completing today's tasks faster. A well-designed hybrid workforce could give people more capacity to understand a problem, explore better options and deliver something the customer could not reasonably expect from the old arrangement. But that possibility depends on the management work around the agents: ownership, authority, evidence, human capability, economics and recovery. The test of that management is not the weight of its documentation. It is whether useful work arrives safely and remains dependable over time—without exhausting the people, hiding the true cost or losing the knowledge needed to challenge and recover it. The shift is not from people to agents. It is from isolated agents to governed digital labour—and from two separate workforces to one accountable organisation.