The harness was already there. Take the coding out.

Two rows are domain-specific and the rest is general infrastructure that took real work to build. The interesting question is not "how do I write an agent loop" but "why would I write a second one". If a coding agent exposes its extension surfaces, remove the two coding-specific parts and supply your own. That subtraction is the fastest path to a non-coding harness.

The harness this builds

The user is a support lead, an ops person, or a PM. They have a question in plain English, "how many accounts churned in June?", and no SQL. The harness inspects the schema and writes one guarded read-only SELECT. It runs the query against a replica, sanity-checks the result, and answers in a sentence with the number in it. The extension appends every question and every query that ran to an audit log.

$ ./bin/pi-sql -- "how many accounts churned in June 2026?"

→ list_tables()          accounts, subscriptions, plans, events
→ describe_table(events)  id, account_id, kind, occurred_at
→ run_query(SELECT COUNT(DISTINCT account_id) FROM events
             WHERE kind='churn' AND occurred_at >= '2026-06-01' …)

142 accounts churned in June 2026.

--no-builtin-tools drops read, write, edit, and bash at the pi layer. That flag is not cosmetic. It leaves the agent no general-purpose way to touch the filesystem or shell out. So the only verbs it has are the ones you register. An agent whose entire vocabulary is four domain tools cannot wander, because there is nowhere to wander to.

The replacement system prompt lives in .pi/SYSTEM.md and pi loads it from the project. Note what the launcher therefore does not need to do:

# No --system-prompt here: pi loads the replacement prompt from
# .pi/SYSTEM.md on the mounted repo (strategy A).

That comment records a design decision. The prompt is a file in the project, not a flag in a launcher. So you can review it, diff it, and version it with the tools it describes. A system prompt passed as a command-line argument is a system prompt nobody reviews.

1. list_tables Tables plus row counts. The agent has no ls, so this tool is how it finds out what exists at all.
2. describe_table Columns and types for one table, and only for a name that appears in the live schema. Introspection without a path to arbitrary interpolation.
3. run_query A single SELECT, capped in rows and bytes, audited on every call. The one tool with real power, and therefore the one with the guard on it (rung 3).
4. save_finding Append a record to sql-output/findings.jsonl. The only write in the whole harness, and it goes to a mounted output directory, not anywhere the data lives.

Registration is ordinary, and the plainness is the point. pi.registerTool five times and pi.registerCommand("ask", …) once, in a single TypeScript file. There is no agent loop in that file, no retry logic, no context management, no renderer. All of it comes from pi.

1. Belt 1 The connection. node:sqlite opened with readOnly: true. SQLite rejects every write at the engine level, so this belt holds even if the other two have a bug.
2. Belt 2 The statement guard. A single SELECT or WITH only. Defense in depth: it gives the model a clean reason string instead of a raw SQLite error it cannot interpret.
3. Belt 3 The whitelist. The extension checks table names against the live schema before it interpolates them. Schema introspection therefore cannot become a string-building primitive.

The guard is worth reading closely, because the interesting part is not the keyword list. It is the scrubbing that happens first.

function scrub(sql: string): string {
	// Neutralize comments and string/identifier literals so keywords or
	// semicolons *inside* them don't trip the checks below.
	return sql
		.replace(/--[^\n]*/g, " ")
		.replace(/\/\*[\s\S]*?\*\//g, " ")
		.replace(/'(?:''|[^'])*'/g, "''")
		.replace(/"(?:""|[^"])*"/g, '""');
}

