ID-71 WS-4 — Headless-at-launch requirement (/idea-refine outcome, 2026-06-13)

ID-71 WS-4 — Headless-at-launch requirement

Status: Outcome of the WS-4 /idea-refine working session (queued in {71.1} RESEARCH §7.1 and lane-a-workshop-outcomes.md WS-4 / §C.1). This document settles the headless-completeness decisions that {71.1} deferred, and lands the Option C headless-agent-fleet runtime requirement (RESEARCH §3). Every decision below is settled input for {71.2} PRODUCT — the HC-numbered invariants (§3) are the testable headless guarantees PRODUCT must assert and the Checker must verify. Date: 2026-06-13. British English throughout.

1. Decisions settled this session

Four forks were put to Liam (the {71.1} §7.1 queue) plus two reconciliations the runtime research forced. All are now settled input.

#	Decision	Settled position
HR-1 Runtime	What must KH itself run at launch?	Thin trigger+delivery substrate, adopted not built: goose (Agentic AI Foundation / Apache-2.0) as the headless runtime — MCP-native, headless via Recipes + built-in cron, self-hosted on the existing IONOS/Coolify box. Pilot-gated before it is committed as the launch substrate. The bespoke-framework option is rejected; the full managed-agent fleet is the post-launch graduation, not launch scope.
HR-2 Outgoing	Outgoing-connectivity launch boundary?	Push delivery + source write-back, scoped to sanctioned destinations (HR-2a below).
HR-2a Write-back ↔ WS-6 reconciliation	Does write-back breach the WS-6 source-connector gate?	No. Launch write-back is limited to already-sanctioned destinations: the controlled local-fs canonical store, the already-live HubSpot↔Cowork connector (the client’s, ridden per WS-10 — not a KH-built connector), and push delivery (RSS / webhook / email). Net-new SharePoint/Drive source-system write-back stays WS-6-gated (local-first; uncontrolled ingestion is the WS-6 anti-goal).
HR-3 Write boundary	Can a headless agent write at launch?	Propose-writes permitted, publication human-gated. Agents may create drafts / suggestions / WS-8 “Draft content for X” resolutions into the queue; publication stays gated (WS-5).
HR-4 W9.3 ownership	Does ID-71 own the W9.3 invariant?	Delegated to the onboarding Task (WS-2 / WS-6). ID-71’s headless-complete set therefore = {O1/O4/O6 reads + W5.6}; W9.3 is cross-referenced only. The O5-detection-sweep expansion was not taken — baseline stays lean.
HR-5 Eval/observability	How does “utilise Raindrop” land?	Raindrop Workshop (MIT, local) = the fleet’s eval factory in dev/CI; authored evals are committed into KH’s ID-104 gate. Hosted Raindrop is excluded from the client-data path (WS-14 blocker); the WS-5 graduation metric is computed in-house on ID-104, using Raindrop’s Signals taxonomy (win/fail/loop/refusal-rate) as a design reference only. This confirms WS-13’s “hosted Raindrop for in-platform agents = deferred”.

2. Problem statement + recommended direction

How might we guarantee Claude completes KH’s core consumption and orientation work end-to-end, no human in the loop — without KH building and operating a bespoke agent runtime before metrics have earned it?

Direction (the thesis): KH is the headless surface plus a thin, foundation-governed runtime — never a bespoke framework. The runtime is goose (AAIF / Apache-2.0): an MCP-native agent that consumes KH’s existing remote MCP server, runs headless via Recipes

built-in cron, and self-hosts on the IONOS/Coolify box KH already operates. Background / scheduled “system-actor” workflows (W5.6 today; the fleet later) run on this runtime; interactive headless work runs on Claude’s own runtimes (Cowork / Desktop / Code / claude.ai) against the same surface. Both are first-class headless-agent forms — “MCP = ability, Skill = expertise” (WS-4). The agent fleet is born-evaluable: Raindrop Workshop authors trace-grounded evals locally, which graduate into KH’s ID-104 gate; that gate also computes the WS-5 auto-apply metric in-house. The fleet is where the O5 / O9 / O3 gaps get served without inflating the human tool count (Option C) — additive, grown per-Task, never a launch big-bang.

3. Headless-completeness invariants (for `{71.2}` PRODUCT)

