Begin with an outcome that matters to a stakeholder. Ask what would improve, for whom and why it matters now. Make the ambition specific enough to compare with the current position. This gives leaders a basis for choosing what to change and deciding whether autonomy is useful in that context.

Define the scope, Outcome owner and baseline. Identify the decisions, knowledge and handoffs that shape the outcome. Ask why each step exists and which constraints are necessary. Record the conditions an improved design must meet, including service quality, human responsibilities and acceptable risk.

Inspect the operating record before selecting a model. Identify the systems of record, interfaces and data needed to support the outcome. Match a rule, query, conventional automation or model-assisted step to the uncertainty in the work. Use a representative set of cases to compare alternatives against the same acceptance criteria.

• Set goals with OKRs — Objectives connected to measurable key results.
• Building effective agents — Workflow and agent distinctions, simplicity, and cost and latency trade-offs.

• Possibilities
• Operating Blueprint

Fund the next justified commitment. Explain the expected benefit, the assumptions behind it and what must be learned before expanding. Distinguish cash savings, avoided costs, released capacity and improved service. Each creates value differently and requires its own evidence.

Agree the scope, accountable sponsor, funding, review point and conditions for choosing Expand, Continue, Narrow, Redesign or Stop. Include implementation and continuing operation. Name how released capacity will be used and who owns that change. Build a roadmap around dependencies such as knowledge ownership, interfaces, controls and workforce capability.

Estimate integration, infrastructure, model inference, retrieval, tool execution, evaluation and support. Include routine and difficult paths, retries, human review and peak demand. Test sensitivity to volume, response time and quality requirements. Compare simpler designs with more autonomous ones using measured cost and performance rather than model-call price alone.

• The Balanced Scorecard: Translating Strategy into Action — Financial, customer, internal process, and learning and growth perspectives.
• Building effective agents — Workflow and agent distinctions, simplicity, and cost and latency trade-offs.

• Measurement
• Operating Blueprint

Coordinate the work around the outcome. Determine what can proceed independently, what must happen in sequence and where a decision changes the path. A useful system carries the context forward, completes the work it is authorized to do and brings people the decisions that need their contribution.

Define the routine path, exceptions, handoffs and recovery. Give each piece of work a state, an owner and a completion condition. Specify how people and systems share information, resolve conflicting inputs and resume interrupted work. Examine whether coordination creates more value than the effort it adds.

Use a defined workflow when steps and checks are predictable. Consider an agent when choosing the next step is part of the task. Use several agents only where specialization or parallel work adds demonstrable value. Preserve task state, limit tool permissions and work budgets, and design for retries, duplicate actions and partial failure.

Predictable path: Defined workflow

Explicit steps and checks make execution easier to inspect. Exceptions still require a designed response.

Variable path within a clear goal: Agent with bounded tools and stopping conditions

Flexible step selection adds evaluation and supervision needs.

Useful specialization or parallel work: Coordinated agents

Test the gain against communication, state management and failure-handling overhead.

• TOGAF Standard overview — Enterprise architecture practice and adaptation of TOGAF guidance to an organization’s needs.
• Building effective agents — Workflow and agent distinctions, simplicity, and cost and latency trade-offs.

• Operating Model Redesign
• Operating Blueprint

Bring people a prepared decision. The request should explain what happened, what is uncertain, what choices are available and why human involvement is needed. The purpose is to make judgment effective while reducing the investigation and coordination required to reach that point.

Name the responsible role, the evidence required, the response expected and the safe fallback. When two roles must contribute, gather their input around one shared case and make the final decision owner explicit. Define how conflicting responses are resolved and how work resumes after an authorized decision.

Route the request with relevant sources, task state, permitted options and action history. Keep the task pending while a response is required. Verify the responder’s authority and the current case state before resuming. Use explicit escalation conditions and tested failure paths; a model’s confidence statement alone is insufficient.

• NIST AI Risk Management Framework Core — Govern, Map, Measure and Manage; ongoing governance and documented responsibilities.
• Building effective agents — Workflow and agent distinctions, simplicity, and cost and latency trade-offs.

• Operating Model Redesign
• Measurement

Make the knowledge needed for a decision usable at the point of work. Ask which facts, policies, experience and relationships matter, whether they can be trusted and who may use them. Make gaps and conflicting evidence visible. Treat forecasts and plans according to their assumptions and uncertainty.

