Loomworks — Agent-Commissioning Chain Note — v0.1

Date: 2026-08-16 Status: Extension note to the agents-as-output-of-an-engagement thread Consumer: Future Claude chats scoping the third investigation arc; Operator as reviewer Canonical home: loomworks-record

Plain-language summary

The Operator proposed a two-engagement chain: Engagement 1 receives a request and description for an agent, and produces a seed for Engagement 2; Engagement 2's work is building that agent. This note records why the chain is architecturally sound, what parts already exist, what parts do not, and the staged test plan the Operator has elected to run. It extends — does not replace — the open agents-as-output-of-an-engagement thread.

1. The proposed chain

• Engagement 1 (commissioning engagement). Input: a request and description for an agent. Output: a candidate seed for Engagement 2. Rendering Mode A — Loomworks produces the artifact (the seed) directly.
• Engagement 2 (agent-build engagement). Work: build the agent per its seed's commitments. Output: an agent specification a downstream production system consumes. Rendering Mode B — Loomworks produces the specification; Loomworks does not execute the agent.

2. Why the chain is sound

• Seed-as-render is settled. "Engagement seed" is a declared render-type in the Loomworks seed. The Phase 53 Discovery-to-seed pipeline (extraction skill, POST /engagements/{eid}/seed/extract, induct_seed hand-off) is the built mechanism for producing an inducted engagement from a Discovery document.
• Agent-as-output boundary is recorded. Rendering Mode B produces the agent specification; the agent is self-attesting by construction; Loomworks does not implement loop or graph orchestration internally (rejected alternative, preserved).
• Cross-engagement seam requires nothing new. Engagement 2's founding provenance is its inducted seed, which carries drafter's-notes provenance back to the Discovery material. Cross-engagement references remain non-transitive by default.

3. Alternative considered and set aside

A single engagement carrying two declared render-types (candidate-seed and agent-specification) could hold the same work. Set aside because the two-engagement split earns its keep when Engagement 1 generalizes — one commissioning engagement spawning many build engagements over time, each with separate Memory scope, contributor roster, and authority. Operator confirmed the two-engagement direction.

4. What exists and what does not (per record, 2026-08-16; CC verification pending)

Exists (per Phase 53 CR and completion record):

• Phase 16 upload accepts text/markdown.
• Discovery-to-seed extraction skill (single-shot, gap-marking, no fabrication).
• POST /engagements/{eid}/seed/extract — extraction plus immediate induct_seed hand-off.

Does not exist:

• Candidate-seed render specialist (declared in seed v0.8; Phase 9/10 did not land it; deferred Phase 54+). Without it, Engagement 1 cannot yet produce the seed as a governed Render.
• Agent-specification declared render-type and registered specialist (the Mode B output for Engagement 2).
• Verified answer on whether /seed/extract inducts into the path-parameter engagement or creates a new engagement. This determines whether the current mechanism supports the chain shape directly or only the single-engagement bootstrap.

5. Staged test plan (Operator-elected)

• Stage 1 — now, after CC readiness inspection. Commission Engagement 2 via the Phase 53 route: Operator and Claude author a Discovery document describing the requested agent; upload; extract; induct. Verifies the seed-for-agent-build half live.
• Stage 2 — small change request. Declare the agent-specification render-type in Engagement 2's seed, register a specialist, run contributions through Memory, Manifestation, Shaping, and a Mode B render producing the agent specification.
• Stage 3 — later. The true two-engagement chain: candidate-seed render specialist in Engagement 1, so the seed itself is a governed Render rather than a route side-effect.

6. Open questions carried unchanged from the parent thread

1. Does the derived agent's output flow back into Engagement 2's Memory as an inward provenance thread?
2. Is the derived agent stale when Engagement 2's Memory moves past the state it was specified from?

Both attach to Stage 2 and beyond; neither blocks Stage 1.

DUNIN7 — Done In Seven LLC — Miami, Florida Agent-Commissioning Chain Note — v0.1 — 2026-08-16