Value and Feasibility Are Essential. Assurance Is Imperative.

Gartner’s data-and-analytics framing is a disciplined investment screen: assess the use case, govern the pilot, define evaluation criteria, measure outcomes, and scale only when value and feasibility are clear.[1] The architectural question that follows is different. Can the enterprise bound the workflow’s authority, govern its consequential actions, and defend its operation with evidence?

For Luminity, the board-level distinction is direct:

Value and feasibility determine whether a workflow is worth pursuing. Assurance determines whether it may proceed.

Assurance is not a third weighted score beside value and feasibility. It is the imperative. Before autonomy proceeds, the enterprise must determine whether authority can be bounded, consequential action can be governed, and sufficient evidence can be produced to defend the workflow’s operation.

The deliverable that makes that decision explicit is a Governed Workflow Blueprint.

Begin With the Workflow That Must Be Governed

A common implementation mistake is to choose the agent before defining the workflow and its consequential effects.

Start instead with the business workflow: the outcome, accountable owner, participants, decision rights, data, systems, handoffs, judgment, consequences, exceptions, and current controls. Then allocate each step among human work, deterministic automation, AI assistance, and bounded agentic execution.

Anthropic draws a useful architectural distinction. Workflows follow predefined code paths; agents dynamically direct their own processes and tool use. Its guidance recommends the simplest architecture that meets the need because greater autonomy trades predictability for flexibility, cost, and additional opportunities for error.[2]

That distinction matters. A fixed eligibility rule may belong in deterministic code. A recommendation may remain AI-assisted with a person retaining the decision. A negotiation, professional judgment, or materially consequential exception may remain human. Bounded autonomy is warranted only where the workflow genuinely requires adaptive multistep reasoning and tool use.

McKinsey, Bain, and Deloitte each emphasize that value at scale depends on redesigning work, data, architecture, and operating responsibilities—not merely inserting an agent into an existing step.[9][10][12] The workflow, not the model, is therefore the proper unit of design.

Value and Feasibility Qualify the Opportunity

Value must include more than gross labor savings. It should account for the business outcome, user impact, unit economics, verification, exception handling, rework, control, and the cost of failure.

Feasibility must include more than a model demonstration. It should cover capability, data quality, semantics, lineage, integration, latency, reliability, operating capacity, human review, vendor dependencies, security, and the ability to test the production path.

These questions are demanding. They should be. McKinsey reports that agent experimentation is widespread while scaled tangible value remains limited, with data constraints a frequent obstacle.[9] Deloitte’s 2026 research likewise found that process, data, integration, and governance readiness lag adoption intent.[12]

The qualification decision has two outcomes. If value or feasibility is inadequate, the disposition is Do not pursue: stop the agentic initiative, retain a simpler operating mode, or revisit the workflow only when conditions materially change. If both are established, the workflow becomes an agentic candidate.

The candidate has earned architecture work, not authority. Expected ROI cannot compensate for an undefined permission boundary. Technical readiness cannot compensate for an irreversible action that has no enforceable stop. A pilot success rate cannot compensate for evidence that ends at the agent trace while the real consequence occurs in another system.

This is why assurance cannot be blended into a composite score. A high-value opportunity with inadequate authority, consequence control, or evidence is not “mostly ready.” It is not authorized to proceed.

Autonomy Changes the Control Problem

An agent does more than generate an answer. It may select tools, construct arguments, call multiple systems, interpret intermediate results, alter its path, and persist until it reaches an outcome.

Anthropic describes the deployed agent as a combination of model, harness, tools, and environment, each of which creates both capability and an oversight point.[3] OpenAI provides corresponding application primitives: function tools, guardrails, approvals, MCP integrations, platform permissions, traces, and evaluations.[4][5][6][7][8]

Those primitives are real and useful. The Governed Workflow Blueprint determines where they fit, what enterprise controls must surround them, and what they cannot establish by themselves.

Strict function schemas can make tool arguments conform to a defined shape. They do not establish that the proposed action is permitted.[5] OpenAI platform roles can constrain access to OpenAI organization and project resources. They do not govern every customer database, payment system, mailbox, or production application.[6] MCP configurations can restrict tools and require approvals, while OAuth registration and downstream authorization remain application responsibilities.[7]

Guardrail placement also changes the result. OpenAI documents that blocking checks can run before agent execution, while parallel checks may allow tokens or tool activity before cancellation. Tool guardrails apply around specified function-tool calls, and other tool surfaces can follow different execution pipelines.[4]

The lesson is not that a provider should supply one universal control plane. It is that the enterprise must compose platform controls with its own identity, policy, downstream authorization, action controls, evidence, and operating ownership.

Capability is not authority.

Assurance Is a Mandatory Gate

The assurance decision has three independent obligations. It is non-compensating: weakness in one obligation cannot be offset by strength in another.

Explore the interactive visual

Luminity architectural interpretation informed by first-party OpenAI and Anthropic evidence, Tier 1 institutional research, NIST guidance, and academic research. Not a certification, compliance opinion, provider authorization, or universal assurance claim.

Bounded Authority

The enterprise must know which actor is operating, who delegated authority, for what purpose, on whose behalf, against which subjects and resources, using which data, tools, operations, and paths, within which thresholds and time window.

