A Post That Started a Question
I recently saw a take on Jike (a Chinese social platform): AI Agents are rewriting the infrastructure playbook — the future isn’t containers, it’s Stateful Containers.
The intuition is correct — when agents evolve from “call a function, return a result” to “work continuously inside an environment,” the underlying infrastructure paradigm does shift. But if you push the question further, things get far more complex than just “adding state.”
This article tries to untangle a few questions from the intersection of agent infrastructure and interaction design: What kind of runtime environment do agents actually need? What does it mean for skills to be the “apps” of the agent era? And why might interface standards be the most important design work of this moment?
Questioning the Stateful Container
Traditional serverless (e.g., AWS Lambda) is stateless: a function is invoked, executed, returns a result, and the environment is destroyed. That’s not enough for agents. An agent may need to install dependencies, manipulate the filesystem, run multi-step tasks — it needs not a function, but a place.
The stateful container intuition is: give the agent a persistent container environment where state doesn’t get lost.
But here’s a counterintuitive fact: many scenarios that seem to need stateful containers actually don’t.
Take the most common agent use case — automatically analyzing news every morning and sending a daily briefing. This is essentially a cron job plus LLM API calls. Each execution is independent; no environment persistence is needed. A GitHub Action is enough.
Even if you need “cross-execution knowledge accumulation” (remembering what was reported yesterday, tracking event threads, learning user preferences), that “state” can be handled by an external database. You don’t need the entire container to stay alive.
At the other end, the reason Claude Code’s resume feature works so well is precisely because there’s no container — it runs on your local machine, where the filesystem is naturally persistent and the environment never disappears. “State” isn’t a problem that needs explicit management.
So what scenarios truly need container-level environment management?
- The agent needs to run 24/7 in the cloud, where environments are ephemeral by default
- The agent serves others as a service and needs isolated runtime environments
- The agent runs untrusted code and needs security boundaries
- Multiple agents need to collaborate or hand off within the same environment
These are real needs. But a more precise framing might be: agents don’t need “an environment that stays alive” — they need “the ability to quickly get a complete environment when needed.” This points not to stateful containers, but to serverless containers: full containers (arbitrary dependencies, complete filesystem, root access) that start on demand, bill by usage, and scale to zero when idle.
If startup is fast enough, you don’t need to maintain state — just rebuild each time. Define the environment as an image, persist valuable outputs to external storage, and discard the environment itself. Modal, Fly Machines, and E2B are all heading this direction.
Skill as App? Not Quite
If the container solves “where to run,” the next question is “what to run.” In the agent context, that “what” is skill.
Anthropic’s Claude Code skills architecture proposes a clear layering: Agent Loop (reasoning) → Agent Runtime (execution) → MCP Servers (connectivity) → Skills Library (knowledge). A skill is defined as a packaged collection of domain expertise — prompts, scripts, documentation.
This naturally invites an analogy: skill is the App of the agent era.
But this analogy immediately hits a fundamental problem: the reason App is a clear product concept is that GUI gives it boundary. You “open” an app, you see what it can do, you interact with it, you “close” it. The entire interaction is visible, bounded, and intuitive.
Skills have none of this. Users may not even know when a skill is invoked. What it runs in the background is invisible. Its boundaries with other skills are blurry. To the user, the agent is a whole; skills are invisible implementation details.
The dependency conflict problem makes things worse. A personal agent might simultaneously have a data analysis skill (needs pandas + jupyter), a web scraping skill (needs playwright + chromium), and an audio processing skill (needs ffmpeg). Cramming all of these into one environment causes conflicts, but fully isolating them makes inter-skill collaboration difficult.
The design challenge here is: finding the right boundary between isolation and sharing.
One possible model is a two-layer architecture:
- Shared layer: A persistent workspace holding the agent’s personal data, configuration, and intermediate artifacts. All skills can read and write. This is “the agent’s home.”
- Execution layer: Each skill invocation spins up a serverless container with that skill’s own dependency environment. It mounts the shared layer for data access, but its runtime is isolated. Destroyed after execution.
Written out this way, you’ll notice it’s strikingly similar to an operating system: shared layer = filesystem, execution layer = process, skill image = application, manifest = permission declaration, agent platform = kernel scheduler.
We’re reinventing every core OS component at the agent level.
If Not an App, Then What?
When we say “skill as App,” the mental model is GUI-based. But skills don’t have GUIs — they’re more like tools, backend processes.
This forces us to rethink a question: what does an “application” even look like in the agent era?
A traditional App tightly bundles three things: computation + data + interface. An iOS App packages these three layers together into a unit users can understand.
In the agent era, these three layers get unbundled:
- Computation = skills (scripts, CLI tools, capabilities), running in containers
- Data = the agent’s shared workspace + external storage, existing across skills
- Interface = split into two parts: the agent’s narrative (lightweight) + generative UI (heavyweight)
Perhaps the agent era simply has no equivalent to “App.” These three layers won’t be tightly coupled like Apps anymore, but loosely composed:
Agent = Scheduling Kernel
├── Skills (compute layer, running in containers)
├── Workspace (data layer, persistent storage)
└── Surfaces (presentation layer, generated on demand)This introduces the concept of “Surface” — not an App’s GUI, not part of a skill, but the presentation mode the agent selects for the current task. Sometimes a surface is just a sentence (“file processed”), sometimes a dynamic chart, sometimes a full interactive interface.
This is structurally isomorphic to the traditional frontend / backend / database three-tier architecture. But with one fundamental difference: who makes the decisions.
In traditional architecture, developers decide at build time what the frontend looks like, how the backend processes data, how data flows. These are fixed when users interact. In agent architecture, these decisions are deferred to runtime, and the decision-maker isn’t the developer — it’s the agent. Developers provide components and constraints, not complete applications.
Where Generative UI Fits
What role does generative UI play in this framework?
Its promise: the agent dynamically generates interfaces based on the current task, rather than using preset fixed UIs. This could solve the problem of skills lacking visual presence — after a skill runs, the agent doesn’t just output text but instantly generates an interactive interface for exploring results.
But there’s a tension between generative UI and agents: generative UI’s logic is to hand interaction control back to the user (here’s an interface, you operate it); while the agent’s logic is to do it for you (you don’t need to operate). If every skill execution pops up a UI for user confirmation, the agent degenerates into a fancy wizard flow.
A more practical concern is implementation cost. Current generative UI approaches — whether iframes, JSON schema rendering, or having AI directly generate React components — are all much heavier than the skills themselves (script + CLI).
So generative UI shouldn’t be the default for skill execution, but rather a detail layer that expands on demand. The default path is agent narrative + result presentation — if that’s sufficient, you’re done. Only when the user wants to go deeper (“show me the raw data,” “how did you reach this conclusion”) does the agent dynamically generate an interactive interface.
This is essentially progressive disclosure applied to agent interaction — the same design principle, extended from the technical architecture layer to the user experience layer.
Interface Standards: The Invisible Experience Design
At this point, we face a loosely coupled system: skills execute in containers, data flows through shared workspaces, surfaces are generated on demand. The agent makes scheduling decisions at runtime. No one designs complete user flows in advance.
This system has extremely high degrees of freedom. But high freedom means high unpredictability. Users don’t know what the agent will do, developers don’t know in what context a skill will be invoked, skills don’t know each other’s output formats. A system without constraints rapidly drifts toward chaos — entropy increases.
What interface standards do is introduce predictability without limiting capability. They don’t tell the agent what to do, but define what contracts the agent’s actions must follow. Like grammar — it doesn’t limit what you say, but lets others understand what you’re saying.
There’s a clear gap at this level today. MCP defines tool invocation interfaces but doesn’t cover environment requirements or presentation needs. Anthropic’s skill spec goes partway but doesn’t reach the surface layer. A complete skill manifest should declare:
- Environment contract: what system dependencies, runtime, and resource limits the skill needs
- Data contract: which workspace paths the skill reads/writes, input/output data formats
- Narrative contract: a one-line description (for the agent to explain to users), key checkpoints during execution (for the agent to report progress), possible failure modes (for the agent to manage expectations)
- Presentation contract: what surface forms suit the skill’s output (plain text / chart / interactive UI), whether it provides generative UI templates
The “narrative contract” is the most easily overlooked yet highest-impact part for user experience. It’s essentially the skill’s narrative interface — not a GUI for humans to operate directly, but material for the agent to communicate with humans. Existing tool definitions (MCP, function calling) almost exclusively focus on technical interfaces. No one is seriously designing this narrative layer.
A Design Tension, Not a Technical Problem
There’s a core design tension here: too few constraints and the system is chaotic, the experience uncontrollable; too many constraints and the agent’s flexibility dies, regressing to traditional software. Finding that “just enough constraint” is the hardest part.
This isn’t a pure systems engineering problem — it’s an interaction design problem.
Good design has never been about giving users unlimited freedom, nor about locking down every path. It’s about designing reasonable constraints so that freedom and order coexist. Interface standard design in the agent era is doing exactly the same thing — except the “user” you’re designing for isn’t just a person, but also the agent itself.
Agents can do anything. But for a system to keep running, something needs to reduce entropy. Interface standards are the entropy reduction mechanism of the agent era. They determine, in a high-freedom system, what is predictable, what is composable, what is trustworthy.
And these invisible boundaries are precisely what determines user experience.
2026.02