The agent finds the procurement policy in seconds. But does it apply to this entity? Can the requester authorize the exception? Has the transaction changed? Which system holds the current record? A convincing demonstration becomes a business implementation when these questions need dependable answers.
For generative AI assistants and agents working across business processes, scaling requires connecting what the organization knows, how it operates and who has authority to act. That context helps an agent identify an appropriate next step. Enforced controls determine what it may actually do, and recorded evidence makes the resulting action reviewable.
Why the pilot works, but expansion exposes gaps
An experienced employee often supplies context without thinking about it: which entity owns the request, which policy takes precedence and who handles an unusual case. A pilot supported by that employee may appear more self-sufficient than it is. When another team adopts the agent, those assumptions can disappear.
Consider a procurement agent asked to prepare a supplier exception for approval. The group policy is relevant, but a local requirement may add a review. The transaction may already have been amended. The named approver may hold authority for a different entity. Finding a document does not establish that its rules apply to this request.
A supplier exception crosses the same decision points, but the applicable context changes.
| Decision context | Business unit A | Business unit B |
|---|---|---|
| Policy | Group procurement policy | Group policy + local requirements |
| Authority | Delegated procurement approver | Local authority and escalation route |
| Review | Standard exception review | Additional specialist review |
| Evidence | Shared procurement system | Entity procurement system |
Identify the operating context before recommending the approval route.
Source: DNA. Illustrative procurement scenario; not a client case study.
Context is one part of the scaling challenge. Workflow design, engineering, leadership and adoption also matter. McKinsey’s research associates AI value with workflow redesign and implementation practices; it does not establish missing context as the single cause of stalled pilots. McKinsey research.
Connect the operating model behind the decision
A document repository can supply information. A connected operating model establishes how that information relates to the work: the process being followed, the policy governing it, the authority required and the systems holding the relevant facts. Context engineering then selects the information an AI application needs for the task. More context is not automatically better. Anthropic’s context-engineering guidance.
Connect the rules, authority and current facts behind one request.
supplier exception?
Locate the request in the workflow.
Identify the current, applicable rules.
Establish the approver and limits.
Identify reviews and safeguards.
Connect approved sources and current system records.
Connected context informs the next step. Application controls enforce what the agent may access and do.
Source: DNA. Illustrative framework.
The relevant relationships extend beyond procurement. Customer journeys help define the service outcome and impact on the customer. Strategy provides agreed objectives. Infrastructure and continuity arrangements identify dependencies and fallback procedures. Each workflow needs an appropriate subset, not the entire enterprise model in every request.
Through MOSAIC, DNA connects and digitizes these operating-model relationships. Policies, processes, decision rights, systems and governed information become a business foundation for AI-enabled work. The organization can begin with one workflow and extend the model as further uses justify it.
Each relationship needs clear scope, ownership and effective dates. A proposed Target Operating Model must remain distinguishable from today’s approved operating arrangements. Future roles and approval limits should not be treated as current authority.
| Layer | Question it answers | Implementation requirement |
|---|---|---|
| Business context | Which rules and relationships apply? | Approved sources, definitions, authority and accountable owners. |
| Context delivered to the agent | What does this task require now? | Relevant information, current transaction facts and access filtering. |
| Controlled operation | What may the agent actually do? | Enforced permissions, approvals, validation and action records. |
The agent needs access to current facts as well as standing rules. Integration must establish the transaction state and recheck relevant conditions before an action. Authorization belongs in the application and downstream systems, not solely in a model’s interpretation of a policy. Microsoft architecture guidance, OWASP guidance on excessive agency.
Follow one request from context to controlled action
For the supplier exception, define the agent’s role first. It might identify the applicable procedure, assemble supporting evidence and prepare an approval request. Authority to approve the exception is a separate permission, not a consequence of being able to prepare it.
| Step | What the implementation must establish |
|---|---|
| 1. Establish the situation | Identify the user, entity, request and current transaction status. |
| 2. Apply the rules | Select effective policies, required reviews and the relevant authority conditions. |
| 3. Determine the next step | Prepare the request or escalate missing information and conflicting rules. |
| 4. Enforce the boundary | Validate permissions and obtain required approval before any authorized system action. |
| 5. Record the outcome | Retain the supporting sources, approvals, action and result for review. |
If two authority records conflict, the agent should route the issue to the responsible owner rather than invent a resolution. If it cannot establish a fact needed for a consequential action, the workflow should pause or seek clarification. The appropriate response must be designed and tested for the use case.
Business documents must also be treated as information, not instructions with authority to redirect the agent. Retrieved content can contain malicious instructions, and access restrictions can be lost during ingestion or retrieval. Source governance therefore needs security controls across the information pipeline. OWASP RAG security guidance.
Make decisions and actions reviewable
A citation shows where an answer points. A useful action record shows the business facts considered, the sources and versions used, applicable authority, approvals obtained, action taken and outcome. These records need appropriate access and retention controls because they can themselves contain sensitive information.
This is operational traceability, not a transcript of the model’s internal reasoning. It enables an accountable reviewer to investigate what happened and assess whether the action was appropriate. It does not, by itself, prove the decision was correct or compliant.
Test that distinction with realistic cases: another entity, a replaced policy, conflicting approval records, restricted information and an instruction hidden inside a retrieved document. Check which sources were used and which actions occurred. A fluent explanation cannot substitute for a correct outcome. Anthropic’s evaluation guidance.
Build a repeatable capability, one workflow at a time
These responsibilities overlap. Revisit the evidence whenever the workflow, rules or systems change.
Prove
One valuable workflow
- Deliverable
- A bounded use case and performance baseline.
Routine and exception cases meet agreed criteria; benefit measured.
Govern
Trusted context
- Deliverable
- Approved relationships, ownership and exception tests.
Permissions verified, source updates tested and incident ownership assigned.
Extend
Another entity or team
- Deliverable
- Common context reused; local differences made explicit.
Local tests, adoption support and operating capacity justify rollout.
Source: DNA. Illustrative framework.
Begin with a named business owner, a defined role for the agent and a baseline for the workflow. Measure preparation time, incorrect routing, rework and review effort. Connect the minimum required context, resolve ownership gaps and agree the integration and permission requirements with technology teams.
Before expanding, test representative cases and consequential exceptions against agreed acceptance criteria. Reuse approved common context while governing local differences. For GCC implementations, include the relevant entities and working languages in testing rather than assuming a successful result transfers unchanged.
After rollout, track errors, escalations, human overrides and the cost of completed work. Retest when policies, models, sources or integrations change. Assign incident ownership and a way to suspend problematic actions. NIST treats AI risk management as a lifecycle responsibility, including testing and incident handling. NIST Generative AI Profile.
What must be true before you expand
Use the assessment below to examine one workflow’s context foundation. It supports a discussion about evidence and gaps. It does not replace deployment reviews covering security, privacy, reliability, applicable obligations and meaningful human oversight. Acceptance criteria should reflect the consequences of the use case, not a universal accuracy percentage.
Before expanding, make the evidence visible.
Assess one AI workflow with its business and technology owners. Read the evidence prompts, then choose a status for each criterion, including “Not assessed” where evidence is missing.
- Established
- We have evidence this works in this workflow.
- Needs work
- We know there is a gap or inconsistent performance.
- Not assessed
- We have not checked, or cannot yet provide evidence.
Uses the right business rules
Does the AI identify the relevant business unit and use its currently approved policies and approval limits?
Ask the same question for two entities with different rules. Check that each answer uses the correct entity, policy version and effective date.
Makes decisions and actions traceable
Can a reviewer trace a recommendation or action to current facts, approved sources and any required approvals?
Review one completed case. Check the source versions, transaction facts, approvals and resulting action. Confirm that the evidence supports the conclusion, not just that a citation exists.
Stays within its authority
Can the AI access only permitted information and perform only authorized actions?
Test restricted requests using different user roles. Confirm that access is blocked where required and that human approvals cannot be bypassed.
Handles uncertainty appropriately
When information is missing, contradictory or outdated, does the AI clarify or escalate rather than assume?
Introduce conflicting policies, expired records, missing details and instructions hidden in a retrieved document. Check whether the AI stops, asks the right question or routes the issue to an accountable person.
Has an accountable owner
Is someone responsible for maintaining the context, approving changes and responding to problems?
Walk through a recent or simulated policy change. Confirm who updates the context, approves it, retests affected responses and supports users.
Delivers measurable business value
Does the workflow improve after human review, corrections, maintenance and technology costs are included?
Compare the workflow with its baseline using turnaround time, rework and cost per completed task. Include the effort required to review and correct AI output.
The business case must also survive the full cost of operation. Time saved in preparation may be offset by correction, review or maintenance. Expand when measured benefits, remaining risks and support capacity justify it, and keep checking those assumptions as adoption grows.
Where does your AI workflow lose business context?
The work crosses organizational boundaries. Technology teams need approved rules and clear business authority. Business owners need working integrations and controls. Someone must connect these responsibilities and embed a way to maintain them.
DNA helps implement that foundation through process and policy management, delegated authority, data and knowledge governance, enterprise architecture, risk and controls, and operational excellence. Through MOSAIC, we connect the operating-model relationships behind the workflow and work with business and technology teams to make that context usable and maintainable.
The tangible outputs are a defined decision boundary, a connected context model, accountable source owners, requirements for integration and controls, agreed acceptance tests and a sustainable operating model for support and improvement. The scope is shaped around the workflow and the organization’s existing capabilities.
Bring DNA one workflow you want to scale. Together, we can identify the relationships, decision rights and implementation gaps that need to be addressed.
Evidence note: Reviewed September 2026. The linked sources support the technical and governance principles discussed. The procurement examples and exhibits are illustrative DNA frameworks, not client results or independent validation of MOSAIC. This guide focuses on generative AI assistants and agents in business workflows.