To pressure-test loomcycle from the outside, we set up an isolated sandbox, installed the brew binary (v0.22.0), and drove it through a fresh Claude Code session as the operator — talking to loomcycle over MCP, with no internal shortcuts and no API access a real third party wouldn't have. Every experiment in the four-experiment series was designed in advance by us; every step was executed by Claude through the same operator-facing tool surface (spawn_run, list_agents, agentdef, interruption_resolve, ...) a community operator would see. The point of running experiments through an agent rather than a hand-written script is that the agent surfaces gaps a script wouldn't — a script does what the author wrote; an agent does what the system tells it is possible, and an honest agent surfaces every moment where the system's docs, error messages, and capability gates don't line up. This first post covers experiments 1 (tool access) and 2 (interruption). Experiment 1: a generic code-guru agent with allowed_tools [Read, Write, Edit, Bash, Grep, Glob, WebSearch, WebFetch] on deepseek-v4-pro is asked to write the first-100-primes program, save it, run it, verify. Run 1 died at Bash{mkdir -p exp1} with DeepSeek 400 "messages[3]: missing field content" — mkdir on success returns empty stdout, loomcycle's openai-compat adapter was serializing the tool-result message with no content field when the content was empty, and DeepSeek's API requires it (every other provider tolerated the omission, so the bug had been invisible against Anthropic/OpenAI/Gemini). F10 — fixed in v0.23.0 (#379, RFC Q): always serialize content on tool messages, defaulting to empty string when actually empty. Run 2 passed cleanly; independent verification confirmed exactly the first 100 primes (0 mismatches, first/last 2/541). Plus F13 surfaced: Write resolves relative paths against process CWD, not LOOMCYCLE_WRITE_ROOT — with the server launched from project root, Write exp1/... split from Bash's BASH_CWD=./work. Operationally fixed by launching loomcycle from the jail directory. Experiment 2: yesno-agent asks "Approve the deployment?" [Yes,No], blocks until resolved, branches on the answer. Both passes worked end-to-end (Claude self-resolves, then marshals to human via Claude Code UI; human answers; agent wakes and branches correctly). But the first resolve attempt — via the plugin's MCP server — left the run blocked despite flipping the DB row to "resolved." F15: Interruption.ask blocks on channels.Bus.Wait, an in-process bus; the resolve handler calls bus.Notify on whichever process received the resolve. The plugin MCP and the HTTP server were two separate processes — same SQLite store, separate in-process buses. The plugin's bus.Notify woke no one. v0.23.0's thin-client topology (RFC R, #381) dissolves this: loomcycle mcp --upstream proxies to a single full runtime, so the cross-runtime pattern that triggered F15 stops arising in normal use. The breaking change (#383): loomcycle mcp --no-http removed. The engineering lesson: provider-adapter correctness is load-bearing in a way unit tests miss. The F10 bug had been live in internal/providers/openai/serialize.go for months. Unit tests against the OpenAI API (which tolerates the missing field) passed; integration against DeepSeek (which doesn't) had never been exercised on a Bash that returns empty stdout. Hand-written integration tests would have had to know to send empty content deliberately; an agent doing mkdir -p sends it accidentally on the first call. Every provider in provider_priority now passes an end-to-end smoke test where the agent's first tool call returns empty stdout.
OpenScience: Workbench for scientific research using custom LLMs