AI as a procurement line item, not an innovation budget

AI spend has graduated from "experiment" to "category." It now sits alongside cloud, observability, and identity in the enterprise stack, with its own approval workflows, vendor evaluations, and renewal cycles. The shift matters because it changes who decides: finance, legal, and security are now in the room before engineering picks a vendor.

The practical implications:

• Multi-year contracts and committed-usage discounts require the same scenario planning as cloud commitments: teams should compare forecasted demand, minimum spend, and a model-provider exit path.
• Internal chargeback makes inference costs visible to the business unit that consumes them, rather than treating token use as an unbounded shared-platform expense.
• Vendor consolidation should not remove portability. An enterprise can standardise on preferred providers while preserving an abstraction layer, a documented export path, and regression tests for alternative models.

Multi-agent orchestration moves into production

For multi-step workflows, enterprises are moving beyond single-prompt chatbots to coordinated agents that hand off tasks. A common pattern assigns planning to one agent, execution to task-specific agents, and output checks to a verifier before returning a result to the user.

What makes this viable is reliability engineering: agent-level tracing, typed tool contracts, idempotency keys, retry and compensation policies, and evaluation harnesses that catch regressions before they reach users. Teams commonly implement the orchestration layer in Python with frameworks such as LangGraph or direct model SDKs, then emit traces through OpenTelemetry to an observability platform.

• Planner / executor splits for complex workflows where one model decides the plan and cheaper models run the steps.
• Parallel agents for tasks that fan out (research across sources, batch document processing, multi-channel customer triage).
• Verifier agents that grade outputs against a rubric before they're shown to users or downstream systems.

The teams shipping multi-agent systems reliably treat orchestration as a software engineering problem: each agent receives least-privilege credentials, bounded tool access, an evaluation suite, and a defined fallback path.

MCP becomes the interop standard for tools and data

Anthropic’s Model Context Protocol (MCP) is becoming a common integration option for connecting AI clients to internal tools, databases, and SaaS systems. It does not remove the need for integration engineering: enterprises still need to define tool boundaries, identity propagation, data classification, and audit logging. Its practical value is a reusable interface between model clients and enterprise services.

Why teams choose MCP instead of bespoke plugin integrations:

• It's a protocol, not a marketplace. Enterprises can run MCP servers on their own infrastructure, behind their own auth, with their own audit logs. No vendor gatekeeping.
• Tool definitions are more portable. MCP standardises the interface, but client support, identity propagation, permissions, and tool semantics still need compatibility testing. This reduces, rather than eliminates, integration lock-in.
• It maps cleanly to existing security reviews. An MCP server is a service; security teams can review its threat model, permissions, logs, and service ownership.

For remote MCP servers, the current MCP authorisation specification uses OAuth 2.1 and requires protected-resource metadata. Treat each server as a production API: validate token audience, expose narrowly scoped tools, prevent prompt-driven privilege escalation, and record every state-changing call.

The emerging pattern is to build internal MCP servers for core systems—CRM, ticketing, and the data warehouse—and expose them to approved AI clients rather than committing all tool access to one vendor ecosystem.

AI governance and compliance as a procurement blocker

Legal, security, and risk now sit upstream of AI vendor selection, not downstream. The EU AI Act, NIST AI RMF, ISO/IEC 42001, and vendor questionnaires have moved governance from “we’ll figure it out post-purchase” to a hard gate. The European Commission’s current guidance confirms phased obligations through 2028; legal teams should assess the applicable role and use case rather than assume every requirement applies at once.

What this looks like in practice:

• Pre-purchase risk classification. Buyers categorise the intended use under EU AI Act risk tiers before issuing an RFP. High-risk use cases trigger documentation requirements that some vendors can't meet.
• Model and data lineage requirements. Procurement asks where training data came from, what the retention policy is, which model and prompt version produced a decision, and what audit logs the vendor will produce. “Trust us” is no longer an answer.
• Internal AI committees that review use cases before any spend is approved. These committees typically include legal, security, data governance, and a business sponsor; their default answer is "not yet."

The practical effect: buying cycles are longer, but the projects that survive them are more likely to make it to production.

Build-vs-buy reassessment driven by model commoditisation

As multiple providers offer strong general-purpose and reasoning models, the strategic question shifts. It is no longer “which model platform do we standardise on?” but “which parts of this stack should we own, and which should we rent?”

The factors enterprises are weighing:

• Reasoning models can change the math. For tasks with clear instructions and strong retrieval, a capable base model may remove the need for fine-tuning; domain-specific quality, latency, and unit cost still need testing.
• Switching costs are distributed. Standardised inference APIs and MCP can reduce provider coupling, but prompts, evaluations, safety controls, and orchestration code remain material migration costs.
• Fine-tuning remains a workload-specific choice. Compare a tuned model with retrieval-augmented and prompt-only baselines on a representative evaluation set, including quality, latency, and total cost.

The pattern: enterprises rent commodity model capability, own the orchestration and evaluation layer, and keep proprietary-data access behind their own security boundary. A portable architecture isolates provider SDKs behind an inference gateway, version-controls prompts and schemas, and validates model changes against a representative evaluation set.

Document extraction matures into production IDP

