From Hype to Strong Foundations: Building Agents That Outlast the Cycle

Most engineering content about AI agents is about context engineering, prompt tuning, or agent-to-agent protocols. Aditya Kumarakrishnan, a technical fellow at Walmart Global Tech, argues that this is the wrong layer to be obsessing over. His thesis is that the industry is in an "amnesia phase": we are building agents on shaky foundations, making meandering progress, and relearning lessons that previous generations of agent research already settled. The talk is part experience report from building agentic middleware at Walmart, part a tour of four older ideas — a stronger definition of agency, modular cognitive architectures, process science, and environment programming — that he believes will still be correct after the current hype cycle ends.

These notes report what the speaker presented. Where I add context that was not in the talk, it is labelled as such.

What You Will Learn

• Why defining an agent as "an LLM in a loop" quietly locks you into a specific implementation, and what a more durable definition looks like.
• How the CoALA cognitive architecture decomposes an agent into modules so that moving from ReAct to CodeAct becomes a component swap rather than a rewrite.
• What process science — procedural memory, workflow engines, and process mining — already knows about running long-lived, flexible processes.
• Why BPMN's ad hoc subprocess is arguably a formal specification of what most tool-calling agents do today, and what durability you get for free by using it.
• Why "hyper-tenancy" makes existing services a hostile environment for agents, and how boundary artifacts add governance, auditability, and arbitration.
• The distinction between MCP as syntax and artifacts as semantics.

Why the Idea of an Agent Keeps Coming Back

Kumarakrishnan describes himself as an "AI agent bull", but with a specific qualification: he thinks the concept of an agent is inevitable, not that any particular realization of it is. His argument for inevitability is historical. Agents were near the centre of computing from the start — he traces the thread back to Turing's conception of machines and to John McCarthy and the early AI pioneers, for whom agents were the central project of the field.

The history of AI, he says, is a story of peaks and valleys. Each peak brings renewed enthusiasm for building agents; each valley brings a catastrophic forgetting of everything learned during the previous peak. That forgetting is the problem the talk is trying to solve.

Borrowing a framing from Michael Wooldridge's Introduction to MultiAgent Systems, he identifies five long-running trends in computing that all converge on the agent concept:

An agent sits at the intersection of all five: you delegate a task to it, you talk to it in a human-oriented way, it is intelligent, it is potentially ubiquitous (everyone may have one, or many), and it must interconnect with other systems and agents. Business process, in his framing, sits at the intersection of delegation, human orientation, and interconnection — which is why process science reappears later as a load-bearing idea. Because those five trends are not going to reverse, the agent concept will keep resurfacing; it is simply hard enough to get right that we keep having to talk about it again.

Idea 1: Embrace a Stronger Notion of Agents

The first idea is conceptual: liberate the agent from the LLM. Treat "agent" as a general-purpose computing abstraction that puts the human at the centre, rather than as a synonym for a language model in a feedback loop.

The classical definition, from Russell & Norvig's Artificial Intelligence: A Modern Approach, is that an agent perceives its environment and acts upon it. The crucial part, Kumarakrishnan stresses, is that the agent decides what action to take and when to take it. Both Russell & Norvig and Yoav Shoham's 1990s work on Agent Oriented Programming treat agency as a modelling tool, not a taxonomy that partitions the world into agents and non-agents. He compares it to wave-particle duality: it is a way of interpreting a phenomenon, not an intrinsic property.

That immediately raises an objection: if you can model anything as an agent, what is the abstraction worth? Shoham's own example is that it is perfectly coherent to describe a light switch as an agent with beliefs and intentions acting on your behalf. Kumarakrishnan's answer is that coherence is not the test — necessity is. A light switch is fully described by a finite state automaton, a much simpler abstraction, so there is no reason to reach for a more complex one. The agent abstraction earns its place when systems become too complex for simpler models. A self-driving car or a personal shopper cannot be adequately described as a finite state automaton; those are the systems where the agent paradigm fits.

