Walmart architect urges stronger foundations for AI agents

InfoQ published the QCon AI presentation June 17, 2026, in which Aditya Kumarakrishnan warned that teams repeat older agent mistakes as they chase LLM features.

Kumarakrishnan, a technical fellow at Walmart Global Tech, framed the current agent wave as an amnesia phase. He said teams forget decades of work in agents, process science, workflow systems and environment design. His prescription gives engineering leaders a test: build agents on abstractions that can survive model churn, tool churn and enterprise scale.

The talk offered no product pricing change. Kumarakrishnan focused on architecture and integration patterns across Model Context Protocol, CoALA, DSPy, Camunda BPMN and Temporal. Those names matter because they anchor agent design in systems that teams can inspect, extend and operate.

A broader agent model

Kumarakrishnan urged teams to treat agents as a computing abstraction. An agent senses an environment, chooses an action and acts for a user. That definition covers more than an LLM loop with tools.

This shift changes the design conversation. A team starts with the job the agent must perform, then chooses the architecture. Some agents need an LLM. Some need a workflow engine, a rules layer or a narrow automation wrapper. The point is scope: teams should avoid baking the current LLM interface into the core model for every agent.

Anthropic engineers describe agent loops in Building Effective Agents: a model observes context, calls tools, reads results and continues. Kumarakrishnan accepted that pattern for AI agents, then pushed for a wider frame. He wants engineers to see the LLM as one component inside a compound system.

That view fits enterprise software. A procurement agent may ask an LLM to interpret a request, but a workflow engine should handle retries, approvals and audit records. A checkout agent may use model reasoning for plan selection, while product, account and payment services enforce policy.

Modules before rewrites

Kumarakrishnan argued that agent frameworks often force teams into rewrites as patterns change. Teams moved from chain-of-thought prompting to ReAct, reflection and CodeAct patterns. Many teams rebuilt agents each time because they encoded reasoning, memory and tool use into one tangled prompt flow.

The researchers behind CoALA offer a cleaner split. They describe agents through memory modules, action spaces and decision processes. Kumarakrishnan said Walmart teams use that model to separate procedural memory, external memory, tool calling and LLM reasoning.

That separation gives teams a migration path. A ReAct agent may use JSON tool calls as its action space. A CodeAct agent may use a code sandbox. If engineers isolate the action module, they can swap the action space without rewriting memory, policy and evaluation code.

DSPy gives teams another route into modular compound AI systems. Developers define modules with signatures, compose them and optimize prompts or model calls against examples. Kumarakrishnan mentioned DSPy as a programming model that fits the same goal: agents should have parts that teams can test and replace.

Process science returns

Kumarakrishnan made his strongest enterprise case around process science. Businesses create value through processes: purchase orders, returns, merchandising changes, incident response and finance approvals. Agents that cannot execute processes at scale will stay trapped in demos.

Process science gives teams three useful building blocks. Teams can encode procedural memory, run work through workflow engines and mine process maps from event logs. Each one addresses a problem agent teams keep rebuilding.

Procedural memory tells an agent how to perform a task. In human teams, that knowledge lives in runbooks, flow diagrams, scripts and employee habits. In agent systems, that knowledge can live in skills, process definitions and domain workflows.

Workflow engines handle long-running work. Developers use Camunda with BPMN when they want a standard process language with execution semantics. Developers use Temporal when they want durable execution from code in languages such as Java, Go or Python.

BPMN also gives agent builders a useful primitive: the ad hoc subprocess. A designer can define a set of tasks without fixing the order in advance. An LLM can choose among those tasks at runtime, while the workflow engine handles state, retries and visibility.

That pattern resembles tool use in many agent systems. A designer gives an agent access to several tools. The model chooses the sequence. The difference comes from the runtime. A workflow engine can preserve completed work after a failure, pause for a human approval and expose execution history.

Process mining adds another step before automation. A team can collect event logs from systems and users, then infer the process that the business runs today. Kumarakrishnan said enterprises need that discovery step before they hand work to agents. An agent cannot enact a process that the organization has never mapped.

Artifacts around MCP

Kumarakrishnan also argued for environment design. Many teams wrap existing REST APIs with MCP tools and call the job done. MCP gives agents a common interface to tools and context. It does not define governance, audit, arbitration or domain semantics for the services behind those tools.

He proposed artifacts as first-class environment entities for agents. A boundary artifact can sit between agents and domain services. It can expose a higher-level command, enforce policy and record each request in an event stream.

A purchase order artifact gives a concrete example. An agent asks the artifact to create a purchase order. The artifact records the request, checks policy, coordinates downstream services and preserves an audit trail. A procurement team can enforce department limits, revoke access for a given agent or review past requests from one place.

Kumarakrishnan separated artifacts from tools. A tool exposes a function an agent can call. An artifact represents part of the environment. Teams can wrap an artifact with MCP, but the artifact carries the domain rule, state and control point.

He described three artifact types. Boundary artifacts govern access to domain capabilities. Resource artifacts mediate access to databases and other shared systems. Coordination artifacts give agents shared state for collaboration.

This design responds to what Kumarakrishnan called hyper-tenancy. Enterprises built many services for a small number of trusted integrations. Agent systems may create thousands of callers with cross-functional goals. A shopping agent can touch search, product detail, account and checkout paths in one task. A human employee might launch several agents that touch the same records.

Boundary artifacts let platform teams absorb that pressure without forcing each domain service team to redesign every API. The service team keeps its domain model. The artifact layer adds agent-facing semantics, audit records and policy hooks.

Use cases

Kumarakrishnan tied the architecture to enterprise work, not chat demos. Procurement gives the clearest example. A purchasing agent needs procedural memory for the buying process, process mining to learn current edge cases and an artifact layer to govern purchase order creation.

Incident response offers another fit. An agent may gather metrics, open tickets, query logs and propose a mitigation. A workflow engine can preserve state across long investigations. A boundary artifact can control access to deploy actions and record each step.

Customer commerce also fits the model. A personal shopper agent needs product search, inventory, profile and checkout access. Teams can avoid flat tool sprawl by exposing higher-level artifacts such as cart, order and account workspaces.

Software engineering agents can use the same pattern. MCP can expose repositories and issue trackers. A workflow engine can manage review, test and merge gates. A coordination artifact can hold shared plan state for several agents that work on one project.

Trade-offs

Kumarakrishnan's approach asks teams to invest before the demo looks impressive. Engineers must define module boundaries, map processes and build artifacts around services. That cost can feel heavy beside a tool wrapper and a prompt.

The payoff comes at scale. Modular agents reduce rewrites as model patterns change. Workflow engines give operators state, retries and inspection. Artifacts give security teams a place to enforce policy across many agent callers.

Teams still face design choices. BPMN gives a standard language and flexible primitives, but developers must learn its modeling style. Temporal lets developers write workflows in code, but teams must build agent-specific flexibility on top.

MCP remains useful in this architecture. It gives LLMs a common way to discover and invoke capabilities. Kumarakrishnan's warning targets the layer underneath: teams need domain artifacts, not thin wrappers around fragile service calls.

The talk lands as agent platforms move from prototypes into business systems. Engineering leaders now need more than better prompts. They need agent architectures that survive new model releases, execute business processes and give operators control over cross-functional automation.