KarstenSamaschke
Back to all writing

Field notes

Hayate Agent: My Harness Gets Its Own Name

The agent harness I have built in public since 23 October now has its own name: Hayate Agent, with its own GitHub organization. What it is, why it is not tied to Pi or one model, and every build log so far.

Karsten Samaschke · · 9 min read

Hayate Agent: My Harness Gets Its Own Name

秋の風 古き名を脱ぎ はやて立つ

Autumn wind. Shedding its old name, Hayate rises.

The agent harness I have been building in public since 23 October has its own name now: Hayate Agent (疾風, read hayate, a swift gale), with its own organization on GitHub at github.com/hayate-agent. Until 1 November it ran as the VanillaCore Agent Harness, or simply the VanillaCore Agent, and from 25 to 31 October I published fourteen build logs under that name. The rename already landed in the code on 1 November: release v0.1.128 carries the merge that renames the product in the README and in the user-facing text.

I think the new name is overdue. Between 24 October and the rename on 1 November, the harness went through 128 releases, from v0.1.1 to v0.1.128, under a name that belonged to something else. A project with its own release line and its own build logs deserves its own name, and the people who want to use or extend it deserve a project they can point at.

Hayate Agent announcement cover: large red brush kanji 疾風 (hayate, swift gale) centered on an indigo-black background, the words Hayate Agent in white below it, github.com/hayate-agent in small muted slate blue near the bottom, and a subtle wave pattern along the bottom edge.

What Hayate Agent is

Hayate Agent is a lightweight, persistent agent harness. Each conversation has its own queue and is processed in order, and the agent keeps working between messages through heartbeats, recurring loops, cron jobs and standing goals. I talk to it in a terminal, in Matrix rooms and DMs, or through a Hermes-compatible HTTP run API.

Pi does the model and tool work underneath. I need to be precise here, because my first post was called "A lighter harness, built on Pi", and that title is easy to read as Pi being welded in. It is not. Pi sits behind one runtime adapter, the rest of the harness talks to a small runtime interface, and the development guide calls Pi "a replaceable runtime adapter, not the product's identity". Today Pi is the only adapter that exists, and the design keeps the door open for another one.

Hayate is not tied to a single model either. Providers and models come from configuration, /model switches between them, and the endpoint is configurable, so an OpenAI-compatible server I run myself works as well as a hosted one. The configuration guide even has a per-model opt-in for OpenAI-compatible servers that only accept reasoning_effort: "none", with a homelab model as its example.

Why it gets its own name

Under the VanillaCore name, the harness looked like a side product of other work. It stopped being one a while ago, and a separate name makes that visible: Hayate is an open-source project of its own, with its own organization on GitHub.

Nothing about the history changes. The published build logs keep their titles and URLs, and links to pull requests and releases still point to the places where those happened.

The three repositories

The GitHub organization has three repositories, each with one job:

  • hayate-agent/core holds the product source and the documentation. It went public late on 1 November, and since 2 November its main branch is a public snapshot of release v0.1.143, the release that renames the package and the command.
  • hayate-agent/plugins holds the plugin adapters, from context and continuation to the Matrix gateway, review, dispatcher, subagents and memory. Core pins them by revision and per-file SHA-256 and never fetches plugin code at runtime.
  • hayate-agent/deployments is for deployment setups and is still empty. For now, the Docker Compose file and the Kubernetes examples are in core.

Both published repositories start with a fresh history and carry none of the old commits. The old history, the release line and the pull requests the build logs link to stay at git.vanillacore.net/harness/core.

Hayate Agent is open source under the Apache License 2.0, and both published repositories carry the LICENSE file.

Why it matters to me

I want an agent I can read, run and change on my own terms, with the model I choose, including a local one. My July video Own Your Harness is about that idea, and Hayate is where I hold myself to it. Self-hosting is the normal case here, not an export option: the agent runs where I run it, and providers and models are configuration, not hard-wired.

Open source matters for a practical reason. An agent that works unattended has to be readable, because when it does something I did not expect, I want to read the harness code that let it act, not a vendor's changelog.

Most agents I see today wait for the next prompt. Hayate is built to work a lot more on its own: it resumes checkpointed work after a restart, runs bounded subagents, and since v0.1.104 runs nightly improvement experiments by default. I care about the stops as much as about the autonomy, and most of the build logs are about them. The harness checks a model's "completed" against the original task, a paused job stays paused when someone tidies up the configuration, and after up to three recovery tries the job stops and asks instead of guessing.

How to start

You need Git and Node.js with npm, on Linux, macOS or Windows through WSL2. The installation guide recommends Node 24.22.1 LTS and requires at least Node 22.19.0. You do not need a separate Pi installation, and you do not need root: use a checkout and an npm prefix in your home directory, not sudo npm. The native installation from the guide looks like this:

git clone https://github.com/hayate-agent/core.git "$HOME/hayate-agent"
cd "$HOME/hayate-agent"
npm ci
npm run typecheck
npm test
npm install --global --prefix "$HOME/.local" .
export PATH="$HOME/.local/bin:$PATH"
hayate-agent version

npm ci also builds the CLI. The global install links to this checkout, so keep it where it is, and put the PATH line into your shell profile. Then start the agent in any project:

cd /path/to/your/project
hayate-agent

That opens the terminal interface in the current directory, with a fresh conversation for that workspace. /login connects a provider, /model picks the model, and /sessions or /resume takes you back to an earlier conversation. Existing Pi settings in ~/.pi/agent are reused, or from PI_CODING_AGENT_DIR when that is set. No init step is required. The agent keeps its state in ~/.hayate-agent and its configuration in hayate-agent.yaml. hayate-agent run starts the same agent without the terminal interface. To keep it running as a background service, put it under systemd, launchd or another supervisor. For Docker Compose and Kubernetes, the installation guide in core has the steps.

The build logs so far

These posts cover the foundations:

These are the build logs:

The morning and evening build logs continue under the new name, with the same rule as before: what merged, what I tested, and what is still missing.

Sources used