Where AI agents sit in the picture

He then situates today's "language agents" or "AI agents" inside that broader space. The popular definition comes from Anthropic's Building Effective Agents essay: an LLM running in a feedback loop with an environment, observing results and choosing the next action. He is explicit that this is a perfectly useful abstraction and genuinely is what an AI agent is. His point is about containment: there is the general idea of an agent, which may or may not need AI at all; there is the idea of a compound AI system, meaning a system of many interacting components of which an LLM may be one; and AI agents sit in the middle of those.

Two practical reasons he gives for adopting the broader definition:

1. It shifts you from implementation-oriented to problem-driven thinking. If an agent is by definition an LLM in a loop, you stop asking what problem needs solving and start asking how to arrange prompts.
2. It is future-proof. If your architecture is built on the general abstraction rather than on the specific LLM-in-a-loop pattern, a new paradigm does not force you to discard your work.

Idea 2: Build Modular and Extensible Agents

The second idea is the practical counterpart. Kumarakrishnan charts the past two-and-a-half years of agent architecture innovation as a series of punctuation marks:

• Chain of thought — cutting edge roughly two and a half years ago. You built an agent by adding a line to the prompt asking the model to explain its thinking before answering, and results improved noticeably.
• Reflection — the agent critiques and revises its own output.
• ReAct — the model emits structured output such as a tool call, which you then invoke, feeding the result back.
• CodeAct — "the new cool kid in town": rather than emitting JSON tool calls, the model writes code that is executed, which appears to work notably well.

His complaint is not with the progression but with how each step is implemented. Every one of these advances is treated as a bespoke web of context and prompt engineering. There is no modular path from chain of thought to reflection, from reflection to ReAct, or from ReAct to CodeAct. Each new architecture invents new concepts and new structures, so upgrading means scrapping the previous agent and rebuilding. He reports having had to do exactly this three or four times in his own career, and says toss-it-all rewrites are currently the norm when teams want better agents. The underlying diagnosis is that we do not have strong abstractions for agents; the symptoms are tight coupling, no migration path, and reinventing the wheel every cycle.

CoALA as a decomposition

The proposed remedy is a cognitive architecture — an agent decomposed into well-defined subcomponents rather than treated as a monolith. He points to the CoALA paper (Cognitive Architectures for Language Agents) as a concrete example and says this is how Walmart has started building agents, to the point that it has become their default way of thinking.

In this decomposition, the agent has distinct memory modules, distinct action spaces, and an LLM with a tightly scoped role rather than being the whole system. The LLM's specific role, in his framing, is the agent's implicit procedural memory: the knowledge of how to perform tasks, encoded implicitly in the model weights.

The payoff is the migration story he complained about earlier. The only meaningful difference between ReAct and CodeAct is the action space: ReAct uses a JSON tool-calling action space, CodeAct uses a code sandbox. If the action space is its own module behind a defined API, that evolution becomes swapping one component. CoALA's authors apply this analysis to several published architectures — ReAct, Voyager, Generative Agents, Tree of Thoughts — and show they reduce to a handful of permutations across a small set of fields, such as digital grounding versus agent grounding, or reasoning plus retrieval versus reasoning plus retrieval plus learning. Two organizational benefits follow: you can define clean APIs per module, and different teams can own different modules instead of one team owning a monolithic agent.

In the summary he adds DSPy as a second example of the same instinct — a programming model that treats an agent as a compound AI system with separate, independently optimizable modules. He notes Walmart is experimenting with both CoALA and DSPy and does not claim either is the final answer; the requirement is simply that an agent be built from subcomponents that can survive rapid change in models and architectures.

Idea 3: Learn From and Leverage Process Science

