From Business Strategy to AI Agents

The way people talk about building AI agents makes it sound easy. Come up with an idea and AI will do the rest. When I first began experimenting with AI tools, I had plenty of ideas and started building. It was impressive how quickly I could create an agent or website, but many of those experiments did not produce a meaningful productivity result. I had built something; I had not necessarily solved a problem.

Is Deploying AI the Goal?

Organizations can fall into the same trap. When deploying AI becomes a measure of success in itself, teams feel pressure to create solutions before defining the work those solutions should improve. The challenge is moving from a measurable business outcome, identifying an appropriate architecture with governance, and applying the LLM to areas that will drive value. Developing the agent is the last of those steps.

The L0–L2 framework below is a practical way to structure that discussion. These are the labels used in this article, not a claim that L0–L2 is a universal industry or SAP methodology.

Demand for AI Is Not a Business Requirement

Companies want to demonstrate that they are using AI, and ideas are emerging across nearly every business function. That enthusiasm can be useful, but it also creates pressure to automate processes that may already be handled more effectively through existing software, APIs, decision rules, and workflow engines. The first question should not be “Where can we put an agent?” It should be “What business problem requires a different way of working?”

A process may justify some AI capability when it has one or more of these characteristics:

• Unstructured inputs: Employees submit free-text descriptions, documents, emails, or requests that require interpretation.
• Context-dependent judgments: A useful recommendation requires combining records, policies, supplier information, or other sources.
• Unpredictable exceptions: The organization cannot economically represent every case as a maintained decision tree.
• Adaptive execution: The next investigative step depends on what the system discovers, rather than a fixed sequence of actions.
• Measurable manual effort: People spend substantial time researching, clarifying, categorizing, or investigating requests.
• Positive business economics: The expected benefit outweighs implementation, inference, maintenance, controls, latency, and error costs.

These conditions qualify a use case for further assessment, not automatic deployment of an autonomous agent. A single language-model call may be enough to classify a requisition. A deterministic workflow may then route it. A true agent becomes more relevant when the system needs to plan subsequent steps, select among tools, interpret their results, and adapt within established boundaries. Anthropic distinguishes predefined workflows from agents that dynamically manage their own processes and tool use.²

This distinction matters because complexity has a cost. Gartner predicted in June 2025 that more than 40% of agentic AI projects would be canceled by the end of 2027 because of escalating costs, unclear business value, or inadequate risk controls.¹ This alone should be enough to make anyone want greater discipline before implementation. Building AI solutions can be costly, and this can reduce the cost and prove that the cost is being applied meaningfully.

L0: Begin with the Business Outcome

A business outcome is a measurable improvement in procurement performance that delivers organizational value through lower costs, shorter cycle times, reduced risk, better compliance, or more effective operations. Implementing an AI agent is one possible means of achieving an outcome.

Consider ad hoc requisitions. Employees submit requests that need manual clarification, supplier investigation, category assignment, and approval routing. Before discussing agents, procurement should establish a baseline: how many requests are processed, how much time each requires, which steps cause rework, and what that activity costs.

Illustrative L0 value assessment

• Annual ad hoc requisitions: 20,000
• Average manual review time: 25 minutes per requisition
• Target reduction in manual review: 40% (10 minutes saved per requisition)
• Estimated time capacity released: 3,333 hours per year
• Illustrative loaded labor rate: $60 per hour
• Gross annual capacity value: $200,000 before solution costs

Capacity released is not automatically cash saved; the business case must account for whether the time can be redeployed, whether other costs decline, and what it will cost to operate the solution.

A credible L0 decision therefore identifies the baseline, a measurable target, the required investment, expected adoption, and the controls that must remain intact. If an existing workflow enhancement can achieve the same result at lower cost and risk, that may be the better answer.

L1: Design Capabilities, Boundaries, and Governance Before Choosing Tools

Once the use case has passed its value assessment, the next step is to evaluate the IT infrastructure, architecture, and security requirements needed to support it. What architecture, tools, skills, and capabilities are required to meet the business need? Where is the information located? How will the solution access it? Which systems remain authoritative for decisions and transactions?

Large document repositories may require indexing, filtering, chunking, and retrieval rather than placing all available material into a model context. Structured requisition and supplier data may instead be available through established interfaces. Existing business controls should be reused rather than reproduced in model instructions.

Depending on the use case, the architecture blueprint may include:

• Enterprise integration: Approved OData or REST interfaces, supplier master records, budget services, and procurement workflows.
• Retrieval and grounding: Search over policies, contracts, and other documents with provenance and access controls.
• Context and data preparation: Metadata filtering, indexing, document processing, and data-quality checks.
• Governance: Identity, permissions, audit trails, supplier eligibility, and human authorization thresholds.
• Operational design: Observability, failure handling, performance expectations, evaluation criteria, and cost limits.

