Indie agent builders, August 15-22: the agent is becoming a recorded system
This week's strongest builder signals turn hidden agent state into inspectable artifacts: local sessions, sandbox workflows, planning maps, capability boundaries, policy decisions, audit rows, and context diffs.
The week in one line
From August 15 through August 22, the most useful agent-building work was not another claim about autonomy. It was a set of ways to make an agent's hidden state inspectable: a local model's reasoning and tool loop, a sandbox's execution boundary, a planning map, a capability stack, a policy decision, and the exact context sent over the wire.
This issue favors direct builder posts, original project documentation, and repository history. The point is not to rank products. The point is to show what an engineer could actually inspect, copy, or falsify.
The map
| Signal | Builder or project | When | Inspectable artifact | First test |
|---|---|---|---|---|
| Local coding loop | Simon Willison + Qwen 3.8 27B | Aug 16 | Pi session, models.json, reasoning traces | Run one repo task at low reasoning effort |
| Sandbox fallback | Simon Willison + Fable 5 + smolvm | Aug 19–20 | GitHub Actions workflow and test logs | Move one disposable transform behind an explicit boundary |
| Planning under uncertainty | Matt Pocock's /wayfinder | Aug 20 | Map, typed ticket, session | Separate global context from task context |
| Composable harness | Pydantic AI Harness | Aug 17–22 | Capability list and recent safety commits | Remove capabilities until the boundary is clear |
| Governed computer use | CopilotKit OpenBot | Aug 19–22 | AG-UI endpoint, gateway decision, audit row | Deny one action and verify the record |
| Context inspection | jianshuo/ccglass | Aug 22 | Proxy capture, turn diff, replay export | Diff a failing turn before changing the prompt |
| The new bottleneck | Simon Willison | Aug 19 | Design decision log and review checklist | Review the next feature for conceptual drift |
The entries are deliberately different kinds of evidence. Simon's timings are a single builder's measurements. Qwen's benchmark numbers are Qwen's own report. Project READMEs describe what their authors intend to ship. Commit histories show that code moved, but they do not constitute a security audit.
1. A 17 GB local model can drive a real coding loop
Simon Willison's August 16 test of Qwen 3.8 27B is interesting for a narrower reason than the model announcement. It asks whether a model small enough to keep on a capable laptop can handle the parts of an agent loop that matter: long context, code generation, tool calling, and enough reliability to navigate an unfamiliar repository.
The setup was concrete. Simon ran a 17 GB Q4_K_M build through LM Studio on an M5 Max MacBook Pro and an NVIDIA DGX Spark. He connected Pi to the local model, then asked it how authentication worked in the Datasette codebase. The resulting session used reasoning and tool calls across multiple files and produced what he describes as a solid explanation. When he wanted to publish that session, he gave the JSONL transcript to the same setup and it built and tested
pi_jsonl_to_md.py.That chain is more useful than a one-shot coding demo because it leaves artifacts at every step: the Pi provider configuration, the session transcript, and the small utility that converted it to Markdown.
The catch is the default reasoning setting. Qwen 3.8 27B defaults to
xhigh; Simon found that it spent 22,276 reasoning tokens and 21 minutes producing a 3,223-token SVG for a pelican riding a bicycle. With reasoning disabled, a related run took 137 seconds. In the coding-agent test, he also reports roughly 15–30 tokens per second on his machines. Those are Simon's snapshots, not a general benchmark, but they expose a practical control knob: reasoning depth is part of the harness configuration, not a property to accept blindly.He also reports a roughly 72% improvement in a comparative Spark benchmark when using
llama.cpp's draft Multi-Token Prediction setup instead of the default GGUF server. Again, that is an announcement-time, builder-run comparison. The reproducible part is the server command and benchmark transcript, not the implied performance on your hardware.Why it matters: local models are becoming viable for agent tasks before they become pleasant as interactive assistants. The relevant question is no longer only whether the model can call a tool. It is whether the engineer can choose a reasoning budget, preserve a long enough context, inspect the resulting session, and accept the latency for the task at hand.
Try it: run one small repository-orientation task with Qwen 3.8 27B or another local model. Start at low or no reasoning, save the complete session, then repeat at a higher setting. Compare tool-call success, context growth, wall-clock time, and tokens per second. Do not compare only the final prose.
2. When the sandbox cannot run, the agent moves the test to CI
The strongest detail in Simon's smolvm sandbox research is not the benchmark. It is the recovery path.
The research task was to test whether smolvm could run untrusted Python and JavaScript data transformations with no network access, bounded CPU and RAM, controlled filesystem access, and protection against an infinite loop. smolvm uses hardware-isolated VMs rather than shared-kernel containers. Simon reports that offline images, resource limits, guest-enforced timeouts, storage quotas, read-only inputs, writable outputs, and
--unprivileged behaved as intended. His post reports cold starts around 0.6–1.5 seconds and warm executions around 50 milliseconds; those figures are his test results for smolvm 1.8.3, not a promise for every host.Claude Fable 5, running in Claude Code for web, could not run the experiment directly. Simon's environment had no
/dev/kvm and no virtualisation flags, so smolvm machine run failed with kvm not available. The agent did not stop at the error. It wrote a temporary GitHub Actions workflow on the research branch, installed smolvm on a runner that exposed KVM, executed the test battery, and collected the results. Simon also shared the episode in an August 20 X post.That is a useful pattern for agent builders: treat the execution environment as a capability that can be absent, and make the fallback an explicit, reviewable artifact. It is different from giving the agent a vague instruction to “try somewhere else.” The workflow records where the experiment moved and what commands it ran.
The boundary still needs review. A CI runner is not automatically a safe place for untrusted code. The workflow's permissions, secrets, network access, retention of logs and artifacts, runner trust model, and cleanup behavior all become part of the sandbox design. smolvm's isolation properties and GitHub Actions' environment properties are separate claims.
Why it matters: an agent that can recover from a missing capability is more useful, but the recovery must also make authority visible. “The model found a workaround” is not the engineering result. “The model created a workflow with a declared runner and a test script that a human can inspect” is.
Try it: put one disposable data transformation behind a temporary workflow. Before running it, write down the allowed files, network policy, CPU and memory limits, timeout, token and secret exposure, and artifact retention. If the agent moves the test, require it to produce the workflow and the resulting logs as part of the deliverable.
3. /wayfinder turns an unclear project into a planning protocol
Matt Pocock's new
/wayfinder skill addresses a problem that appears before the usual coding-agent loop: the human does not yet know what the plan should be.In the August 20 Latent.Space interview, Pocock describes using agents away from the keyboard. He already had a process for turning a known plan into specifications and tickets. The bottleneck was making the plan when the project was still a “fog of war”: the destination was not clear, and managing many research and planning sessions consumed the context budget before implementation began.
The skill's key move is to separate three artifacts:
- a map containing the decisions and the wider shape of the project;
- a ticket containing the specific work for one session; and
- a session containing the discussion and result of that work.
The vocabulary is not decoration. Pocock argues that the agent needs stable leading terms so that a child session knows what belongs to the global map and what belongs to its own ticket. The skill can create different ticket types for grilling, prototyping, research, and human tasks, then orchestrate those threads and pull their results back into the project plan. His repository history shows the skills collection actively changing during this window, although the history around
/wayfinder is not a controlled evaluation of the workflow.Swyx called the skill “/wayfinder for the fog of war” while sharing the interview. That post is a useful signal about the pattern's relevance, not independent evidence that the skill improves project outcomes.
Why it matters: many “agent memory” failures are really information-flow failures. A child session receives either too little context to make a decision or the entire project history, which wastes tokens and hides the local task. The map/ticket/session split gives the builder something inspectable to tune.
Try it: take one greenfield task that you cannot fully specify. Create a short map, open one research ticket and one prototype ticket, and keep each child session scoped to its ticket. At the end, inspect whether the map gained a decision, whether the ticket gained an actionable next step, and whether the session can be discarded without losing project context.
4. Pydantic AI Harness makes capabilities the unit of composition
The Pydantic AI Harness is not a new wrapper around one model. Its README presents a different unit of design: a capability that can be snapped into a typed agent, composed with other capabilities, or removed from a larger agent stack.
The repository's
Coder capability combines workspace-rooted file access, an allowlisted shell, repository orientation, structured planning, a read-only explorer sub-agent, and context controls. The same repository exposes the pieces separately. That makes the harness legible in a way a large “autonomous coding agent” prompt is not: an engineer can ask which capability granted a tool, which path it can reach, which commands are allowed, and what happens when the context approaches its limit.The timing of the repository activity is the signal. Its commit history shows changes from August 17 through August 22, including
FallbackCompaction for failure-based strategy chains, returning recoverable filesystem failures to the model, preventing absolute host-path leakage, adding an async PlaywrightBrowser capability, and hardening capability defaults and execution boundaries. The same history includes a fix to prevent write_file from blocking on FIFOs and a change to propagate UsageLimits into nested summaries.GitHub showed 802 stars on the repository page when this issue was researched. That is a retrieval-time snapshot, not a measure of quality or adoption, and the README's capability descriptions are project claims rather than an independent security audit.
Why it matters: composition is only useful when the boundaries remain testable. A capability stack gives an engineer a place to put an allowlist, a timeout, a path check, a compaction policy, or a failure mode. It also makes the removal test possible: if the agent stops working when one capability is removed, the dependency is explicit instead of hidden in a prompt.
Try it: start with the Coder stack, then remove one capability at a time. Test path traversal, symlink behavior, FIFO writes, oversized tool output, browser access, and a restarted long-running task. Record which capability made each test pass or fail. That inventory is more valuable than a single end-to-end success run.
5. OpenBot puts the governance layer between the agent and the computer
OpenBot is the week's clearest example of a product treating computer use as a governed execution surface rather than as a hidden browser tool. Atai Barkai's August 19 launch post describes an open-source Grok Bot that works with any agent harness, supports computer use and human handoffs, and records the data for the operator. The official project page and repository make the more concrete claim: the platform runs inside the user's infrastructure and accepts any agent that speaks AG-UI.
The repository's architecture puts a gateway in the path of every action. The gateway resolves the target, evaluates policy, writes an audit row, and only then calls the Bot's computer, or refuses the action and names the rule. Each Bot gets its own container, workspace volume, browser profile, and credentials boundary. A person can watch the screen, take control at a login or 2FA wall, and hand it back. The repository exposes separate surfaces for boundaries, computers, credentials, plugins, and audit events.
The project was changing quickly during the window. GitHub showed 2.3k stars and commits on August 16–22 when retrieved, including changes related to computer lifecycle, authentication, shell access, AG-UI responses, and keeping an unanswered request from outliving its run. Those repository figures and feature descriptions are project evidence, not proof that the system is ready for production. The README labels OpenBot Alpha and lists real prerequisites: Docker, Bun, a CopilotKit Intelligence project and license, and a model key.
The important design choice is the protocol boundary. An agent built with LangGraph, Mastra, CrewAI, Pydantic AI, Google ADK, or hand-written code can arrive as an AG-UI endpoint. The governance layer does not need to know which framework produced the next tool call; it needs to know the target, the intent, the actor, and the policy decision.
Why it matters: “supports any harness” is only meaningful if the controls sit outside the harness-specific prompt and tool adapters. OpenBot's proposed seam is a policy and audit gateway that can refuse an action before execution and preserve the refusal as evidence.
Try it: connect one existing AG-UI agent to a disposable OpenBot deployment. Deny one browser or MCP action, trigger a login wall, take the wheel, and inspect
/admin/audit. Verify four things separately: the action was denied, the reason was recorded, the human takeover was recorded, and no secret entered the transcript.6. ccglass makes the context the agent receives visible
Dan Kornas announced
ccglass on August 22 with a simple diagnosis: a coding agent sends more context than the operator can see. The project is a local logging reverse proxy and web dashboard for inspecting requests from Claude Code, Codex, OpenCode, Kimi, and other clients. The repository README shows how it works and where its edges are.ccglass starts a local proxy, points a supported client at it through the appropriate base-URL setting, and opens a dashboard. The capture includes the system prompt, message history, tool schemas, tool calls, and tool results. The dashboard pairs tool use with its result to show the agent loop, compares two turns to reveal new context and cache breakpoints, tracks input/output/cache tokens and estimated cost, and exports a request as raw HTTP, Markdown, JSON, or HAR. It can also register self-inspection tools with Claude Code so the agent can query the requests it just made.That changes the debugging question. Instead of asking “why did the model suddenly behave differently?”, an engineer can ask which system instruction, tool schema, prior result, cache breakpoint, or context block changed between two requests. A saved capture becomes a test fixture or a redacted bug report.
There is an important date distinction here. The public announcement is new this week, but the repository's latest visible commit was July 9, and the README describes an existing multi-client inspector rather than a new August release. This is therefore a new builder signal about a useful tool, not a claim that the project shipped a release in this coverage window. GitHub showed 697 stars and 45 forks when retrieved; those are snapshots, not evidence of correctness.
The limitations are part of the tool's value. The README says Codex sessions authenticated through ChatGPT use a WebSocket path that bypasses the supported
OPENAI_BASE_URL interception. IDE interception requires a client that supports a custom base URL or BYOK mode. Captured logs can contain sensitive prompts and tool data, and the documented --no-redact option makes that risk explicit rather than removing it.Why it matters: observability is not only for production traces. In an agent loop, the request assembled by the harness is part of the program. If engineers cannot inspect it, prompt changes, tool changes, cache changes, and model changes are confounded.
Try it: capture one failing session, select two adjacent turns, and write down every context block that changed before touching the prompt. Export the request, redact credentials, and keep the capture as a regression fixture. If the client cannot be intercepted, use its native JSONL or trace output and preserve the same turn-to-turn comparison.
7. The new bottleneck is conceptual integrity
Simon Willison's August 19 essay on conceptual integrity is a thesis rather than a new tool. It belongs here because it names the failure mode that the other six signals are trying to make visible.
Simon argues that lines of code can sometimes be a meaningful productivity measure with agents, but only when the code is working, tested, maintainable, and of the same quality as code produced without them. Once an agent makes a new feature cheap, the constraint moves. The engineer can produce more code than they can hold in their head and review for coherence.
His phrase is conceptual integrity: software should cover the right domain, fit together, and avoid surprising new rooms. Agents make it easy to add another room because the prompt is cheap. They do not automatically preserve the shape of the house. The post is built from a lightly edited Talking Postgres transcript, so it is a builder's argument, not a controlled productivity study.
The practical connection to this week's artifacts is straightforward. A Pi transcript tells you what the local model actually did. A CI workflow tells you where a workaround acquired authority. A map and ticket tell you what a planning session was allowed to decide. A capability list tells you which tools were attached. An audit row tells you what the policy permitted. A context diff tells you what the model actually saw. None of those artifacts replaces engineering judgment, but each reduces the amount of hidden state that judgment has to guess at.
Try it: before an agent adds the next feature, write three lines: the domain boundary, the decision the feature must preserve, and the reason not to add one adjacent feature. Review the diff against those lines. If the code introduces a new concept, name it or remove it; do not let a fast implementation smuggle a new room into the system.
What to try this week
- Instrument one real run. Use
ccglasswhere its proxy path is supported, or your agent's native transcript output. Save the system prompt, tool definitions, tool results, token counts, and two adjacent turns. Treat the capture as a debugging fixture, not as a diary. - Make one risky capability disposable. Put a user-provided transformation behind a narrow sandbox or temporary CI runner. Define network, filesystem, resource, secret, timeout, and artifact-retention rules before the agent starts.
- Plan one ambiguous task with explicit information flow. Create a map, then issue one research ticket and one prototype ticket. Give each session only the map plus its local ticket, and check whether the returned decisions are enough to update the map.
- Run a removal test. Start with a composed harness, remove one capability, and observe what fails. The missing boundary is often easier to see when the tool is absent than when the full stack succeeds.
The signal to carry forward
The common pattern this week is not “more autonomy.” It is inspectable authority. Builders are moving the important questions out of an opaque model loop and into artifacts: transcripts, workflows, maps, capability lists, policy decisions, audit rows, and context diffs.
That shift gives an engineer a better adoption question than “does this agent feel smart?” Ask instead: What can I inspect when it works, what can I prove when it fails, and which boundary can I remove or tighten without guessing? The projects and experiments above give several concrete places to start.
Next Saturday's issue will continue the weekly scan of new builder posts, repositories, releases, and build logs.
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.
Related content
More from this channel
- Compaction summaries, harness mods, and five agent-builder signals from September 12-19
- WebAssembly sandboxes, shared MCP tools, and five agent-builder signals from September 5-12
- Small Macs, structured screens, and four agent-builder signals from August 29-September 5
- Sessions, receipts, rollbacks, probes: four agent-builder signals from August 22-29
- Indie agent builders, August 8-15: the control plane moves above the model
- Indie agent builders, August 1-8: the work log is becoming the interface
- Indie agent builders, July 25-August 1: the harness is becoming the product
- Indie agent builders, July 18-25: make the agent's work inspectable