The third idea is the one Kumarakrishnan calls the most important, and the one he thinks is most missing from current discourse. Process science is a tradition roughly forty years old that provides rigorous grounding for processes. His argument for its relevance is economic: for agents to generate value in an enterprise or as personal assistants, they must enact multi-step, long-running processes that coordinate real work inside organizational and interpersonal complexity. That is exactly what process science studies, so reinventing it — the current trend — is wasteful.

He draws out three specific contributions.

Procedural memory

Procedural memory is an agent's memory of how to do task X. His human analogy is brushing your teeth: you do not reason from first principles each morning about the toothbrush, the toothpaste, and the sequence — it is muscle memory. Organizations hold enormous amounts of procedural memory locked up in flow diagrams, workflow engines, documented processes, and people's heads.

His notable observation here is that Claude skills are a rediscovery of procedural memory: a Markdown instruction file plus Python scripts telling an agent how to carry out a procedure such as running a data analysis or sending an email. Process science already has executable, human-interpretable process representations that serve the same purpose, and he counts four such representations available to hand to agents.

Flexible processes and the ad hoc subprocess

A common objection is that workflows mean rigid sequences of tasks and are therefore antithetical to open-ended agents. He treats this as a myth that process science already dismantled through its work on process flexibility.

The rigid version people imagine is design-time flexibility: at design time you enumerate every branch with if/then/else statements, which is inflexible precisely because every path must be specified up front. Process science identifies other flavours, and the one he singles out is deviation: at design time you specify a set of possible tasks without fixing when, in what order, or how many times each occurs; the sequencing is decided at runtime. His claim is that most agents today are already using the deviation form of flexibility — they just are not aware they are.

The concrete primitive is BPMN's ad hoc subprocess, which has been in the BPMN specification for about fifteen years. It says: here are the things you may do; I am not telling you when to do what, and you may do them sequentially or in parallel. Compare that with how you build an agent today — you give it tools and skills, you do not tell it when to use each or what the inputs will be, and you declare the possibility space at design time. In his example process map, an LLM call sits alongside a set of MCP servers and a deterministic workflow branch; the ad hoc subprocess declaratively expresses "invoke these however many times you want, in whatever order".

Because that is expressed in a formal workflow language running on a workflow engine, you inherit durability. He gives the specific case of three tool calls executing in parallel: if the second fails, you do not lose the result of the first. Toggling between sequential and parallel execution is a configuration change. These are precisely the properties agent builders are currently reimplementing by hand.

He also flags worklets as the process-science analogue of agent skills, with the same late-binding property that makes Claude skills interesting: the agent does not see the worklet until it needs it. It is not enumerated at design time — it is available if and when required.

Do not write your own workflow DSL or engine

Kumarakrishnan observes that popular agent frameworks are converging on workflows anyway. LangGraph is, in effect, a custom DSL for building workflows; Google's ADK is another. His criticism is that each is inventing its own DSL and repeating the previous generation's mistakes rather than adopting a mature specification.

The follow-up temptation — use a standard DSL but write your own engine — he rejects from experience, having written several workflow engines. Engines are domain-independent infrastructure full of subtle pitfalls, and a well-tested existing one is the better bet. What you get from a mature engine, none of it agent-specific:

• Durability across failures and restarts.
• Scalability, including cross-region execution, since a workflow is effectively configuration the engine executes.
• Control-plane facilities for operating and observing running processes.
• Asynchrony and message handling out of the box, if the workflow language is expressive enough.

The agent implementer specifies the process; the engine handles the rest.

Process mining

The third contribution is process mining. The raw material is transactional event data that systems, humans, and customers already emit: someone walks into a store, someone adds items to a cart and checks out. Process mining derives the as-is process — what actually happens — from that event data.

Why this matters for agents: enterprises want an agent to perform work that a group of people and systems currently perform, but most enterprises do not actually have a complete understanding of that process. The typical situation is partial automation with humans absorbing the tail cases. You cannot simply point an agent at that, because the agent does not know the process either. Writing tabula rasa Claude Code skills will not get far. His Walmart example is issuing purchase orders: you cannot just tell Claude Code to go issue one; you first have to know how purchase orders are actually issued.