The testable surface-#4 guarantee. PRODUCT asserts these; the Checker verifies them (primarily via the MCP eval L4 functional-correctness layer + the per-agent ID-104 contract).

HC-1 — Completable set. The launch headless set = { O1 find/answer reads, O4 reorientation/briefing reads (widened beyond KH state — reorient the person), O6 exposure “layers” reads (data → quality → use-today → gaps → opportunities), W5.6 re-syndication } is 100% completable through MCP + Skills with zero human-in-UI step.
HC-2 — No publication gate inside the read set; propose-writes allowed. Headless agents MAY create proposals / draft-content / suggested resolutions (the WS-8 “Draft content for X” / “Discuss options for Y” loop) into the queue; publication remains human-gated (WS-5).
HC-3 — Dual runtime, both first-class. “Headless” is satisfied by Claude’s own runtimes consuming the surface AND by KH’s thin goose runtime for scheduled / system-actor workflows. Neither is privileged; the surface is identical.
HC-4 — Bidirectional connectivity, first-class. Incoming = remote MCP (exists). Outgoing = trigger-driven push (RSS / webhook / email) plus write-back to sanctioned destinations (local-fs canonical store; live HubSpot↔Cowork). Net-new source-system write-back stays WS-6-gated (HR-2a).
HC-5 — Born-evaluable. Every headless agent ships an ID-104 eval contract; fleet evals are authored via Raindrop Workshop (local) and committed into KH’s L3/L4 + baseline harness; the WS-5 graduation metric is computed in-house (never via Raindrop cloud).
HC-6 — W9.3 delegated. W9.3 (onboarding discovery→propose) headlessness is owned by the onboarding Task; ID-71 cross-references only (HR-4).

4. Runtime + eval research verdicts (condensed)

Full briefs + citations below. Both verified live, 2026-06-13.

4.1 goose — Pilot-grade fit