This is more than broad access. NIST’s 2026 agent identity work highlights identification, authorization, auditing, non-repudiation, credential management, and delegated access as active design concerns. It recommends treating agents as distinct entities with scoped entitlements rather than allowing them to inherit a person’s reusable credentials.[13]

For Luminity, these conditions form the Authority Envelope. The envelope binds the agent to purpose, subject, resources, tools, path, thresholds, time, delegation limits, and revocation. It should be evaluated against current workflow state immediately before a consequential action.

BCG describes a related authorization gap: agents can operate across systems in ways that fit neither traditional human controls nor fixed application permissions. Its purpose- and conduct-bound framing reinforces the need to govern both the approved task and the permitted path.[11]

Governed Consequence

An instruction is not enforcement. A policy statement becomes a control only when the execution path can prevent, limit, pause, or redirect an action before the consequence occurs.

OpenAI’s human-review guidance supports pausing before side effects such as cancellations, edits, shell commands, or sensitive MCP actions.[4] That approval is useful only when the reviewer sees the exact action, target, data scope, likely effect, policy result, and alternatives—and has both authority and a practical ability to refuse.

Human review is not the only answer. For rules that cannot tolerate interpretive error, the architecture may require deterministic eligibility checks, exact resource scope, downstream authorization, transaction limits, separation of duties, idempotency, or fail-closed behavior. A 2026 preprint evaluating solver-aided tool policy checks found that intercepting proposed tool calls before execution reduced policy violations in its test setting.[16] That result is promising but bounded: formal enforcement covers only the policies correctly represented and the paths actually instrumented.

Consequence and reversibility should determine the control mix. A reversible internal draft is not the same as a payment, record deletion, access grant, external communication, or decision affecting a person’s rights. Where an effect cannot be reliably reversed, prevention and narrow authority matter more than post-event detection.

Defensible Evidence

OpenAI traces can record model calls, tool calls, guardrails, handoffs, and related events. Agent evaluations can grade those traces and identify regressions.[8] These capabilities are valuable evidence inputs. They are not the complete evidence system.

The enterprise record must also bind intent, identity, delegated authority, policy version, data and resource scope, proposed action, deterministic checks, human decision, downstream authorization, actual system response, resulting state, exception, retry, reconciliation, and final disposition.

That last distinction is critical. A trace may show what the agent attempted. Reconciliation shows what the system of effect actually did.

Academic research makes the evaluation limit visible. AI Agents That Matter documents cost, holdout, reproducibility, and overfitting problems in agent benchmarks.[14] Tau-bench evaluates resulting database state and repeated-trial reliability rather than accepting a plausible conversation as success.[15] AgentDojo shows that tool-using agents remain exposed to prompt injection through untrusted data and that failures can occur even without an attack.[17]

No single score, trace, approval, or monitor closes the case. Defensible evidence is a joined record sufficient to reconstruct what was intended, authorized, decided, attempted, executed, observed, and resolved.

The Governed Workflow Blueprint

The Governed Workflow Blueprint turns these obligations into an inspectable architecture, acceptance record, and operating contract. Its complete ten-part record is organized into four decision layers:

• Workflow baseline — identity, purpose, owners, current state, failure paths, and allocation among human, deterministic, assistive, and bounded agentic work.
• Qualification — value, feasibility, measurement, operating cost, dependencies, and explicit stop thresholds.
• Assurance architecture — the Authority Envelope, consequential-action controls, evidence obligations, evaluation, and acceptance criteria.
• Operating authority — approved scope, residual risk, accountable sign-off, monitoring, change triggers, suspension, retirement, and reauthorization.

The relationship is explicit:

Value and feasibility remain the upstream qualification. The assurance decision applies only to a qualified candidate and produces one of two initial outcomes.

May proceed means all three obligations are supported by evidence against scope-specific acceptance criteria; unresolved exceptions and residual risk are recorded; and the accountable decision authority signs the versioned Blueprint for the approved scope.

Redesign required means value and feasibility may remain positive, but an authority, consequence, or evidence condition is incomplete.

After authorization, Reauthorization required is the lifecycle disposition when material change, drift, incident, or operating evidence invalidates the prior decision. Consequential action pauses until the designated authority records a new decision.

The Blueprint is not a certification, compliance opinion, or universal checklist. It must be tailored to the workflow, consequence, jurisdiction, industry, provider, and systems involved.

Evidence Informs Authority. It Does Not Become Authority.

Production evidence should improve the enterprise’s decision. It should never expand autonomy automatically.

Anthropic’s analysis of millions of agent interactions found that experienced users auto-approved more often while also interrupting more often, and that agent-initiated requests for clarification were an important form of oversight.[18] The finding is not a universal law, but it reinforces a practical point: autonomy and supervision change in use. A launch approval cannot stand indefinitely without reference to actual behavior and changing conditions.

The operating loop is therefore deliberate:

Observe. Reconcile. Reauthorize.

Evidence may justify maintaining the existing envelope. It may require contracting authority, redesigning a control, suspending the workflow, or retiring it. Expansion requires a new decision with a new scope and supporting evidence.

That is Assurance by Architecture: not a promise that the system cannot fail, but a defensible structure for deciding where it may act, controlling the consequences, and knowing when the decision must be revisited.