The Hybrid Enterprise Is One Organisation Written by Benjamin Johnson. This is an AI-narrated reading. What running my own agent team is teaching me about responsibility, permissions and getting work finished. In the conceptual illustration: Concept illustration of a human service owner and an agent lead reviewing the same service work packet, with a specialist agent contributing nearby and infrastructure visible behind them. The human points to the decision while the agent presents evidence. One service, shared work and explicit human responsibility. Concept illustration, not a photograph of my environment or proof of a deployed team. When I think about a hybrid workforce, I generally start with the service offering. What are we promising to deliver, how does that delivery work today, and where could we streamline it? For a managed service, I am thinking about the daily operation: reducing unnecessary hand-offs, making routine work more consistent, spotting issues earlier and giving people more room to focus on complex problems and customer outcomes. That might mean improving an existing offering rather than creating a new one. I want to understand where agents could help with that work before deciding which roles to create. I am working through this with my own AI and lab infrastructure: the services I use to work with my agent team, the monitoring and scheduled jobs behind them, and the compute, storage and network they depend on. In Beyond Agents: The Digital Workforce Operating System, I set out the model I believe we need to govern digital labour. The question here is how people, agents and specialist teams work as one organisation to deliver and sustain the service. For me, sustainability has a practical test: can we keep the service healthy, current and recoverable without making one person the permanent coordinator, reviewer and emergency fallback? More agent activity is not the result I am after. A service we can continue to stand behind is. The test is not whether I can add another agent. It is whether the organisation can carry the work, including the decisions, the interruptions and recovery when something goes wrong. Manage the contribution, not the collection of agents My background is ICT managed services and innovation. When I think about a service-operations team, I think about whether the environment stays available, incidents receive a timely response, service is restored when something fails, and systems remain patched and supportable. I would start with the service outcomes, then work out the people, agents, expertise and decisions needed to deliver them. The same expectations should apply whether the first investigation comes from a human engineer or an agent. There are three outcome areas I would put at the centre of that conversation: The table compares Service outcome, Evidence I would want. Service outcome: Keep the service available and useful. Evidence I would want: Measured service availability against an agreed target and measurement window, supported by checks of user-visible errors, latency and service health—not just whether a host is running. Service outcome: Restore service and resolve the work properly. Evidence I would want: Time to verified restoration, ticket-resolution time and reopened work; acknowledgement and meaningful response times by priority help explain where the delay occurs. Service outcome: Keep the environment current and supportable. Evidence I would want: The share of in-scope assets patched within the agreed window, overdue items and the age of approved exceptions; changes must not create an unacceptable level of service disruption. I would be precise about the clocks. Here, MTTR means mean time to restore service, from the start of service impact to verified restoration. Ticket resolution is a separate measure: closing the record does not prove recovery, and restoring service may leave follow-up work. Atlassian's incident-metric definitions distinguish several uses of MTTR; I would not mix those meanings in one report. For response, I want to know when somebody with responsibility acknowledged and began to own the issue, not merely when a system generated an automatic reply. For patching, an approved exception should remain visible, not disappear from the denominator to improve the score. Availability needs an agreed service boundary, observation window and treatment of maintenance. The targets have to fit the service promise and the owner's risk decisions. I am not attaching invented response times or availability commitments to a personal lab. I am describing what I would expect the operating model to make measurable. Speed needs guardrails too. Faster ticket closure is not a gain if incidents reopen, changes cause avoidable disruption, controls are bypassed or people inherit more after-hours recovery work. That is how I would judge the contribution of an additional agent: does it help keep the environment healthy, shorten a justified response or recovery path, maintain patch currency, or improve the quality of the decision? What contribution do I need? Who owns it? What information can they use? What happens when they hit a boundary? Who checks the result, and who can say it is good enough? That means treating an agent as an extension of the team, with the same seriousness about role clarity, supervision and accountability that I would expect around a human colleague. It does not mean pretending the agent is a person, giving it human standing, or transferring my accountability to it. A specialist earns its place through a real service need. Those needs also cross product, security, commercial and customer-service responsibilities; Operations cannot make the service sustainable on its own. Put the work on the table before deciding who joins the team For a managed service, I would make the contributions and retained decisions explicit before drawing the team. This applies whether we are developing an offering or improving how an existing service operates. The table compares Contribution, Useful digital work, Human decision that remains. Contribution: Product and solution design. Useful digital work: Compare options, trace requirements and expose assumptions. Human decision that remains: Which customer problem are we solving, and what belongs in the offering? Contribution: Service operations. Useful digital work: Assemble dependencies, operating procedures and readiness gaps. Human decision that remains: Can we deliver and support the service under the stated conditions? Contribution: Security and risk. Useful digital work: Organise access requirements, identify gaps and prepare challenge. Human decision that remains: Are the controls and residual exposure acceptable to the relevant authority? Contribution: Finance and commercial. Useful digital work: Maintain an inspectable cost model and flag unconfirmed commitments. Human decision that remains: What investment, price and contractual commitments may the business make? Contribution: Service management. Useful digital work: Assemble service-performance evidence, track agreed actions and prepare customer reviews and improvement options. Human decision that remains: Are we meeting the agreed service outcomes, what needs escalation, and which improvements should we prioritise with the customer? Service management is more than producing a customer update. It connects the service promise to performance, the customer relationship, escalation and continual improvement. Communication is part of that responsibility, not a substitute for it. These are contributions, not five compulsory departments or agents. A smaller business may combine several responsibilities; required independent review still needs to be preserved. A human–agent lead pairing can help connect that work, not absorb every owner's decisions. Putting those contributions on paper is the starting point. Building my own operations team is showing me what happens when the responsibilities meet actual work—and how quickly the human owner can become the connection between everything. Building Alfred's service-operations team The wider service-management model I have been developing is broader than a service front door, event triage or a security analyst. It includes a Service Desk, Event Manager, Change Manager, Problem Manager, Service Delivery Manager, Technical Delivery Manager, and XLA and Experience Analyst, with practice ownership and continual improvement connecting the functions. Those are contributions to the service, not a requirement to create one agent for every job title. A small environment may combine responsibilities. A larger organisation may share some capabilities and dedicate others. Neither arrangement works merely because all the names appear in a catalogue. From my environment to corporate IT The broader role model tells me what work needs covering. My internal environment lets me test parts of it. A corporate application then has to fit the services, people and commitments of the organisation that will rely on it. These are intended contributions, not a claim that every role is already active: The table compares Function and example roles, Intended internal contribution, Corporate application to explore. Function and example roles: Front door and response — Service Desk and Event Manager. Intended internal contribution: Bring requests, operational signals and follow-up into an owned work record. Corporate application to explore: Connect service intake and business impact to the right resolver group, escalation and update cadence. Function and example roles: Change enablement — Change Manager. Intended internal contribution: Establish readiness, dependencies and the decisions needed before changing the AI or lab environment. Corporate application to explore: Work within business risk decisions, customer change windows and the organisation's change authority. Function and example roles: Problem management and learning — Problem Manager and predictive analysis. Intended internal contribution: Connect repeat failures, recurring friction and evidence to an improvement action. Corporate application to explore: Coordinate investigation and prevention across services, teams and suppliers rather than repeatedly treating symptoms. Function and example roles: Service and technical delivery — Service Delivery Manager and Technical Delivery Manager. Intended internal contribution: Connect service priorities and reviews with the technical work needed to keep the environment supportable. Corporate application to explore: Distinguish service commitments, relationships and performance from technical delivery coordination and dependencies. Function and example roles: Experience and improvement — XLA and Experience Analyst, supported by practice ownership. Intended internal contribution: Examine whether the service helps the people using it, including repeated friction that healthy infrastructure alone may not reveal. Corporate application to explore: Combine service performance with experience feedback and accountable improvement decisions. That is why change, problem management, delivery and experience belong in this discussion. They sustain the same service at different points. They are not unrelated extras added to an event-monitoring team. What we are exercising internally Our internal build began with a practical problem: there was no single clear front door. Bob handled enquiries, alerts came directly to me, and platform specialists both watched the environment and changed it. Useful work was happening, but responsibility for connecting it was too easy to leave with whoever noticed the problem first. Frequently, that was me. As at 31 October, part of that wider model is being exercised internally. Alfred has completed bounded advisory assessments and recommends routes, but does not have authority to change systems or approve the work. Event Manager is assessing events in read-only shadow mode, not running live incident management. The SOC Analyst role is registered but not operationally accepted. Those are different states of readiness, not a completed team simply waiting for more work. I am not treating the wider role list as an operational team inventory. A role definition explains the intended contribution; it does not prove that the worker is active, authorised or accepted in my environment. Platform and service specialists retain their own investigation and execution responsibilities. Bob coordinates across teams; security authority and independent QA provide their respective challenge; I retain consequential risk, change and outcome-acceptance decisions. Those are separate responsibilities, not a declaration that all contributors report into Alfred. Automated monitoring does not turn this arrangement into 24-hour staffed or autonomous response cover. A corporate IT environment is not simply my lab with more machines. A service may cross business owners, customers, suppliers, resolver teams and different service hours. The operating model has to specify who owns the service conversation, who owns technical delivery, what information each contributor may use, and which decisions remain with the organisation's authorised people. For example, a Service Delivery Manager and a Technical Delivery Manager may contribute to the same outcome without owning the same decisions. The service commitment and customer relationship need to stay connected to technical dependencies, maintenance and recovery work. Experience analysis then asks whether meeting a technical measure actually helped the people relying on the service. Project coordination may support a complex change. It does not need to become part of the standing service-operations front door. The wider model should make these contributions available when the work calls for them, not manufacture a reporting line for every possible specialist. Pair the human lead with an agent lead This is where a human–agent lead pairing becomes useful within the existing organisational structure. The human lead owns the service or business outcome and the decisions within their remit. The agent lead coordinates delegated contributions, gathers evidence, surfaces conflicting recommendations and brings back the decisions that need human attention. They work towards the same outcome, with different responsibilities. I would define the contribution before counting the resource. An FTE tells me about human capacity, not what that person is accountable for. Naming an agent tells me neither its productive capacity nor its authority. Both need a clear role, expected outcomes, permitted decisions, escalation boundaries and somebody who accepts the result. The comparison is not one person against one agent. It is how human and digital contributions combine to deliver the same service, at the required quality, with a workload people can sustain. For example, I could pair a managed-service owner with an agent delivery lead. The human owner would set priorities and agree the operating boundaries. The agent lead could track dependencies, assemble service evidence and highlight exceptions or improvement opportunities. Operations, security and commercial owners would retain the decisions in their own areas; the pairing would not absorb their authority. In the current internal phase, Bob connects the wider organisation and Alfred has an advisory service-operations remit. That gives me a practical starting point for developing the pairing, not proof that every hand-off already works. It is not a requirement to give every manager an agent counterpart, or permission for an agent lead to approve work merely because it coordinated it. Delegation still needs a clear scope, an escalation route and a named owner for any consequential action. In the conceptual illustration: An intended human and agent lead pairing connects service-management contributions to one outcome. Human leads retain decisions and acceptance in their remit; agent leads coordinate delegated work and return evidence and exceptions. Service desk and events, change and problem, service and technical delivery, and experience and improvement contribute to the same service. Domain owners, security and independent QA retain their own responsibilities. This is a design pattern, not a deployed team or a reporting hierarchy. One service, not two workforces. The pairing connects contributions without absorbing each owner's authority. This is the intended role model; the internal states described above remain advisory, shadow or unaccepted where stated. Corporate use still needs its own boundaries and validation. The value is in how those contributions fit together. That includes knowing how the responsible person is reached when the work becomes urgent. Reaching the person who can act In my setup, the escalation capability includes SMS for P2, and SMS plus a phone call for P1. Those channels matter because an operations model needs a way to reach somebody, not just another status update waiting on a dashboard. The capability belongs in an authorised escalation path. It does not give Alfred or the shadow Event Manager permission to declare an incident or contact people outside their remit. Bob retains P1 declaration and cross-team coordination under the current arrangement; I retain consequential risk and change decisions. I would want to know whether the notification was delivered, who acknowledged responsibility, how long that took and what happens if nobody responds. A message sent is not an acknowledgement. A call placed is not an answered call. Neither means the service has been restored. Having SMS and voice capability is not, by itself, proof of a tested end-to-end escalation path or round-the-clock response cover. In a managed service, the agreed coverage, named responder and fallback matter as much as the channel. If the whole arrangement depends on me answering every time, that is a human dependency to manage, not a sustainable workforce design. The same responsibility chain has to work during daily operations and a planned change. A different trigger does not remove the need for an owner, a usable hand-off and a human decision point. Alfred could assess the change. He could not make the hand-off. The next piece of real work came from a planned upgrade, not an alert from Event Manager. It tested a different part of the same operating model: could the team bring technical readiness, security review, independent QA and my change decision together before anyone altered the environment? This was not a request for Alfred to become the engineer or the Change Authority. His job was to assess readiness within his remit and connect the work to the appropriate owners. On 31 October, Alfred received that readiness request for the environment supporting Bob. It included routing work to a Change Manager and returning evidence that the hand-off had actually happened. Alfred could not start that hand-off. The interface needed to invoke the role was not available within his advisory scope. He did not invent a session identifier or write as though another agent had done work it had never received. He explained the limitation and assessed the evidence he could use instead. That assessment found that readiness for the exact change candidate had not been established. Earlier rehearsal candidates had failed and been revised. The supplied evidence did not establish completion of the required rehearsal, independent QA and security clearance for the current candidate. A possible change window was not my approval to proceed. The useful result was a clear stop: readiness not established. Alfred identified missing evidence and the owners who needed to supply it. Bob still had a coordination gap to resolve; the domain, security and QA owners still had their contributions to make; my consequential approval was still required. The reviewed record ends with an assessment, not an authorised or executed change. There are two lessons in that. An agent can do useful work by explaining why something is not ready. And if I give an agent a coordination role, I have to prove that it can actually reach the people or agents it is expected to coordinate. I can draw a Change Manager underneath Alfred on a diagram in seconds. That does not create a usable hand-off, transfer the context or give either agent permission to act. In the conceptual illustration: The observed 31 October journey is planned-change evidence to Alfred's authority/readiness assessment, an unavailable Change Manager hand-off, and a returned readiness-not-established result. Missing evidence, exact human approval, authorised execution and verification remain required next steps, not completed stages. A good assessment is not a completed change. The solid observed path ends at an unavailable route and a readiness-not-established result. The dashed continuation shows work still required, not completed, authorised or accepted stages. One change, more than one execution owner The readiness assessment exposed an unavailable hand-off. The separate 28 October review of upgrade work in Bob's environment exposed the related question of execution ownership. There was a person who could approve consequential steps: me. There was work being reviewed. There were rehearsals. What was less clear across the different workstreams was who alone owned execution of the shared change. One track was concerned with the upgrade. Another was working on a team that depended on the same environment. Those could sound like separate jobs until their work reached the same operational boundary. The source records do not fully reconcile who did what across every event, so I am not presenting this as a settled forensic account. The management response is clearer. I stopped the overlapping track from continuing the upgrade work, retained its other assigned work, named one upgrade owner and postponed the change. That was not a decision to abandon progress. It was a decision about how progress would be allowed to happen. The rehearsals were also doing useful work by finding defects. But a successful recovery component did not mean the whole change had passed. At the review point, no rehearsal had completed successfully end to end. I chose a longer, booked window rather than force the original plan or reduce what we were preserving merely to fit it. The distinction I take from this is simple: approval, review, execution and acceptance are separate responsibilities. Having the first two does not make the third unambiguous, or establish the fourth. Who owns which decision? Approval: The authorised human decides whether the proposed work may proceed. Review: A reviewer challenges the work and records a verdict within the review's scope. Execution: A named contributor carries out the permitted change; parallel work does not imply shared execution authority. Acceptance: The accountable owner checks the result, including what remains incomplete. One person may hold more than one responsibility. None should be assumed from another. In a human organisation, we recognise this problem. Two teams can each be doing useful work while creating a collision in a shared service. Agents do not remove that organisational problem. Their ability to work in parallel makes it more important to resolve. “Fix the issue” is not a complete operating instruction if several contributors can interpret it as permission to change the same thing. The security role was registered. That did not make it ready. The change examples ask who may coordinate, approve and execute. The SOC Analyst role added another question: did the intended control boundary hold when tested? On 29 October, an authorised synthetic exercise showed that it did not. This was a controlled test failure, not evidence of a real-data breach. The security authority's response was to block operational acceptance and require a stop, remediation and retesting. The fact that the role had a name, a job description and a registered identity did not make it safe to use. Bob routed the technical work to the platform owner. A repair candidate was prepared and validated offline, then received a conditional security review. Those were distinct contributions: preserving the test evidence, making the security judgement, coordinating the response and preparing the technical change. A conditional review was not my permission to execute it. The record available for the 31 October pack did not establish live execution or a successful retest. I cannot turn a prepared repair into a claim that the role was fixed and accepted for operations. That is the organisational lesson I want to keep, without publishing the control mechanism. A failed test must be allowed to change the plan. A security specialist's recommendation is not risk acceptance. A platform specialist's repair is not its own independent approval. And an administrative instruction to stop is a different claim from proof that a technical hold has been enforced. A role description says what the worker is meant to do. A configured permission says what a system has been told to allow. A test shows what happened under the conditions tested. Authority says whether this worker may undertake the particular work. I need those answers to agree. I cannot assume that they do because the document is well written or the setup looks correct. This matters even more as our work spans different models and agent harnesses. A harness is part of the environment that gives an agent tools, context and ways to act. The operating expectations should remain consistent across those environments; evidence about how a boundary behaves in one does not automatically transfer to another. That is not an argument for a separate organisation for every harness. It is an argument for one clear set of responsibilities, with checks appropriate to where the work actually happens. One organisation needs connected evidence, not unrestricted access to everything. The three episodes expose different ways a service can become dependent on a person filling the gaps: a route that cannot be used, overlapping execution and a control that did not hold. The sustainable response is not to ask that person to watch harder. It is to make the ownership, hand-offs and conditions for safe work explicit—and test them. When is an operations team ready to work? Those experiences make the word ready much less abstract. Writing the roles down is useful. It does not establish what each worker may do, which inputs it can use, where it must stop or whether the combined team can handle the work I intend to give it. A prepared role describes an intended contribution. A registered identity gives that contribution a place in a system. Approved access establishes what it may do. A test provides evidence about a particular capability under particular conditions. An accepted result tells us whether the work met the brief. None of those automatically supplies the next. For Alfred's team, I want to be able to answer each question separately, rather than let the word ready cover all of them. Four questions behind “done” Prepared: Can the role and its working material be reviewed? Authorised: Is this worker permitted to do this work, with these inputs and tools? Performed: What did it actually do, and what evidence supports that account? Accepted: Did the named owner accept the result against the agreed brief? These are distinct claims, not a declaration that our team has passed all four. My lesson is not that every small task needs a large onboarding programme. It is that I need to ask a more precise question when somebody, human or agent, tells me a team is ready. Ready for me to review? Ready to practise with permitted inputs? Ready to recommend a decision? Ready to take an action? Those are different responsibilities, with different consequences. If I hear the first and plan around the last, the operating failure starts with my interpretation, not just the agent's output. Readiness answers what a worker may contribute. The next question is how to organise that contribution across the services it supports without sharing away a boundary or building a queue nobody can sustain. Do we need one experienced worker or a team of specialists? The choice is much bigger than one capable agent versus several smaller ones. What should be shared across services or customers? What needs a customer-dedicated role? And how do we know the arrangement has enough capacity to deliver what we promised? A traditional managed-services mindset gives us useful starting points: service ownership, event management, specialist expertise, escalation and change authority. I would keep that discipline. I would not assume the best hybrid design is the same support hierarchy with agents substituted into every position. These are the arrangements I would compare, rather than a structure I can claim we have already proved: Shared event management. A common capability could assess incoming events, assemble permitted context and route work. I would require customer-specific priorities and escalation paths, with protection against one customer's event surge consuming everyone else's capacity. Shared specialists. Network, cloud or identity expertise might support several services where the method is reusable. Each assignment still needs its own permitted customer context, access and acceptance conditions. Reusing expertise must not become permission to mix customer information. Customer-dedicated specialists. A role bound to one customer may make sense where context, contractual boundaries, isolation needs or sustained demand justify it. A dedicated role does not, by itself, establish reserved processing capacity; that must be specified separately. A smaller, coherent assignment might still be better handled by one capable worker. Specialisation earns its place when it preserves a meaningful knowledge, access, evaluation or review boundary—not merely because the human team has a corresponding job title. My working hypothesis is a combination: shared capabilities where they genuinely fit, customer-bound work where context and authority require it, and a human service owner supported by an agent lead to keep the end-to-end result visible. Shared versus dedicated expertise, customer context, execution capacity and human accountability are separate design choices. In the conceptual illustration: Two shared capabilities, event management and specialists, support two peer customer teams through scoped work and returned evidence. Each customer team has its own human lead, agent lead and customer-dedicated agents. Human leads retain decisions in their remit and outcome acceptance; agent leads coordinate delegated work and return exceptions. Customer context, permissions and work records remain separate. There is no customer-to-customer route, and a dedicated role does not imply reserved execution capacity. One possible arrangement: shared capabilities support two peer customer service teams, each with a human–agent lead pairing and customer-dedicated contributors. Links represent scoped work and returned evidence, not shared customer access or granted authority. Roles do not prescribe fixed headcounts. These customer teams are illustrative, not a depiction of my lab. Conceptual illustration, not an operationally validated design. How would I know an agent is at capacity? Those allocation choices only work if I can see where the work goes and where it waits. Agent observability is part of the operating model, not an optional dashboard after the team has been built. “Overworked” is useful shorthand, but I do not mean that an agent tires like a person. I mean the assigned work can no longer be completed within the required time, quality and control boundaries. A role being available in the catalogue tells me nothing about that capacity. I need two connected views: the health of the environment and the behaviour of the workforce looking after it. Google's SRE monitoring guidance uses latency, traffic, errors and saturation as foundational service signals. For agent work, I also want to see the assignment, the hand-offs, the tool results, the decision points and the accepted outcome. The operational questions I would ask are: Is demand outrunning delivery? Compare incoming and completed work by task type and priority, the age of waiting work, and hand-off or approval wait times. An average can hide a small group of very old tasks. Where does execution get stuck? Look at tool failures, retries, rate limits, dependency latency and task duration. Separate time doing useful work from time waiting for another system or person. Does quality deteriorate under load? Track first-pass acceptance, rework, reopened work and routing judgements checked against human review. A correct escalation or stop must not be treated as failure merely because it needed a human. What does the work demand from people and resources? Watch human-review queue age and effort, repeated interruptions, and model/tool consumption per accepted result. A lower token count is not an improvement if it creates more rework; the full cost model belongs in the economics article. These are proposed diagnostic measures, not a claim that we already collect all of them or have calibrated capacity limits. They need consistent task identifiers, timestamps and owner records across the harnesses involved. A hand-off should carry permitted evidence references and approval context; observability is not permission to log every prompt, secret or customer record. The current build has already exposed waiting work that is not a model-capacity problem. Alfred could not invoke a requested role. In an earlier shadow review, he could not inspect the evidence needed to judge the Event Manager's work because the permitted access and evidence location did not line up. Creating another agent would not, by itself, repair either hand-off. That is why I want to distinguish a busy worker from a blocked workflow. Model latency, a tool dependency, an unavailable interface and a human approval queue call for different responses. A full context window, high token use or a count of active jobs is not a complete “agent utilisation” measure. Some of this is familiar engineering. Microsoft's queue-based load-leveling guidance warns that adding consumers can overload downstream dependencies. Its bulkhead pattern addresses protecting consumers from each other's resource exhaustion. Adding agent workers is not a way around those constraints. I would establish limits with representative work and bounded load tests, including burst demand and the review effort needed, before promising capacity. The response might be to prioritise, defer intake, protect a customer allocation, repair a hand-off, simplify the workflow or expand the actual bottleneck. Creating another named agent is only one possible response. Accountability and service commitments remain familiar. The way we assemble expertise, separate context and allocate execution does not have to copy human staffing one for one. Observability gives us a way to judge those choices rather than treating the organisation chart as the answer. That is also a sustainability question. If every increase in agent output creates a bigger human-review queue, or a shared capability lets one burst of work delay everyone else, the service design needs attention before I add more workers. Count the work we can rely on That distinction between activity and service contribution is already visible in our own records. The morning digest on 31 October recorded four Event Manager shadow triage results since 30 October. That is evidence that shadow work was produced. It is not four accepted incidents, four successful restorations or an accuracy measure. The sample had not yet been scored against a representative set of human judgements. For a service-operations team, there are plenty of other things I could count: events received, investigations prepared, reports produced and work cards updated. Those counts can help me understand activity. They cannot, on their own, tell me whether the AI and lab services are being looked after effectively. For Alfred's team, I would want the trail from a signal to its assessment, the owner of the next decision, any authorised action and the result that was checked. A quiet event queue is not enough if the service remains unhealthy or unresolved risk has disappeared from view. The question I want to move towards is: what work can I now rely on this team to perform, and what happened when it tried? Alfred's readiness assessment also needs the right unit of success. Returning a justified stop is useful; it does not count as delivering the change. An accepted outcome is already central to the operating model. The service-operations build needs to make it practical: who accepts an investigation or response, what evidence is retained, how rework is recorded and how much human review the work requires. For an event-investigation assignment, that might mean the agent used permitted evidence, separated observations from possible causes, exposed unresolved assumptions and returned a justified escalation or recommendation. The owner could accept that contribution without claiming that the underlying service had already been restored. An appropriate stop also deserves recognition. A worker that identifies a boundary and returns a useful explanation may have done exactly the right thing. That is not the same as completing the original outcome, and the record should make both facts visible. The performance conversation becomes much more useful when it can distinguish good work, a justified stop, avoidable rework and an unsupported claim of completion. The full approach to induction, evaluation and development belongs in the next article on Agent HR. The organisational requirement starts here: somebody must be able to judge the contribution in context. Knowing what the agents contributed is only half of the review. I also need to ask what the arrangement required from the humans around them. What changed because a human was involved? “Human in the loop” can sound reassuring while saying very little about the human's actual job. On 30 September, I accepted the model that separates the service-operations front door from technical change. In the earlier change-ownership episode, my contribution was not simply reading an agent's recommendation and clicking approve. It included stopping overlapping execution, postponing a change and choosing a window that reflected what the rehearsals were revealing. I also approved a reasoned list of stale or superseded work to close. That cleanup was still in progress when the case review was written. An approval to simplify the board was not proof that the board had already been simplified. These are management decisions: what matters, what should stop, what risk is acceptable, who owns the next step and when the organisation is genuinely ready. The agents helped bring the choices into view. They prepared options, carried detailed work and surfaced problems that needed attention. They also created more material to check and more coordination work. Both are true. I still believe there is a substantial human multiplier here. A team that can maintain research, expose assumptions and compare alternatives should create more room for customer understanding, solution design and challenging what we currently accept as standard practice. But should is doing important work in that sentence. These examples do not establish a productivity gain or a reduction in human review effort. If all I achieve is a larger queue of decisions waiting for me, I have scaled the bottleneck rather than the capability. The balance I want is not an agent for every possible role and a human approving every movement. It is useful delegated work within explicit boundaries, with human attention reserved for the decisions and consequences that require it. That balance needs evidence, not just enthusiasm about what the models can do. This is the human and operational side of sustainability for me: clear responsibility, supportable services and a level of review and interruption that people can keep carrying. Economic viability and environmental impact matter too, but this account does not measure those benefits. Nor do the examples establish that we can yet recover every service without a particular person, model or harness; continuity and fallback still need to be proved. The organisational design has to make those dependencies visible. If a particular agent, person, model or harness becomes unavailable, do we still know what is waiting, what must stop and how the service continues? It should create room for better work and recovery when something fails, not merely give the human owner a larger collection of agents to supervise. One organisation does not mean one giant agent The lesson I am taking into the next round of work is not that every agent needs to report through one universal controller. Nor is it that a hybrid workforce should copy a traditional organisation chart box for box. It is that work needs continuity of responsibility as it crosses people, agents, teams and technical environments. A useful handover carries the outcome, permitted inputs, authority, acceptance conditions and a route back when something is unclear. The next contributor should not have to reconstruct those from whichever conversation happens to be visible. In a larger enterprise, the same work may cross service owners, security, commercial teams, suppliers and a customer. In a small business, one person may carry several of those responsibilities. The structure can change. The need to know who can decide, who can act and who accepts the result does not disappear. Our personal work is not proof that this has been solved at enterprise scale. It is giving me much more concrete questions to take into that environment, and a healthier suspicion of the word complete. I do not need another set of impressive agent names beside the human organisation. I need a team whose contributions connect, whose boundaries hold up when tested, and whose results someone is prepared to stand behind. That is what I mean by one organisation. Not humans doing the important work while agents sit in a separate experiment. Not agents racing ahead while a human inherits the consequences. One body of work, with different contributions and responsibilities that remain visible from the brief through to the accepted result. Next in this series: Agent HR — how a digital worker earns a role, demonstrates its capability, receives a meaningful performance review and develops without quietly acquiring more authority.