The sequence he reports success with is: discover the process with process mining, codify the discovered process in a system, then ask an agent to enact it — which also opens the door to automating process discovery and management themselves.

His summary of the third idea has three parts: agents must be able to enact business processes or they will not be valuable to businesses; workflow engines are mature infrastructure agents can inherit if the agent is modelled in a process language that supports flexibility (so choose the language carefully); and agent builders should use process mining to discover and understand existing processes. Together these give you agents that execute durably at scale, are effectively configuration rather than bespoke infrastructure, and understand the process as it really is.

Idea 4: Terraform the Environment for Agents

The fourth idea has a deliberately provocative title. The claim: the most capable agent is only as effective as the environment it operates in. We obsess over agent architectures and neglect everything around them — legacy systems, poorly documented APIs, services with very little defensibility — and then expect agents to succeed there.

He anticipates the reflexive answer, MCP, and rejects it as a solution. MCP is an interface: it gives an LLM natural-language descriptions so it can decide when to call something. It can be the interface to your real solution, but it is not the underlying implementation, and it carries no opinions about higher-level abstraction or governance. Those have to be built beneath it.

The older idea he draws on is environment programming from Agent Oriented Programming, roughly ten to fifteen years old: reshape the environment so it is navigable, observable, and actionable for agents. His analogy is that humans have terraformed the physical world so that children and the elderly can move through it safely; our digital environment has had no equivalent work done for agents. Terraforming lets you place guardrails in the environment rather than only in the agent, and gives you legibility and feedback loops.

Why current environments are hostile

Three properties distinguish agents from the services our systems were designed for:

His illustration of cross-functionality: ask an agent to check something out at an e-commerce store and it needs search, product details, account, and checkout — a span of systems a single service would never touch.

Against that, the environments we actually have were built for a few trusted integrations with tightly scoped access, are not written defensively (validation assumptions are split between client and server), have few guardrails, and enforce policy in a distributed, inconsistent way. Hyper-tenancy adds a failure mode that barely exists in the services world: one agent naturally undoing or overriding another agent's work. At scale that requires arbitration, governance, and auditability, none of which current environments provide.

Artifacts

The abstraction he proposes is the artifact: a first-class entity in the environment that encapsulates functionality, presents a higher-level abstraction, and carries operating instructions for agents. Artifacts are the ergonomics of the environment.

He describes a layered environment: domain services at the bottom; ontology-based APIs above them, where issuing a purchase order is a single event-driven command rather than five API calls; and artifacts above that. Three flavours are named:

• Boundary artifacts — the interface to a set of capabilities, providing security, organizational control, and abstraction.
• Resource artifacts — mediating access to resources such as databases.
• Coordination artifacts — shared state for agents that need to coordinate, such as a blackboard namespaced to two agents and temporary in nature.

Walmart's middleware, as he describes it, has a proliferation of agents on top — hundreds or more — and domain services underneath. Direct integration between each agent and each service is infeasible: the services are not defensible and you cannot easily audit who did what. So a middleware stack of boundary artifacts sits between them, exposing a very simple API upward.

The boundary artifacts are implemented as event-sourced entities. When an agent wants to issue a purchase order, it calls the purchase order artifact with a create-purchase-order command; the artifact records that request in an immutable event stream. That gives auditability — the fact that a specific person's agent requested a purchase order is permanently recorded. It also gives a single enforcement point: if the purchase order team wants to cut off a particular agent tomorrow, there is exactly one place to do it, because all agents reach the services through the artifact. An MCP layer is then exposed on top of the artifacts, which he considers perfectly fine.

His example of arbitration is a policy such as: agents from department X may issue at most one million dollars of purchase orders in any 48-hour window. Every request from every agent is tracked, so this is enforceable at the artifact. Crucially, the underlying services do not change — they keep working as they always did, and the middleware absorbs the hyper-tenancy responsibility.

