Capital de TokensWhen we think about a programming agent, we usually picture a model connected to a terminal. We ask it to fix a bug, the agent reads files, runs tests, modifies code, and returns a result.
But that picture hides two deeper questions:
- Where does the computer the agent works on actually live?
- What happens to everything the agent did during execution when the session ends?
Hermes Agent, from Nous Research, is interesting because it treats both questions as infrastructure problems. On one hand, it decouples the agent from the machine where commands execute. On the other, it can record the complete path of its sessions as trajectories: structured data useful for debugging, evaluation, and even training models that can use tools.
These two ideas —portable execution environments and reusable trajectories— point toward an important evolution: moving from using agents as individual assistants to operating them as measurable and trainable computing systems.
The agent is not its computer
A modern agent can conceptually be divided into three pieces:
Model
+
Agent runtime
+
Execution environmentThe model decides what to do. The runtime maintains the conversation, provides tools, coordinates calls, and manages state. The execution environment is the real computer where actions such as git status, pytest, npm install, or file editing happen.
In a traditional tool, those layers appear attached to our laptop. Hermes introduces an abstraction in between: its terminal tool can point to different backends without changing the agent’s high-level logic.
The current implementation documents seven backends: local, docker, ssh, singularity, modal, daytona, and vercel_sandbox.
For the model, however, the experience can remain almost identical:
terminal("git status")
terminal("pytest")
read_file(...)
patch(...)The model does not need to constantly worry about whether the command ran on the user’s laptop, inside a container, or on a remote machine.
Runtime and sandbox: a fundamental separation
This separation enables an architecture closer to cloud computing:
User / Telegram / API
│
▼
Hermes Agent
│
│ tools
▼
remote sandbox
│
┌─────┴─────┐
git pytest
python buildHermes can act as the agent runtime, while Daytona, Modal, Docker, or Vercel Sandbox act as its work computer.
That means the agent can be reachable from a chat while simultaneously working on a machine that is not the device from which we are talking to it. Closing the laptop no longer necessarily means shutting down the place where the agent performs its work.
This distinction also improves security. The agent can live in a relatively stable runtime and send terminal operations into a separate environment with explicit CPU, memory, disk, process, and permission limits.
The problem with ephemeral environments
A fully ephemeral sandbox has a clear advantage: every execution starts clean. But it also has a cost.
Every time we begin a task, we may repeat:
create environment
↓
clone repository
↓
install dependencies
↓
create caches
↓
execute work
↓
destroy environmentFor small tasks that may be acceptable. For agents that repeatedly work on the same project, it becomes inefficient.
That is where persistence appears.
A persistent environment can preserve, across sessions, elements such as:
workspace/
├── repo/
├── .venv/
├── node_modules/
├── build/
└── caches/The agent can stop working, the environment can become inactive, and later that state can be recovered instead of rebuilding everything from scratch.
For container backends, Hermes exposes common configuration for CPU, memory, disk, and persistence. In Docker, for example, it can maintain a long-lived container during the process and reuse the same workspace across multiple tool calls.
Disk persistence does not mean an immortal process
There is an important distinction that often gets lost when discussing persistent sandboxes:
filesystem persistence ≠ process persistenceA provider may preserve files even if it destroys the machine or microVM that was executing them.
Vercel Sandbox, for example, can rely on filesystem snapshots to reconstruct task state. That makes it possible to recover files and configuration, but it does not imply that a process with a particular PID remains alive after the sandbox is recreated.
When designing long-running agents, it is important to know exactly what persists: files, variables, processes, ports, machine identity, or simply a reusable volume.
Why does this matter for autonomous agents?
An agent that works for hours or days needs something more like a workstation than an isolated function.
It may require cloned repositories, installed dependencies, build caches, intermediate artifacts, controlled credentials, Git branches, test results, and specialized tools.
Being able to move that workstation between local, Docker, SSH, or cloud lets us choose infrastructure according to risk and workload.
A local environment can be ideal for development. Docker adds isolation and reproducibility. SSH keeps the agent away from its own runtime. Singularity fits HPC. Modal and Daytona target cloud execution. Vercel Sandbox provides microVMs with snapshots.
The terminal abstraction turns those details into an infrastructure decision instead of requiring a complete rewrite of the agent.
From running agents to studying agents
The second idea is even more interesting from a research perspective.
When an agent solves a task, it does not produce only a final answer. It produces a sequence of decisions and actions.
For example:
User: "fix the bug"
↓
Model decides to inspect the repo
↓
git status
↓
reads results
↓
read_file(...)
↓
modifies code
↓
pytest
↓
interprets result
↓
final answerThat complete path is a trajectory.
A trajectory is more valuable than a final answer
If we store only:
prompt → answerwe lose almost all the operational information.
To train or evaluate tool-using agents, we want something much richer:
objective
+
decisions
+
tool calls
+
arguments
+
results
+
errors
+
corrections
+
final outcomeHermes can save these trajectories as JSONL compatible with ShareGPT-style formats. In addition to conversation history, the format can include tool statistics, call counts, completion status, and errors.
A simplified entry could look like this:
{
"prompt_index": 42,
"completed": true,
"model": "teacher-model",
"conversations": [
"... messages, tool calls, and tool results ..."
],
"tool_stats": {
"terminal": {"count": 8, "success": 8, "failure": 0},
"read_file": {"count": 4, "success": 4, "failure": 0}
}
}Now the agent’s work no longer disappears when the session ends. It becomes a data artifact.
Generating trajectories in batch
Hermes includes a batch_runner.py aimed precisely at this scenario.
Instead of giving the agent a single task, we can prepare a dataset:
{"prompt": "Fix this Python bug"}
{"prompt": "Implement this REST endpoint"}
{"prompt": "Diagnose this test failure"}And run many agent sessions in parallel:
task dataset
│
▼
Hermes batch runner
│
┌────────────┼────────────┐
▼ ▼ ▼
worker 1 worker 2 worker 3
│ │ │
agent agent agent
│ │ │
sandbox sandbox sandbox
│ │ │
└────────────┴────────────┘
│
▼
trajectoriesEach prompt can have its own isolated environment. The runner supports parallelism, checkpoints, and resuming interrupted executions.
The result is organized like a small data pipeline:
data/my_experiment/
├── trajectories.jsonl
├── batch_0.jsonl
├── batch_1.jsonl
├── checkpoint.json
└── statistics.jsonThat turns the agent runtime into a factory for reproducible experiments.
Teacher and student: learning to use tools
Suppose we use a powerful model as the teacher to solve thousands of tasks.
powerful model
│
▼
Hermes Agent
│
▼
10,000 tasks
│
▼
10,000 trajectoriesThe resulting dataset contains examples of how the model selects a tool, constructs its arguments, interprets the result, detects an error, changes strategy, verifies the outcome, and decides when to stop.
Those examples can later be used for fine-tuning or research on smaller models.
The goal is not only to teach that a correct answer is X. We want to teach the tool-use pattern that leads to a correct answer.
For example:
if you need to know repo state
→ call git status
if you modified code
→ run tests
if tests fail
→ interpret the error
→ inspect the relevant file
→ fix it
→ test againThat kind of behavior is central to the next generation of tool-oriented models.
The problem: trajectories can be enormous
A real session can accumulate tens or hundreds of thousands of tokens because tool outputs are often large:
system prompt 8K
response 4K
terminal result 20K
file read 35K
logs 30K
more reasoning 20K
...Keeping everything raw can be expensive and impractical for training.
That is where trajectory compression comes in.
Hermes includes a compressor that tries to reduce a trajectory to a token budget without simply chopping off the end. The project’s example configuration uses a 29,000-token target.
The strategy protects important parts such as the system message, original request, early interactions, and final turns. The middle section can be semantically summarized when necessary.
Conceptually:
beginning KEEP
↓
early decisions KEEP
↓
intermediate work COMPRESS
↓
intermediate work COMPRESS
↓
latest actions KEEP
↓
final outcome KEEPThis is not ZIP compression or model quantization. It is semantic compression of the agent episode to turn a long session into a manageable training example.
When we combine both worlds
Portable execution and trajectories are not isolated features. Combined, they form a much more interesting architecture.
We can imagine the system like this:
TASK DATASET
│
▼
Hermes
│
├── sandbox 1 → agent
├── sandbox 2 → agent
├── sandbox 3 → agent
└── sandbox N → agent
│
▼
trajectories
│
▼
trajectory compression
│
▼
curated dataset
/ \
▼ ▼
evaluation fine-tuningNow Hermes is no longer simply an alternative to a terminal coding agent. It starts to look like an experimental runtime for agentic systems.
The most important idea: the work stops disappearing
Today, much of the work performed by agents is lost after each session. We know the final answer, but we do not necessarily preserve in structured form what the agent tried, which tools it used, where it failed, and how it recovered.
Trajectories change that.
Every execution can become evidence for answering questions such as:
- which models use tools best?;
- which action sequences precede a correct result?;
- which errors repeat?;
- how much does it cost to solve a particular class of tasks?;
- which toolsets help or hurt?;
- can we train a smaller model from executions of a more capable one?;
- which policies reduce retries and unnecessary calls?
In other words, the agent stops being only a worker. It also becomes a generator of data about its own way of working.
Conclusion
The two most interesting features of Hermes Agent point in the same direction.
The first decouples the agent’s brain from its computer. The runtime can work on local, Docker, SSH, or persistent cloud sandboxes without fundamentally changing how the model uses tools.
The second decouples the result from the process that produced it. A session stops being an ephemeral conversation and becomes a structured trajectory that can be analyzed, compressed, compared, and used as a dataset.
Together they produce a powerful idea:
agents can run as infrastructure and their experience can accumulate as data.
When that happens, we are no longer talking only about automating tasks with an LLM. We are building systems that can operate agents at scale, measure how they work, and use that evidence to improve the next generation of agents.