From a Book About Agents to a Book Built with Them

Agentic software development is difficult to explain as a list of model features. The useful questions are practical: how does work survive when a session ends, how can parallel agents avoid collisions, and what happens when a green test suite misses a real workflow failure? The Ubunatic Books repository turns those questions into a local-first library of chapters, examples, and working reference material.

The project began as documentation and slide publishing infrastructure. Its sources include three mdBooks, a custom Go slide compiler, a local website landing page, a style test book, and a browser demo built around DuckDB compiled to WebAssembly. The books cover agentic practices alongside language guides and research material. The website and generated readers are designed to work without a content delivery network. The repository’s Make targets coordinate rendering, link and rule checks, PDFs, and placement validation.

In late summer 2026, the library began documenting a wider change: agent work had become a multi-repository operation. The chapter “The Multi-Agent Fleet” describes fresh handoffs, measured context costs, tool output filtering, issue reservations, and the gap between passing unit tests and a functioning live hook. On October 3, commit af74dc2 added a chapter about guardrails for multi-repo workflows. It explains how an ordinary command line should handle fuzzy requests without moving model latency into keystroke completion, and how bounded interfaces can connect separate tools.

One episode in that chapter captures the value of dividing work and reviewing evidence. During a sprint, a simulated HTTP timeout test left its server handler waiting indefinitely; the Go test eventually hit its ten-minute timeout. The documented fix bounded the handler’s wait with context cancellation. Two other failures involved a mismatch between a model’s abstention token and the test’s expected schema, and ambient classifier logging that broke older CLI assertions. Those are small defects individually. Together, they show why an agent workflow needs explicit test seams and a human reviewer who understands what the test is proving.

The chapter records a plan-first sequence: a worker first proposes files, schema decisions, and test cases while read-only; the host reviews that plan before granting write access. It also describes a quota of one full test run, followed by inspection and one re-verification when failures appear. This is not a claim that agents eliminate engineering judgment. It is a design for concentrating judgment at boundaries: the ticket, the proposed plan, the verification evidence, and the final diff.

The repository makes those ideas durable in several ways. Issues provide task records and follow-up queues. Agent instructions establish verification and handover expectations. Evergreen docs describe toolchain and publishing details. The book itself includes candid reports of failures, including cases where tests passed against unrealistic workflow assumptions. Recent history shows seven commits in six weeks, including two substantial chapters and a September documentation sweep. The current source set contains 27 Markdown chapters and 10 Go test functions for the slide compiler; this is a focused documentation and publishing project rather than a broad application test suite.

For a small team, agent contribution is most plausible in breadth and parallel research: chapters can synthesize evidence from several repositories, reviewers can probe a chapter from different professional perspectives, and the editorial backlog can hold findings until they are checked. The repository provides evidence of that breadth through its review tickets, cross-project stories, and documented multi-agent episodes. It does not establish that every historical claim in those chapters was independently reproduced during this review, so the stories are best read as a working engineering record with cited artifacts, not as a benchmark report.

The result is both a library and a record of how the library is maintained. Its strongest lesson is that agents become useful collaborators when their work leaves behind inspectable artifacts: a ticket, a plan, a test, a commit, or a written account of what failed.

Facts