aaif-goose/goose is the canonical current home, not a fork. Block donated goose to the Agentic AI Foundation (a Linux Foundation project; Anthropic is a Platinum founding member; AAIF also stewards MCP itself + agentgateway) on 2026-04-07. Apache-2.0, multi-vendor governed — KH bets on a foundation, not a single vendor.
The substrate is the product (KH builds no orchestration): native MCP client (remote SSE / Streamable-HTTP + auth headers — exactly KH’s server shape); headless (goose run, YAML Recipes with parameters / retry / sub-recipes, built-in cron scheduler); self-hosts (ghcr.io/block/goose, Docker/compose, goosed daemon) on the IONOS/Coolify box — correctly not Vercel; OTel-instrumented (OTLP/HTTP); first-class Anthropic/Claude.
Write-back = STRONG mechanism / PARTIAL turnkey connectors. Drive is first-party; SharePoint/HubSpot = bring-your-own-MCP-server or webhook (KH points its own — fine, since KH owns its MCP core). Propose-write into KH = just another remote-MCP call.
Biggest risk: a moving, code-agent-shaped product (weekly releases; goosed is a bespoke ~103-endpoint REST surface backing the desktop app, not a stable embedding contract). Mitigation: pin a version, use only the stable surfaces (Recipes + cron + remote-MCP + goose run), do not depend on goosed; pilot one recipe first. A self-signed-TLS health-probe wrinkle (issue #7685) needs configuring away on Coolify.
Verdict: Pilot — stand up one scheduled recipe (remote-MCP → Claude → one outbound write-back) on Coolify before committing it as the launch substrate.

4.2 Raindrop — Workshop-local adopt; hosted = WS-14 blocker on client data

Workshop (MIT, local-only): localhost:5899 + local SQLite, no account/key; SDK with empty writeKey ⇒ cloud POST is a no-op. OTel-native (consumes gen_ai.* spans). Headline: Claude reads the local trace over MCP, authors a code-aware eval from the real failure and loops until it passes (“self-healing eval”). Provably client-data-safe.
Hosted Raindrop (cloud, opt-in): Trajectories, Signals (server-side classifiers → win/fail/loop/refusal), Issues, Experiments, Slack triage. The longitudinal per-workflow quality metric — the thing that would earn WS-5 auto-apply — lives only in cloud; feeding it means POSTing client-data-derived trajectories to Raindrop → disqualified by WS-14. VPC (“data never leaves your infra”) is beta / partner-gated → not a constraint-satisfying option today (watch-item only).
Posture: Workshop = eval factory (dev/CI) → commit authored evals into KH’s ID-104 gate. WS-5 metric built in-house on ID-104 (Raindrop Signals taxonomy as design reference). Integration effort is low (@raindrop-ai/claude-agent-sdk + OTel v2 — near-zero code since goose already emits OTel).

5. MVP pilot (riskiest-assumption-first)

ONE goose Recipe on Coolify/IONOS: cron trigger → remote-MCP into KH (Claude) → generate one O4 briefing → (a) deliver to one outbound channel + (b) write one propose-row into KH’s queue. Instrumented with Raindrop Workshop locally; the failure-authored eval committed to ID-104.

This single slice proves HC-1 / HC-2 / HC-4 and all four must-be-true assumptions (§7) at once. If it is not slightly embarrassing in scope, it is over-built.

6. Not doing (and why)

Bespoke KH agent framework — goose IS the runtime (adopt, don’t build).
Hosted Raindrop on client data — WS-14 blocker; Workshop-local only.
Net-new SharePoint/Drive source-connector write-back at launch — WS-6-gated (HR-2a).
Auto-apply at launch — WS-5 propose-only; auto-apply is ID-104-earned, per-workflow.
The full fleet at launch — one piloted recipe; the fleet grows per graduated Task.
Owning W9.3 — delegated to the onboarding Task (HR-4).
Adding the O5-detection sweep to the baseline — kept lean; W5.2 stays its own Task (WS-10).

7. Assumptions to validate + open questions

Must-be-true (validate in the pilot):

goose remote-MCP-with-auth is production-grade (not a desktop convenience) — pilot a remote-MCP recipe end-to-end.
A goose recipe runs reliably as a long-lived Coolify daemon on IONOS; the self-signed-TLS / health-probe wrinkle is configurable away — deploy one and soak it.
Raindrop Workshop with empty writeKey performs zero trace egress beyond localhost — confirm with a one-time network sniff before any client-data trace in CI.
KH’s ID-104 baseline / variance / judge infra can compute a usable per-workflow quality metric without Raindrop cloud Signals.

Should-be-true: goose’s AAIF/LF stewardship stays genuinely vendor-neutral and maintained (no quiet single-vendor recapture or abandonment).

Open questions for PRODUCT / TECH:

~~Write-back destination scope at launch~~ — RESOLVED this session (HR-2a: sanctioned destinations only).
goose version-pinning policy + reliance on goose run / Recipes vs the unstable goosed daemon.
Thin runtime co-located on the existing IONOS/Coolify box, or its own instance/box?
Per-agent ID-104 contract shape — reuse the L3/L4 + baseline layers, or a new agent-eval layer? (Coordinate with ID-104.)

Sources (research, verified 2026-06-13)

goose: https://github.com/aaif-goose/goose (Apache-2.0; canonical home) · https://goose-docs.ai/blog/2026/04/07/goose-moves-to-aaif/ (AAIF move) · https://aaif.io (Linux Foundation; founders; hosts goose + MCP + agentgateway) · https://goose-docs.ai/docs/getting-started/using-extensions/ (remote SSE / Streamable-HTTP MCP + auth headers) · goose run / Recipes / goose schedule add (headless + built-in cron) · https://github.com/aaif-goose/goose/issues/7685 (self-signed-TLS health-probe wrinkle) · https://goose-docs.ai/docs/tutorials/goose-in-docker/ (Docker / ghcr.io/block/goose).
Raindrop: https://github.com/raindrop-ai/workshop (MIT; local-only debugger + agent-authored evals; cloud POST is a no-op with empty writeKey) · https://www.raindrop.ai/blog/introducing-raindrop-2/ (Self-Healing + VPC, beta / select-partners) · https://www.raindrop.ai/docs/workshop/overview/ · https://www.raindrop.ai/ (hosted product; Signals; pricing; SOC 2 Type II).

End of WS-4 /idea-refine outcome. Settles {71.1} §7.1; feeds {71.2} PRODUCT headless-completeness invariants (HC-1…HC-6).