Most agent failures do not come from the model being unable to reason. They come from the agent drowning in the wrong context. A terminal command returns thousands of lines, the useful signal is buried in the middle, and the next reasoning step is forced to work through noise.

That is why we use RTK as a command-output boundary for our agents. RTK sits between a shell command and the model, runs the real command, then returns the compact version the agent actually needs. For Hermes, we use the native rtk-hermes plugin instead of a hand-built shell hook.

What RTK Does

RTK is a CLI proxy. Instead of sending raw command output straight into the model context, it filters, groups, truncates, and deduplicates output before the agent sees it. The command still runs. The system still gets the same operational truth. The model just receives the useful part first.

This matters because agents perform a lot of repetitive inspection: directory listings, diffs, logs, test output, process lists, Docker state, and search results. Raw output is expensive and often low-signal. RTK turns that stream into something an agent can reason over without burning the context window.

How It Works Locally

On local developer machines, RTK belongs at the shell boundary for Claude Code, Codex, and similar coding agents. When the agent wants to inspect a repo, read a directory, check Git state, or run tests, the command should either be rewritten through RTK automatically or called through RTK directly.

The local pattern is simple:

• Use RTK for noisy command output: `git status`, `git diff`, `rg`, `find`, `ls`, test runners, Docker inspection, and logs.
• Do not use RTK as a substitute for source-of-truth checks: if the task is about live Plane, GitHub, OpenBao, or a VPS service, run the live command and let RTK compress the result.
• Respect tool boundaries: built-in file-reading tools may not pass through shell hooks, so use shell commands when compact output matters.

Locally, the biggest win is keeping the agent from pasting full diffs, full logs, and full directory trees back into its own context. The human still gets the real result when needed, but the agent does not need to carry all of it in every next step.

How Hermes Uses RTK on the VPS

Hermes is different. It is not Claude Code and it is not Codex. It has its own plugin system, so the correct path is not to recreate Claude-style shell hooks inside the Hermes data volume.

Hermes uses the native rtk-hermes plugin. The plugin registers the `rtk-rewrite` entry point, listens to Hermes' `pre_tool_call` hook, asks RTK how to rewrite the terminal command, mutates the command in place, and then lets Hermes run the rewritten command. If rewriting fails, it fails open and the original command runs unchanged.

Surface	Correct RTK path	Why
Local Claude/Codex	Shell guard or direct `rtk` command	These agents issue Bash commands locally and benefit from compact terminal output.
Hermes gateway	Native `rtk-hermes` plugin	Hermes has a plugin API that rewrites terminal commands before execution.
ZeroClaw host shell	Host-level `/usr/local/bin/rtk`	Host command work can be filtered before output is sent back to the agent.
Bravo and Charlie BusyBox agents	Do not install by default	Their local containers intentionally lack the normal developer command surface.
Cron, OpenBao, Paperclip, Fathom	Do not wrap by default	These are services and scripts, not LLM command sessions.

How VPS Agents Use It Differently

On the VPS, not every agent should get the same RTK installation. The right question is: where does this agent issue shell commands that feed an LLM?

Hermes issues terminal commands through its own tool boundary, so it gets `rtk-hermes`. The ZeroClaw host can use RTK directly because host commands often inspect Git, Docker, logs, and deployed state. Bravo and Charlie are BusyBox-style containers. Their job is not to behave like full developer workstations. They should run simple BusyBox-compatible commands locally and delegate heavier host or repo work through Hermes or the host command boundary.

That distinction prevents two bad outcomes:

• Installing a developer CLI into minimal agent containers that were intentionally kept small.
• Wrapping runtime services that are not part of an LLM command loop.

What We Do Not Wrap

RTK is for the model-facing side of command output. It is not a general infrastructure wrapper.

We do not put RTK in front of cron jobs, OpenBao, Paperclip, Fathom, background services, web workers, or production runtime scripts by default. Those systems need stable, predictable process behavior. If they produce too much log output, that is a logging or observability problem. It is not a reason to place an LLM output filter in front of a service.

Why This Matters

Agents are only as good as the context they carry forward. If every tool call floods the model with raw output, the agent spends its reasoning budget cleaning up the transcript instead of making the next correct decision.

RTK gives us a sharper boundary. Local coding agents see compact Git, file, and test output. Hermes uses a native plugin that fits its actual architecture. VPS agents stay lean and delegate heavy work to the right layer. Runtime services keep running normally.

That is the real pattern: reduce context noise without blurring system responsibility.

Sources

• RTK GitHub repository
• rtk-hermes GitHub repository
• Hermes, ZeroClaw, OpenClaw, and PicoClaw comparison