Closed-Loop Development
Agent Machines are built so I can verify my own work. I should not ask the operator to click around, paste logs, or tell me what an endpoint returned when the machine can observe those things directly.
Default loop
- Read the repo instructions and identify the narrow behavior to change.
- Make the smallest useful edit.
- Start the relevant server, worker, or test target.
- Exercise the real surface with the right tool.
- Read failures from stdout, service logs, browser console, network traces, or database state.
- Fix the root cause and repeat until the observed behavior matches the requested behavior.
Tool choices
- Browser/UI: use
agent-browser or the browser_* toolset to navigate, snapshot, interact, screenshot, and inspect rendered UI. Snapshot before refs, and snapshot again after navigation or DOM changes.
- API: use
curl, httpx, and jq. Hit the actual route. Save the exact response shape before changing client code around it.
- Database: use
sqlite3 for local SQLite files and migration checks. Query the schema after running migrations.
- Tests: use the repo-native runner first:
node --test, npm test, pytest, go test, cargo test, or the project script.
- Logs: inspect
/.machine/logs/services/ first, then the runtime originals under /home/machine such as ~/.agent-machines/logs/gateway.log.
- Network: use
ss -tlnp, dig, curl -v, and nc to check listeners, DNS, and connection failures.
- Runtime docs: read
/.agent/llm.txt and /.agent/docs/agent-context.md before assuming which machine tools exist.
When to stop
Stop and report only when the blocker requires human ownership: missing credentials, captcha/passkey, destructive confirmation, provider outage, or an unavailable external system. Include what I tried, what I observed, and the next concrete manual step.
Anti-patterns
- Asking "can you check the console?" when service logs or browser console tools exist.
- Declaring success because code compiles while the endpoint or UI flow was never exercised.
- Adding retries or fallbacks before proving the root cause.
- Reinventing browser automation instead of using the installed browser tools.
1---2name: closed-loop-development3description: Use when building, debugging, or verifying software inside an Agent Machine. Teaches the agent to write code, run the service, hit endpoints, inspect logs, drive the browser, and iterate without asking the user to be the test harness.4license: MIT5---67# Closed-Loop Development89Agent Machines are built so I can verify my own work. I should not ask the operator to click around, paste logs, or tell me what an endpoint returned when the machine can observe those things directly.1011## Default loop12131. Read the repo instructions and identify the narrow behavior to change.142. Make the smallest useful edit.153. Start the relevant server, worker, or test target.164. Exercise the real surface with the right tool.175. Read failures from stdout, service logs, browser console, network traces, or database state.186. Fix the root cause and repeat until the observed behavior matches the requested behavior.1920## Tool choices2122- Browser/UI: use `agent-browser` or the `browser_*` toolset to navigate, snapshot, interact, screenshot, and inspect rendered UI. Snapshot before refs, and snapshot again after navigation or DOM changes.23- API: use `curl`, `httpx`, and `jq`. Hit the actual route. Save the exact response shape before changing client code around it.24- Database: use `sqlite3` for local SQLite files and migration checks. Query the schema after running migrations.25- Tests: use the repo-native runner first: `node --test`, `npm test`, `pytest`, `go test`, `cargo test`, or the project script.26- Logs: inspect `/.machine/logs/services/` first, then the runtime originals under `/home/machine` such as `~/.agent-machines/logs/gateway.log`.27- Network: use `ss -tlnp`, `dig`, `curl -v`, and `nc` to check listeners, DNS, and connection failures.28- Runtime docs: read `/.agent/llm.txt` and `/.agent/docs/agent-context.md` before assuming which machine tools exist.2930## When to stop3132Stop and report only when the blocker requires human ownership: missing credentials, captcha/passkey, destructive confirmation, provider outage, or an unavailable external system. Include what I tried, what I observed, and the next concrete manual step.3334## Anti-patterns3536- Asking "can you check the console?" when service logs or browser console tools exist.37- Declaring success because code compiles while the endpoint or UI flow was never exercised.38- Adding retries or fallbacks before proving the root cause.39- Reinventing browser automation instead of using the installed browser tools.
kevin-liu-01