function checkReadOnly(sql: string): { ok: boolean; reason?: string } {
	const raw = sql.trim().replace(/;+\s*$/, "");   // allow one trailing ';'
	if (!raw) return { ok: false, reason: "empty query" };
	const scrubbed = scrub(raw);
	if (scrubbed.includes(";"))
		return { ok: false, reason: "multiple statements are not allowed" };
	const head = scrubbed.replace(/^[\s(]+/, "").toUpperCase();
	if (!/^(SELECT|WITH)\b/.test(head))
		return { ok: false, reason: "only SELECT / WITH queries are allowed" };
	if (FORBIDDEN.test(scrubbed.toUpperCase()))
		return { ok: false, reason: "query contains a forbidden keyword" };
	return { ok: true };
}

Without scrub, belt 2 rejects a legitimate query that contains the word "update" inside a string literal. It also reads a semicolon inside a literal as statement stacking. A guard that produces false refusals on valid work is a guard the operator eventually removes. The scrubbing is therefore what keeps the belt in place.

The guard has a runnable spec

The repo duplicates the rules as plain JavaScript in docker/sql-guard.test.mjs. The source carries a comment saying so, and saying that changing one means changing the other. That duplication is a deliberate trade: the spec runs in the container. A security rule with a runnable spec beats a rule with a single definition and no test.

Skills load on demand, so the method costs nothing on turns that do not need it. The description is the trigger, and it names a set of conditions rather than a topic:

name: analytics-playbook
description: Plain-English-to-SQL answer loop (understand the question →
  inspect schema with list_tables/describe_table → write one guarded SELECT →
  run_query capped → sanity-check → answer in one sentence and save_finding).
  Load when the user asks a data/business question, asks for a
  count/total/breakdown, or invokes `/ask`.

Two details in that description are worth copying. It spells the loop out as an arrow chain, so the model has the method before the body. And the load condition names three concrete triggers instead of "load when relevant". That vaguer instruction produces skills that never load or always do.

Where the method lives, and why not in the system prompt

1. System prompt Who the agent is and what it must never do. Always resident, so it stays short.
2. Skill How to do the job, in detail, including the sanity-check step. Loaded only when a data question arrives.
3. Prompt template /ask. The user-facing surface. It exists so a non-engineer has one thing to type and does not have to phrase a good agent prompt.

docker_args=(
	run --rm -i
	--read-only                       # rootfs is immutable
	--tmpfs /tmp:rw,size=64m           # the only scratch space
	--cap-drop ALL
	--security-opt no-new-privileges
	-v "$here":/work
	-v "$db_path":/data/analytics.db:ro   # the one host artifact, read-only
	-e ANTHROPIC_API_KEY
	…runs as a non-root user
)

Read the mount list rather than the flags. Exactly one host artifact reaches the harness: a database file, mounted read-only. Not a home directory, not a source tree, not an SSH agent socket. Most of what makes a container safe is what you decline to mount into it.

Ergonomics that decide whether it gets used

• Builds on first run. No separate build step to forget.
• Seeds the sample database on first run, as the host user. You own the file, so you can mount it read-only.
• Allocates a TTY only when stdout is one, so the same launcher works interactively and in CI.
• Takes a different database as an argument, so a real replica is a path, not a rebuild.

1. WebSocket A live terminal in the browser. For the person who wants to ask follow-up questions and watch the agent work. ttyd in front of the same launcher.
2. REST One question in, a text answer out, no session. For scripts, dashboards, and the Slack bot somebody will inevitably build. shell2http in front of the one-shot mode.
3. Edge nginx terminates TLS, enforces basic auth, and routes both paths. The harness itself does not know that authentication exists, which is the correct division.

Rung 5 built the one-shot mode for CI. That mode is what makes the REST adapter a configuration file rather than a service rewrite. Nobody planned that reuse: it happens when you write the launcher to work when stdout is not a terminal.

The six surfaces, end to end

Where this sits

1. Guardrails Five guardrails constrains a stock coding agent doing coding work. Same substrate, unchanged job.
2. This page Same class of substrate, different job. These surfaces change what the agent is for, rather than fencing in what it already does.
3. Neighbours Promotion to the harness builds an agent loop from parts instead of inheriting one. Building a harness with iii is the other direction again: many small durable nodes rather than one reshaped agent.