Document processing was an obvious early use case for LLMs, and it has matured. Multimodal models can complement OCR engines such as Amazon Textract, Azure AI Document Intelligence, and Google Document AI for structured PDFs, scanned forms, and mixed-content documents. The production question is no longer “can we extract this field?” but “can we run extraction at enterprise volume with validation, exception handling, and an audit trail?”

What's changed since 2024:

• OCR and multimodal extraction are selected per document type. A robust IDP pipeline classifies incoming files, uses OCR for layout and text extraction, then applies a multimodal model only where semantic interpretation adds value.
• Validation and human-in-the-loop steps are part of the pipeline. Production IDP is model plus confidence thresholds, JSON Schema or Pydantic validation, duplicate detection, and selective human review on low-confidence outputs.
• The integration question dominates. The model is rarely the bottleneck; getting validated data into systems of record—ERP, claims, or case management—with idempotent APIs and reconciliation is.

See intelligent document processing solutions for the production patterns that have settled out.

Retrieval moves from static RAG to agentic retrieval

RAG is a common enterprise pattern; the next design decision is how much retrieval logic to make adaptive. Static vector-database RAG, where every query embeds and searches the same index, can be extended with agentic retrieval: agents decide which tools to query, iterate on a search strategy, and combine structured systems, unstructured stores, and live APIs.

The shift in production retrieval:

• Tool-augmented retrieval. Agents call SQL, search APIs, vector stores such as pgvector or OpenSearch, and MCP-exposed services in the same workflow, choosing based on the question.
• Iterative refinement. Instead of a single retrieval pass, agents reformulate queries, expand or narrow scope, and verify results before generating an answer.
• Source attribution and access controls as first-class outputs. Production systems return citations by default and apply the requestor’s document-level permissions before retrieval; both are common procurement requirements.

Human-in-the-loop tightens around the high-risk steps

Human-in-the-loop is no longer a blanket policy ("a human checks every output"); it's a targeted intervention at the points where the cost of being wrong is highest. The teams running HITL well today instrument their pipelines, identify the low-confidence or high-impact decisions, and route only those to humans.

Two patterns have stabilised:

• Tuning and evaluation. Humans label, grade, and curate the eval set. The eval set, not the model, is the durable asset.
• In-production review on confidence triggers. The system itself decides when to escalate, based on calibrated confidence scores or business rules. Humans handle the long tail; the model handles the head.

Customer service agents need controlled action boundaries

Customer service is a high-volume use case for action-taking agents. A production system may issue refunds, update orders, or escalate cases, but every action needs a defined permission boundary, approval rule, and recovery path.

What this requires that 2024-era chatbots didn't:

• Real tool access through MCP or equivalent, with scoped permissions per agent.
• Reversibility and audit logs. Every action is logged with the tool input, approval state, and result so support leads can review and intervene. High-impact actions should require explicit approval or a compensating transaction.
• Confidence-based handoff. The agent handles tier-1 autonomously, escalates tier-2 with full context, and never pretends to be human.

The business case should be tested against a baseline: containment rate, transfer rate, resolution time, rework, customer-satisfaction score, and cost per resolved case. Auditability supports controlled expansion, but logging alone does not prove quality or ROI.

Agent orchestration becomes a platform-selection decision

The platform-versus-custom decision has replaced the earlier wave of isolated AI automations. Microsoft Power Platform and established RPA vendors remain suitable for deterministic processes; agent orchestration adds an execution layer for LLM-driven workflows across systems.

What enterprises are choosing between:

• Established automation platforms with bolted-on AI features. These are safe, well-governed, and limited to workflows the underlying engine can express.
• Agent orchestration platforms designed AI-first, with built-in tracing, evaluation, and tool registries. These are more flexible but newer, with less mature governance tooling.
• Custom orchestration on a model SDK. This is often appropriate for high-value workflows when a small Python or cloud-native team can meet requirements for identity, durable execution, evaluation, observability, and support.

The AI hire profile narrows to “ships agents in production”

Enterprise teams increasingly need engineers who can ship a production agent, write evaluation harnesses, and operate tracing, cost monitoring, prompt versioning, and incident response. These skills matter alongside, rather than instead of, backend, cloud, and data-engineering fundamentals.

How enterprises are responding:

• Upskilling existing senior engineers where the organisation already has strong backend, security, and platform practices. A senior backend engineer who learns the agent stack can own production integration work; model research may require a different profile.
• Project-based engagement with specialist firms for architecture-defining work—AWS landing zones, Python services, evaluation harnesses, and secure integrations—with internal teams owning steady-state operations.
• Tightening the JD. "Worked with LLMs" no longer differentiates a candidate; "shipped an agent system to production with evals and observability" does.

AI-native development tooling becomes a hiring filter

Workforce training has shifted from “everyone needs an AI awareness course” to a more pointed question: can engineers use AI-native tooling safely within the organisation’s SDLC? Claude Code, Cursor, and Copilot can accelerate selected tasks, but leaders should measure impact with cycle time, review rework, defect escape rate, and security findings—not assume a productivity gain.

The implications:

• Hiring signals have changed. Teams increasingly assess whether candidates can verify AI-assisted code, protect secrets, understand dependency risk, and work within review and testing controls.
• Internal tooling investment. Enterprises are standardising on a small set of AI-native development tools, defining data-handling rules, and building review patterns rather than letting every team select a tool independently.
• The training question is narrower. Teams don't need a generic "intro to AI" course; they need hands-on practice shipping with the tools the company has chosen.