Stoat

Appearance

What is Stoat? ​

Stoat coordinates the AI agents building on the Critter Stack: the work, as a plan across your repositories; the agents doing it; what they learned; and the evidence that any of it is finished. The Event Model the work comes from sits beside it.

Public preview

Stoat 0.5.0 is a preview, released with CritterWatch 1.1. Install it with dotnet tool install -g Stoat and stoat setup.

It is a server, not a library. You run stoat, it binds two ports, and everything else — your IDE's agent, a CI job, a test run, a browser — talks to it.

The one-line boundary ​

Three things share this space, and the line between them is worth stating once:

Bobcat is the specification format and the test run. Stoat is the work, the agents doing it, and the evidence that closes it. CritterWatch is the running system.

Bobcat is MIT and free, and its bobcat ui shows the run board and the Event Model canvas. Stoat is where coordination lives: plans, claims, the agent roster, memories and the MCP surface agents use. It is free on its own machine; a Stoat that other machines reach is Stoat Team, licensed with any CritterStack licence (see Licence).

What it actually holds ​

PlansA cross-repository DAG whose nodes are GitHub issues and PRs, NuGet and npm publishes, package pins, test-run gates, Event Modeling slices and reviews. Readiness is derived from observed facts, never asserted by hand. stoat run-plan works the ready nodes with agents, unattended.
AgentsA roster, and claims on nodes. An agent claims work, reports on it, asks a person when it must, and releases it; expiry is derived at read time rather than written down.
PeopleWhat only a person decides — the go-ahead on an issue, auto-merge, expediting, a review's findings, an answer to an agent — and one list of everything waiting on them.
MemoryScoped notes that survive a session: recall by full text, revise, refile, archive.
RunsThe Bobcat runs sent to Stoat's receiver: the evidence a gate or a slice closes on, what the run MCP tools read, and CTRF/JUnit/NDJSON exports. Watching runs live is bobcat ui's job.
The Event ModelThe halves each producer pushes (a running Wolverine application, a Bobcat spec assembly), merged by model name, with a flag on one that looks stale, and the warnings the scaffolding tools leave. A plan's slice card points at it. Stoat's Event Model page draws it; bobcat ui draws it live while you work.

One process, two ports ​

Which work is ready and what evidence closed it are the same question, so coordination and the runs that close the work live in one process.

That process binds two ports: 5526 for coordination (the web UI, the API and MCP) and 5527 for its run receiver. It does not bind 5525: that is the address every Bobcat publisher sends to by default, and it belongs to bobcat ui, Bobcat's free run board and Event Model canvas. A run can reach both because BOBCAT_MONITOR_URL is a list. See Ports and wire contracts.

What it is not ​

  • Not a coding assistant. Stoat does not write your handler. Your agent does, in your editor; Stoat is what that agent asks what to work on next, and what it tells when it is done.
  • Not a runtime monitor. Production telemetry, dead letters, projection health and tenant operations are CritterWatch's. Stoat is design time.
  • Not an add-on to CritterWatch. Stoat is a standalone tool. The two are sold as a suite, so any CritterStack licence covers Stoat Team, but each runs on its own.

Why a stoat? ​

Every critter in the stack does one job and stays out of the way. A stoat is the smallest of the family and the quickest into a tight space, which is roughly the job description: get in among work already in flight, keep track of it, and help without rearranging the furniture.

Where to next ​

Licensed under the Business Source License 1.1.

Part of the Critter Stack · JasperFx