Give critical knowledge a source, owner, update rule and access boundary. Agree shared definitions where teams use the same words differently. Identify who resolves conflicts and how corrections reach future work. Assemble the context needed for the particular decision instead of treating the entire enterprise repository as equally relevant.

Use permitted system interfaces for current facts. Use retrieval-augmented generation, or RAG, when source material needs to inform a generated response. Consider agentic retrieval for questions that justify planning and multiple searches. Use shared definitions or an ontology when entities and relationships affect meaning. Test source access, freshness, retrieval quality and how insufficient evidence is handled.

Current operational facts: Permitted interface to the authoritative system

Freshness depends on the source, its availability and the access allowed.

Relevant policies or documents: RAG

Retrieval can supply useful grounding; poor retrieval, stale sources and unsupported synthesis still need to be tested.

Investigation across questions or sources: Agentic retrieval within a RAG design

Planning and multiple searches may improve coverage while adding latency, cost and evaluation needs.

Consistent entities and relationships: Shared definitions or an ontology

Explicit meaning can support interpretation and joins; ownership and maintenance require ongoing work.

Knowledge: The maintained facts, policies, experience and relationships the enterprise uses to support decisions.

Context: The task-relevant information, instructions and state supplied for a particular decision. Authority must also be enforced by the systems that execute actions.

Inference: The model’s generation of an output from its inputs and learned parameters. Relevant context helps; it does not itself establish correctness.

Ontology: An explicit description of concepts, entities and relationships that supports shared meaning.

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — Retrieval-augmented generation as a model-and-retrieval approach.
• Agentic retrieval overview — A concrete implementation of query planning, multiple searches and added latency.
• OWL 2 Web Ontology Language Document Overview — Ontologies as explicit representations of concepts and relationships.

• enterprise knowledge backbone
• Operating Blueprint

Turn useful feedback into an improvement the enterprise can reuse. A correction should outlive the immediate case when it reveals better guidance, missing knowledge or a recurring weakness. Demonstrate that the change improves subsequent work and identify when it should no longer apply.

Capture feedback with the original context and evidence. Assign an owner to review it, resolve conflicts and decide whether the change belongs in knowledge, instructions, tools, controls or the work itself. Make the review path visible to contributors so people can see what happened to their input.

Separate temporary case state from reusable knowledge. Preserve provenance and permissions when proposing an update. Version approved changes, evaluate them against representative cases and examine regressions before wider use. Keep a recovery path. Model retraining is one possible intervention; many improvements come from other parts of the operating system.

• NIST AI Risk Management Framework Core — Govern, Map, Measure and Manage; ongoing governance and documented responsibilities.
• Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — Generative AI risk identification, evaluation and management considerations.

• enterprise knowledge backbone
• Measurement

Delegate authority for a defined purpose and scope. Use four arrangements: Recommend leaves the decision with a person; Act permits specified execution while conditions hold; Escalate withholds the affected action and routes an exception; Never Delegate reserves the named decision to humans. These are arrangements within one workflow, not steps toward maximum autonomy. Specify retrieval access separately, and name who can restrict or withdraw permission. Match authority to the evidence and the consequences of action.

Describe eligible cases, permitted actions, required evidence, approval routes and recovery responsibilities. Separate proposing an action from committing it where the consequences require that distinction. Review boundaries when the work, risk or evidence changes. The number of interventions alone does not determine whether authority should expand.

Enforce identities, permissions, scoped tools and policy checks at execution time. Keep the model’s instructions consistent with those controls, while retaining enforcement outside the model. Validate proposed actions against the current case and authorization. Record what was permitted, attempted, approved and completed so decisions can be investigated.

• NIST AI Risk Management Framework Core — Govern, Map, Measure and Manage; ongoing governance and documented responsibilities.
• Security and Privacy Controls for Information Systems and Organizations — Access control, audit, monitoring, incident response and related control practices.

• Operating Blueprint
• Operating Model Redesign
• Bounded Autonomy — authority arrangements

Make control effectiveness visible during operation. Security, privacy and assurance need owners, mechanisms and evidence. Leaders should be able to see which risks are addressed, where uncertainty remains and how the enterprise will respond when an important boundary is challenged.

Define preventive checks, detection, intervention and incident response. Test difficult and inappropriate requests as well as routine work. Keep access decisions and operating policies current. Agree who investigates an incident, who can stop or restrict activity and how the operation returns to an acceptable state. Translate applicable obligations into controls and review duties, and examine whether outcomes introduce unfair treatment.