For an ad hoc purchasing scenario, the agent may identify a plausible supplier or recommend a category. The procurement platform and its configured policies must still determine whether a supplier is eligible, whether a budget is available, and which approvals are required. An AI recommendation must not become a shortcut around authorization.

Not every agent needs the same combination of capabilities. Nevertheless, organizations should standardize reusable services such as identity management, connectors, retrieval, monitoring, and approval controls wherever practical. The L1 deliverable is an AI Use Case Architecture Blueprint: a description of required data, integrations, interfaces, security boundaries, controls, and operational criteria, together with a clear decision about whether an agent is necessary.

L2: Put the Agent Inside a Controlled Workflow

Imagine a Renaissance engineer working 500 years ago. The engineer could reason, test ideas, and solve mechanical problems, but lacked the accumulated standards, computing tools, and shared technical infrastructure available today. A modern engineer can accomplish more partly because of the environment in which that ability is applied.

A similar principle applies to a large language model. On its own, a model may interpret information and generate recommendations. To act in a business process, however, it needs a structured environment that provides access to the right information and approved operations. This brings us to a term that appears increasingly often in agent development: the agent harness.

The agent harness is the surrounding software that allows the model to retrieve context, choose or invoke tools, process results, and continue through an execution loop under defined limits. The model supplies language-based reasoning; the harness connects that reasoning to operations and supplies the safeguards around them. A harness is not a replacement for enterprise architecture: it implements capabilities and boundaries established in L1.

In practical terms, L2 builds and tests:

• Model configuration and instructions, including structured outputs and evaluation cases.
• Tool interfaces to approved enterprise APIs, databases, search services, or MCP servers.
• Context retrieval and state management, including policy grounding and source traceability.
• Orchestration, retries, stop conditions, escalation, and error handling.
• Permission checks, human approval checkpoints, validated write operations, and audit logs.
• Testing and observability for accuracy, task completion, latency, cost, and policy compliance.

An effective harness uses AI where interpretation or flexible investigation is needed and deterministic services for predictable calculations, rule evaluation, transactions, and enforcement. Production readiness should depend on explicit testing and measurable exit criteria rather than the fact that a prototype appears to work.³

Procurement Use Case: Ad Hoc Purchasing

Ad hoc purchasing illustrates the distinction between AI assistance and conventional procurement automation. Unlike catalog buying, ad hoc requisitions often start with incomplete product specifications or free-text requests. Procurement must clarify the need, assess approved suppliers, compare pricing, identify sourcing requirements, and determine the appropriate route to purchase.

Consider an employee requesting specialized maintenance equipment with a vague title and brief description. An agent could interpret the intended equipment category, ask for missing specifications, inspect approved supplier records, and compare permitted supplier and pricing information. Where internal sources are insufficient, approved external research could help prepare a supplier shortlist or RFx package. Any public price would be treated as indicative until confirmed through the sourcing process.

The next stage should be deliberately hybrid. A deterministic service checks supplier status, budget availability, category restrictions, contract requirements, and approval thresholds. When those checks return an exception, the agent can investigate the cause, explain it in business language, and suggest a correction or request additional information. A requester or buyer reviews changes that require human judgment. Authorized APIs can then update eligible requisition fields and resubmit the request, after which the procurement system recalculates the applicable approval route.

That design could reduce unnecessary rounds of clarification and rework. It does not authorize the agent to waive procurement rules or decide independently that an approval is unnecessary. Any simplification of the approval chain must follow approved process and policy changes. The objective is to get a more complete, policy-aligned requisition to the right approvers the first time.

What success would look like

Measure the result against the L0 baseline: requisition cycle time, manual review minutes, number of return-and-resubmit cycles, first-pass completeness, approved-supplier utilization, error rate, and purchasing compliance. Compare those benefits with inference, integration, monitoring, support, and change-management costs. A reduction in manual touches that increases rework or audit risk is not a successful outcome.

Measure Outcomes, Not Agent Count

The ability to build agents has advanced rapidly, but building an agent and delivering a sustainable business solution are different accomplishments. My earliest experiments taught me that a working demonstration is not the same thing as a useful product. Enterprise initiatives deserve the same scrutiny.

The ad hoc procurement example shows why the answer is rarely “make everything agentic.” Interpretation, supplier research, and exception investigation may benefit from AI. Budgets, purchasing policies, authorized changes, and approval routing still need reliable systems of record. L0 establishes why the investment matters; L1 determines what is required and what must remain controlled; L2 puts those capabilities into operation.

Success is not the number of agents released. It is whether requisitions move faster, procurement professionals spend less time on avoidable work, the economics make sense, and compliance remains intact. One agent that addresses a persistent operational bottleneck can be worth more than dozens of impressive demonstrations.

What Comes Next: Inside the Agent Harness

That leaves the practical architecture questions. How does a harness decide which tools are available? How does it retrieve authoritative procurement data, recover from failed API calls, preserve context, or stop an action that requires human approval? In a follow-up article, I will examine how these components fit together and how they can be designed for reliable enterprise operation.