Agents Force a Rethink of Backend Architecture
AI agent frameworks are opinionated software systems that turn language models into long-running, tool-using backends, bundling runtime, memory, gateways, and governance into a coherent way to build, deploy, and operate agents in production instead of handling them as isolated API calls. That shift has moved from theory to practice. AWS recently released AWS Blocks in public preview, an open-source TypeScript framework in which each “Block” bundles application code, a local development implementation, and the AWS infrastructure required to run it in production. Vercel has released Eve, an open-source framework for building, deploying, and operating AI agents in production. In parallel, the agent harnesses OpenClaw and Hermes argue over what should control agents in the first place—gateways or memory. Underneath all of them, AWS, Microsoft, Google, and Anthropic are rebuilding runtimes so the agent session, not the request, is the unit of compute.
Blocks vs. Eve: Two Opposite Answers to AI Backend Infrastructure
AWS Blocks is explicit about its bet: if agents are going to write backend code, the framework should bake infrastructure patterns straight into TypeScript. Each Block is an npm package for a backend capability—database tables, user authentication, AI agents, file uploads, background jobs, scheduled tasks, real-time notifications, email—and the framework then generates AWS infrastructure that runs on Lambda, DynamoDB, Aurora, API Gateway, and Bedrock with zero code changes between local and production. Developers can run npm run dev and get Postgres, authentication, real-time messaging, and file storage locally without even having an AWS account. That is a strong stance: agent authors should not see Terraform, only type-safe APIs. Eve takes the opposite tack. It is built around a filesystem-based project structure where instructions, tools, skills, subagents, channels, and scheduled tasks are directories and each capability is a file, discovered at build time and exposed to the agent without registration code.
OpenClaw vs. Hermes: Who Really Controls the Agent?
OpenClaw and Hermes agree on the anatomy of an agent harness: a runtime that keeps an agent alive, a gateway that moves messages, and memory that persists across sessions. They disagree on which part should be the primary control point. OpenClaw is gateway-first, built around connecting a single governed agent to channels like WhatsApp, Discord, and Slack so platform teams can offer one enterprise agent inside tools staff already use. Hermes Agent is memory-first, built around durable, developer-centric context so one agent can carry a developer’s work across weeks and refine its own skills. The open-source momentum reflects how much this argument matters. OpenClaw’s repository neared 380,000 GitHub stars by late June, while Hermes surpassed 100,000 stars by mid-May and reached roughly 160,000 later that month; Hermes also topped OpenRouter’s daily rankings with 224 billion tokens on May 10 and more than 22 trillion tokens by late June. Those numbers are a blunt signal: developers are voting on control philosophy, not models.
Session-Based Compute: The New Agent Runtime Architecture
The most important convergence is happening at the runtime layer. Over the past few months, AWS, Microsoft, Google, and Anthropic each shipped agent runtime updates that all point to the same shift: from request-level load balancing to session-aware execution. Enterprise agents are long-running, stateful, tool-using processes that often run code influenced by user input, so the runtime is becoming a control plane for state, identity, isolation, and lifecycle, with the session as the scheduled unit. Anthropic’s Managed Agents explicitly virtualize an agent into three parts: a session that logs everything, a harness that drives the loop and routes tools, and a sandbox that executes code. AWS AgentCore is the most opinionated: each session gets a dedicated Firecracker microVM with isolated compute, memory, and filesystem, and any request with the same runtimeSessionId is routed back through a session header to that microVM. All four platforms now treat agent work as separate from ordinary load-balanced traffic.
What These Architectural Bets Mean for Developers
These design choices are not cosmetic. They codify competing philosophies about how agents should be governed and isolated in production. The contest between OpenClaw and Hermes is over the control layer, not the model either one calls. Blocks argues the control layer belongs inside a TypeScript agent development framework that bundles mocks and AWS infrastructure, steering coding agents toward "correct" architecture from day one. Eve argues that control comes from filesystem conventions: capabilities as files, durable execution modeled as workflows that can pause and resume, and agent-generated code running inside isolated sandboxes locally via Docker or in production via Vercel Sandbox. Meanwhile, the cloud giants converge on routing and lifecycle but diverge on execution substrates; no single architecture fits every workload, and a multi-day research agent, a code-heavy agent, and high-volume automation will each want different isolation levels. For ordinary users, the practical upside is clear: governed agents reachable from existing tools, with sessions that survive failures, and conversations that can pause and resume without losing state.