Apply least privilege, input and action validation, protected interfaces and monitoring. Treat retrieved and external content according to its trust level. Connect source references, system events and action records so reviewers can investigate an outcome. Use evidence and decision records for explanation; a fluent model narrative is not a substitute for verifiable records.

• NIST AI Risk Management Framework Core — Govern, Map, Measure and Manage; ongoing governance and documented responsibilities.
• Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — Generative AI risk identification, evaluation and management considerations.
• Security and Privacy Controls for Information Systems and Organizations — Access control, audit, monitoring, incident response and related control practices.

• Operating Blueprint
• Measurement

Design human contribution around judgment, relationships, outcomes and improvement. As systems perform more execution and coordination, people need clear responsibilities and time to develop new capabilities. Leadership must align measures and incentives with the work it wants people to do.

Define decision ownership, exception duties, knowledge stewardship and improvement responsibilities. Examine the work that remains, including supervision and support. Decide how released capacity will be used. Involve people in redesigning the operation and make feedback part of how work improves, with visible ownership and follow-through.

Bring relevant cases and evidence to the responsible role within the tools people use. Preserve context across collaboration, approvals, overrides and feedback. Make permissions and pending decisions visible. Measure the attention required by the interface as part of the design; a stream of low-quality requests can move effort rather than reduce it.

• The Balanced Scorecard: Translating Strategy into Action — Financial, customer, internal process, and learning and growth perspectives.
• NIST AI Risk Management Framework Core — Govern, Map, Measure and Manage; ongoing governance and documented responsibilities.

• Operating Blueprint
• Operating Model Redesign

Develop the ability to direct work, question evidence and improve the operation. People need to understand what the system can be trusted to do in the current scope, when to challenge it and how to intervene. Treat these abilities as part of role expectations and leadership development.

Identify the judgments each role must make. Use realistic practice, coaching and case reviews to develop them. Include unfamiliar situations, conflicting evidence and the pressure to accept a convenient answer. Check demonstrated capability in the work and revisit expectations when responsibility changes.

Expose relevant evidence, uncertainty, action history and available interventions in understandable form. Provide practice environments that allow people to inspect and challenge outcomes. Capture useful feedback with its context. Design explanations around the decision being made and distinguish observed facts, model-generated suggestions and human approvals.

• NIST AI Risk Management Framework Core — Govern, Map, Measure and Manage; ongoing governance and documented responsibilities.
• The Balanced Scorecard: Translating Strategy into Action — Financial, customer, internal process, and learning and growth perspectives.

• Operating Blueprint
• Measurement

Use outcomes, economics, controls and human workload to decide whether to Expand, Continue, Narrow, Redesign or Stop. More activity and greater delegation are useful only when they support the intended result. Look for evidence of sustained value and for conditions under which performance deteriorates.

Give each measure a baseline, owner, measurement method and decision threshold. Review difficult cases, incomplete work and variation between business areas alongside averages. Separate realized savings from capacity awaiting a useful purpose. Define the evidence needed for the next investment and delegation decision.

Evaluate representative cases before release and monitor operation afterwards. Combine outcome measures with quality reviews, errors, latency, costs, required escalations and control evidence. A system can assemble this evidence and flag possible gaps. Claims about readiness still require suitable measurement coverage and accountable review.

• The Balanced Scorecard: Translating Strategy into Action — Financial, customer, internal process, and learning and growth perspectives.
• Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — Generative AI risk identification, evaluation and management considerations.

• Measurement
• Operating Blueprint

Notice changing conditions and improve the operation through authorized action. Distinguish a routine recovery from a change that affects the operating model. Restrict activity when evidence no longer supports the current scope, and use recurring problems to inform the next improvement.

Name the signals that should trigger investigation, intervention or recovery. Define permitted responses, escalation paths and recovery ownership. Review repeated incidents for weaknesses in knowledge, work, controls or incentives. Retest changes before they become the new operating baseline.

Monitor operational signals and retain enough state to recover safely. Design retries and recovery actions to avoid duplicate commitments. Test staged changes and rollback where appropriate. Apply the same authorization and evidence requirements to repair as to ordinary execution; requests outside those limits require the defined review path.

• TOGAF Standard overview — Enterprise architecture practice and adaptation of TOGAF guidance to an organization’s needs.
• Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — Generative AI risk identification, evaluation and management considerations.
• Security and Privacy Controls for Information Systems and Organizations — Access control, audit, monitoring, incident response and related control practices.

• Operating Blueprint
• Measurement