Architecture

Every agent framework is secretly the same five pieces

Strip the branding off OpenClaw, Hermes, ZeroClaw, or Claude Code and the same anatomy appears: a loop, a config, a state directory, a front door, a clock.

Maritime Team·August 17, 2026·6 min read

Pick any two agent frameworks and read their websites side by side. One is a runtime for autonomous work, the other is the fastest way to ship agents that act. Now deploy both, wait a week, and look at what is actually running on the machine. Underneath the branding, every AI agent framework is the same animal: a loop, a config file, a state directory, a front door, and a clock.

We are in a good position to make this claim. Maritime hosts agents built on OpenClaw, Hermes, ZeroClaw, and Claude Code, next to a long tail of custom containers, each on its own isolated machine. Watch enough of them boot, sleep, wake, and misbehave, and the differences start to look cosmetic while the structure stays constant. Five pieces, every time.

The anatomy: five pieces, one machine. The world and the clock arrive through the front door; everything durable lives in the state directory

The loop

The piece every framework leads with: take a goal, call the model, run the tools it asks for, feed the results back, repeat until done. This is where the marketing lives, and the loop is genuinely where frameworks differ. ZeroClaw implements its loop in one static Rust binary. Claude Code's runs behind the Claude Agent SDK. OpenClaw's is a Node process with a plugin ecosystem.

It is also, structurally, the smallest piece. A working agent loop is a few hundred lines, and every impressive demo you have watched was mostly this piece performing. The other four are where the remaining ninety percent of every framework's codebase went, which tells you something about where the real problems live, and about why the demo is not the product.

The config file

Every framework converges on a file that names the model, the provider, and the credentials. OpenClaw has openclaw.json. ZeroClaw has one TOML file, migrated explicitly at startup. Hermes wants a providers dictionary. Claude Code takes environment variables and per-call options. The formats never agree; the role never changes.

The config is the part of the agent you can regenerate from documentation. Lose it, and you grumble, read the docs again, and retype it in ten minutes. Annoying, not fatal.

The state directory

Which makes the third piece the interesting one, because it is the part you cannot regenerate. Conversation memory. The workspace with half-finished projects. Approved contacts. Tool state. OpenClaw keeps its world under /data/.openclaw. ZeroClaw's entire universe, config and workspace and state, lives under one directory, by design. Hermes persists its pairing decisions on its volume so they survive restarts. Claude Code accumulates sessions and a workspace it can return to next month.

An OpenClaw agent's volume in the dashboard file browser: .openclaw touched an hour ago, an inbox, an outbox. You are looking at the agent

The uncomfortable conclusion, once you have watched enough agents live and die: the state directory is the agent. The process is disposable, restartable, upgradeable. The directory is not. This is why sleep/wake works at all (suspend the machine, keep the disk), why moving an agent between hosts means moving its volume rather than its image, and why a backup of anything else is decoration.

What dies with the process, and what the process cannot take with it

We restart agent processes all day: deploys, wakes, host maintenance. Nobody has ever written in about a lost process. The email you never want to receive from your hosting provider is about a lost directory.

The front door

An agent nobody can reach is a batch job. So every framework grows an entry point, and here the convergence is loosest in mechanism and tightest in function. OpenClaw runs a gateway that speaks WebSocket and connects messaging channels. ZeroClaw's gateway speaks WebSocket under a versioned subprotocol, zeroclaw.v1, so old clients survive upgrades. Hermes refuses to have an HTTP chat endpoint at all; you reach it through its channels or its CLI (on Maritime, chat runs hermes chat inside the VM). Claude Code, wrapped for hosting, answers POST /chat and GET /health on a port.

The front door is also where the security that matters lives, because it is where strangers arrive. Hermes holds unknown contacts at a pairing wall until the owner approves them; the agent literally replies "I don't recognize you yet" and waits. The lesson generalizes: you cannot make the model reliably ignore hostile instructions, but you can decide who gets to put text in front of it. The model never gets safer. The door can.

The pairing panel of a Hermes agent. Strangers wait here until you let them in

The clock

The last piece is what separates agents from chatbots. A chatbot answers; an agent also acts when nobody is watching. The morning digest, the hourly sweep, the retry at 3 a.m. Every framework grew internal scheduling, and every serious deployment also wants scheduling from outside the process, because a schedule that lives inside a process dies with it. On Maritime, cron and webhook triggers fire from the platform, wake the agent, and let it decide what the tick means. The schedule keeps its promises even when the agent does not exist between ticks.

Why every framework converges on the same architecture

The shape is not fashion. It falls out of what an agent is: a long-running, stateful process that talks to a model, is reachable by the world, and acts on a schedule. We made a version of this argument about hosting models; it applies one level up. Any framework that survives long enough grows all five pieces, in whatever order its users demand them.

The convergence is also why frameworks can be hosted uniformly. Give the state directory a persistent volume, the front door an endpoint, the clock a trigger system, and the loop an LLM key, and the platform genuinely does not care what language the loop is written in. That is the entire trick behind deploying four very different frameworks with the same command.

The Templates page on Maritime: four frameworks, four Deploy buttons, one lifecycle underneath

Where they still differ, honestly

Footprint. ZeroClaw's single binary keeps a fraction of an interpreter stack's memory resident, which on snapshot-based infrastructure means smaller snapshots and faster wakes. The anatomy is shared; the mass is not.
Security defaults. A pairing wall that quarantines strangers and a webhook URL that acts as a bearer credential are both front doors, with very different failure modes. Read the defaults before you pick.
State formats are not portable. The directories converged; the file formats inside them did not. Switching frameworks today means abandoning your agent's memory. Nobody has built the converter yet.
Tools. MCP is doing for agent tools what USB did for peripherals, but adoption is uneven, and every framework still ships its own native tool layer beside it.

Choosing with the anatomy in mind

Stop comparing loops; you will use maybe three of the features. Pick by the piece you will actually touch. If your agent lives in messaging, weight the front door: Hermes and OpenClaw have the most mature channel handling. If you are embedding agents in your own product, weight the loop's programmability: Claude Code behind the Agent SDK is a library, not a lifestyle. If you care about density and cold-path speed, weight footprint: ZeroClaw. The other pieces will find you regardless. (For a concrete head-to-head at the orchestration layer, see LangGraph vs CrewAI.)

All of them run on Maritime with the same lifecycle, because the lifecycle was built for the anatomy, not for any one framework.

Frameworks compete on the loop. Production happens in the other four pieces.