Artifacts are not tools

He is precise about the distinction, and returned to it in the first audience question:

Artifacts can be wrapped and exposed as tools, and all three flavours can have MCP wrappers. The line he uses to compress the whole idea: MCP gives you the syntax of interacting with the environment; artifacts give you the semantics. MCP tells you there is a tool with a description and a schema. The artifact supplies governance, abstraction, and arbitration. Citing the artifact literature, he notes the environment is not just a passive container that waits for something to happen — it is something you can actively mould for agents.

Asked in the Q&A for a concrete example of a resource artifact, he declined to give a one-size-fits-all answer, since it depends on the resource, but pointed to the workspace concept from the artifact literature: a workspace is a collection of artifacts, so membership in a workspace grants access to the artifacts it contains, and access control can be applied at the workspace level. How permissive that is depends on how "Wild West" you want your agents to be with a given resource. His point is that once you start thinking in resource artifacts, you automatically start asking the right questions — what implementation details can I hide, what is the observable state?

Architecture And Data Flow

The two structural ideas from the talk compose into a single picture: a modular agent (idea 2), specified as a flexible process on a workflow engine (idea 3), acting on an environment mediated by artifacts (idea 4).

flowchart TB
    subgraph Agent["Agent (CoALA-style modules)"]
        LLM["LLM
implicit procedural memory"]
        MEM["Memory modules
semantic / episodic / procedural"]
        ACT["Action space module
JSON tool calls or code sandbox"]
        LLM <--> MEM
        LLM --> ACT
    end
    subgraph Process["Process layer"]
        ENGINE["Workflow engine
durability, scale, async"]
        ADHOC["Ad hoc subprocess
deviation flexibility"]
        SKILLS["Worklets / skills
late-bound procedural memory"]
        ENGINE --> ADHOC
        ADHOC --> SKILLS
    end
    subgraph Env["Terraformed environment"]
        MCP["MCP layer
syntax"]
        ART["Boundary / resource / coordination artifacts
event-sourced, semantics"]
        GOV["Audit trail, policy, arbitration"]
        ONT["Ontology-based APIs"]
        SVC["Domain services"]
        MCP --> ART
        ART --> GOV
        ART --> ONT
        ONT --> SVC
    end
    EVENTS["Transactional event data"] --> MINE["Process mining
discover as-is process"]
    MINE --> ENGINE
    ACT --> ENGINE
    ADHOC --> MCP

The request path for the purchase order example runs as follows.

sequenceDiagram
    participant A as Agent
    participant W as Workflow engine
    participant B as Purchase order artifact
    participant S as Domain services
    A->>W: enact process (ad hoc subprocess)
    W->>B: createPurchaseOrder command
    B->>B: append to immutable event stream
    B->>B: check policy (e.g. dept X spend cap / 48h)
    alt allowed
        B->>S: orchestrate underlying service calls
        S-->>B: results
        B-->>W: outcome
    else denied
        B-->>W: rejected, recorded with reason
    end
    W-->>A: durable result (survives partial failure)

Trade-offs And Limitations

The broader agent definition is an analysis tool, not a licence to over-model. Kumarakrishnan is explicit that if a simpler abstraction describes your system, use it — a light switch is a finite state automaton. Reaching for the agent paradigm on a system that does not need human orientation and complex delegation adds cost with no benefit.

Modularity has an up-front cost. Defining module boundaries and APIs is more work than adding a line to a prompt, and the payoff only arrives when the architecture changes. His counter-argument is that models are improving fast enough that the change is close to certain, but a short-lived prototype may rationally skip it.

Adopting a workflow engine is a real dependency. You inherit durability, scale, and asynchrony, but also an engine to operate, a specification language to learn, and a constraint on how your agent can be expressed. He warns that a process language without adequate flexibility primitives will fight you — pick one that has something like the ad hoc subprocess, or you will end up back in rigid design-time branching. His alternatives are both unattractive: your own DSL repeats the industry's mistakes, and your own engine is a large domain-independent project with many pitfalls.

Process mining requires event data you may not have. The whole technique assumes systems, humans, and customers already emit transactional events. Where work happens in people's heads, in email, or in undocumented tail cases, the discovered process will be incomplete — and those tail cases are exactly where existing automation already fails.

Artifacts are middleware, with the usual consequences. A boundary artifact layer is a new tier to build, operate, and evolve. Its benefit is that domain services are left untouched, but it also becomes a chokepoint that must scale with agent traffic and stay in sync with service semantics. Event sourcing gives auditability and permanent records, but permanent records of agent activity carry their own retention, privacy, and storage obligations — the talk mentions the immutability as a benefit and does not discuss the governance burden it creates. (That last observation is mine, not the speaker's.)

MCP is not the villain. Asked directly in the Q&A, he was careful: MCP is a perfectly reasonable, even fantastic, interface when you want an LLM to drive tool selection, because semantic natural-language descriptions are what LLMs are good at. He is not criticizing MCP. His question is what sits underneath the MCP tool — and his hope is that it is not merely a wrapper over a REST API. His sharpest phrasing in the wrap-up: do not just "slop MCP layers on top of existing REST APIs".

Scope of the evidence. This is an experience report from one large enterprise plus a reading of the research literature, not a controlled comparison. Claims such as CoALA becoming Walmart's de facto approach, or success in discovering and codifying processes before handing them to agents, are the speaker's reported experience. The talk includes no benchmarks, and the Walmart architecture diagrams were acknowledged on stage as hard to read at presentation scale.

The "agents are just services with LLMs in the middle" framing. He acknowledges you can think that way, but argues it violates the stronger notion of agency he is advocating, and that the three differentiators — hyper-tenancy, unpredictability, cross-functionality — are precisely what the services mental model fails to account for.

Practical Takeaways

1. Separate the problem from the implementation when you define your agent. Write down what the agent perceives, what it acts on, and which decisions it owns, before choosing whether an LLM is involved at all. If a state machine or a plain workflow fully describes it, do not build an agent.
2. Draw module boundaries before your first rewrite, not after. At minimum, isolate the action space (tool calling versus code execution), memory, and the model call behind separate APIs. CoALA and DSPy are two concrete vocabularies for this; the requirement is that a change in agent architecture should touch one module.
3. Treat skills and prompt-embedded procedures as procedural memory, and store them accordingly. Claude skills, worklets, and documented runbooks are the same category of asset. Late binding — the agent only sees the procedure when it needs it — keeps the context window and the design-time specification small.
4. Before writing another agent framework DSL, evaluate a mature workflow engine. Camunda with BPMN was his concrete recommendation in the Q&A, specifically because BPMN's ad hoc subprocess already captures the runtime flexibility agents need. Check any candidate for the deviation-style primitive before committing.
5. Get durability from the engine, not from your agent loop. If a multi-tool-call step can partially fail, that is a workflow-engine problem with a known solution, not something to re-solve in application code.
6. Mine the as-is process before automating it. Pull transactional event data from the systems that already record the work, reconstruct what actually happens, codify it, and only then hand it to an agent. Skipping this is the most common reason enterprise agent projects stall.
7. Put governance in the environment, not only in the agent prompt. Build a boundary artifact for each high-risk capability — purchases, refunds, data export — that records every request in an event stream and enforces policy such as spend caps and per-agent revocation in one place.
8. Ask what is under each MCP tool. If the answer is "a thin wrapper over a REST endpoint", you have exposed syntax without semantics: no auditability, no arbitration, no higher-level abstraction.
9. Design for hyper-tenancy explicitly. Assume many agents acting for many principals will touch the same resources concurrently and may undo each other's work. Decide where arbitration lives before that happens.
10. When you need agents to coordinate, reach for a coordination artifact. A namespaced, temporary shared blackboard is a cleaner mechanism than passing state through prompts.
11. Use workspaces to group resource artifacts for access control. It gives you a coarse-grained handle on what a given agent may touch without per-artifact permission sprawl.

Key Terms

• Agent — In the classical Russell & Norvig sense, an entity that perceives an environment and acts on it, deciding what action to take and when. Used as a modelling abstraction rather than a category of system.
• Agent Oriented Programming — Yoav Shoham's 1990s programming paradigm treating agents as entities with beliefs and intentions; also the source of the environment programming idea.
• Compound AI system — A system composed of many interacting components, of which an LLM may be one. Broader than an AI agent.
• Chain of thought — Prompting a model to articulate reasoning steps before producing an answer.
• ReAct — An architecture where the model interleaves reasoning with structured tool calls that the runtime executes.
• CodeAct — A variant where the model's action space is executable code in a sandbox rather than JSON tool calls.
• CoALA — Cognitive Architectures for Language Agents; a formalism that decomposes an agent into memory modules, action spaces, and decision procedures, and re-describes existing agent architectures within it.
• DSPy — A programming model for building language-model systems as composable, independently optimizable modules.
• Procedural memory — Knowledge of how to perform a task. In an LLM-based agent, partly implicit in model weights and partly explicit in skills, scripts, and process definitions.
• Process science — The roughly forty-year-old discipline covering formal process modelling, workflow execution, process flexibility, and process mining.
• BPMN — Business Process Model and Notation; a long-standing standard process specification language executed by workflow engines.
• Ad hoc subprocess — A BPMN construct declaring a set of permitted activities without fixing their order, timing, or repetition; the formal counterpart of giving an agent a tool set.
• Deviation flexibility — A process-flexibility category where the runtime, not the design-time specification, determines which of the permitted tasks execute and in what order.
• Worklet — A process-science construct for a self-contained procedure that becomes available only when needed; analogous to an agent skill.
• Process mining — Reconstructing the actual ("as-is") process from transactional event logs emitted by systems, people, and customers.
• Environment programming — Deliberately reshaping the environment agents act in so it is navigable, observable, and actionable, rather than only improving the agent.
• Artifact — A first-class entity in the agent's environment that encapsulates functionality, provides a higher-level abstraction, and carries operating instructions. Boundary artifacts provide governance and security; resource artifacts mediate access to resources; coordination artifacts provide shared state between agents.
• Workspace — A named collection of artifacts used as a unit of access control.
• Hyper-tenancy — The condition where very large numbers of agents, acting on behalf of many principals, concurrently use systems designed for a handful of trusted integrations.
• Event sourcing — Persisting state as an append-only sequence of immutable events, which yields a natural audit trail.
• MCP (Model Context Protocol) — A protocol exposing tools to LLMs with natural-language descriptions and schemas. In this talk's framing, the syntax of environment interaction, not its semantics.
• Catastrophic forgetting — Borrowed from machine learning; here, the industry-level pattern of discarding hard-won lessons at the end of each AI hype cycle.

Kumarakrishnan closes by restating the four ideas together: adopt a stronger, implementation-independent notion of agents so you stay problem-oriented; build for modular evolution because models and architectures are changing faster than you can rewrite; lean on process science rather than reinventing it; and terraform the environment for the hyper-tenant, unpredictable, cross-functional demands agents place on it. His framing is that none of these are new — they are old ideas that only look futuristic because the field forgot them — and that is precisely the argument for their durability.

Reference: Aditya Kumarakrishnan, From Hype to Strong Foundations: What the Rise, Fall and Resurgence of Agents Can Teach Us about Outlasting the Cycle, QCon AI, published by InfoQ. Presentation length 50:24; notes based on the full published transcript including audience Q&A.