A Critter Stack release day with AI agents, CI queues and a Marten memory fix
Jeremy D. Miller keeps a running diary of a Critter Stack release day: Claude agents spread over several repositories, GitHub Actions runner queues, local test gating and a client-reported Marten memory issue. The post is a useful look at the bottlenecks that show up when agents multiply the work a single maintainer can attempt.
Key points
- Wolverine now has 46 separate GitHub Actions test workflows and Marten around 30, so a single Wolverine PR can sit in the runner queue for over two hours at busy times.
- Miller turned Actions off for the day and brought it back only as a release gate, moving most verification into local CommitGate/PushGate scripts.
- Stoat was extended to drain in-flight work before heavy stress runs and to know whether CI is currently enabled before auto-merging.
- A client-reported memory problem in Marten was reproduced with a stress test and opened as a PR that replaces a community approach he judged deadlock-prone.
- Bobcat Supervisor, built on the Microsoft Testing Platform, adds visibility into long test runs, flags flaky tests and can reset Docker so agents don't stall on hung suites.
- Community PRs are triaged four ways; a partial index for Wolverine's scheduled messaging went in without an opt-in flag because the schema change is purely additive.
Jeremy D. Miller logged a whole Critter Stack release day to show how he runs Claude agents across six or seven JasperFx repositories and about a hundred NuGet packages. The plan lives in Stoat, his work-in-progress agent orchestration tool, but the real bottleneck is GitHub Actions: a single Wolverine pull request can wait two hours for a runner, so CI was switched off for the day and kept only as a gate before publishing.
The day also produced a real fix: a client's memory pressure reports turned into a stress-tested Marten change that avoids a locking approach he feared could deadlock. Community pull requests are sorted into four buckets — merge, merge with follow-up, superseding PR, reject — and agents are asked to add tests before contributions land, because contributors optimize for their own scenario.
Real-world use
- An OSS maintainer running a dozen repositories who needs pull request verification to stay fast while runner queues and costs grow.
- A team that keeps a local test-gating script so coding agents can iterate without waiting on cloud CI for every commit.
- A high-volume Marten/PostgreSQL system that shows memory spikes during rollouts and needs before/after stress measurements.
- A supervisor agent that must not start two heavyweight test suites at once on a single developer machine.
Why it matters
Agent-assisted development multiplies both CI time and machine memory use, so the limiting factor stops being how many agents you can start and becomes the guardrails: local gating, release-only CI and resource-aware agents.