Version. 0.1 Date. 2026-05-06 Status. Investigation. Thinking material for architectural decision. Author. Claude.ai (investigation layer). Operator: Marvin Percival. Provenance. Conversation initiated by the Operator's question about whether an agent could be spawned to manage a render process and report to the Companion. The Operator's correction — that the agent should report to the Companion, not be the Companion — is the load-bearing insight this investigation develops. Informed by. Companion as agent investigation v0.1 (capability tiers, delegation contract, protocol triangle). Operator Layer discovery v0.4 (Specialist SDK, three populations, specialist registry and discovery). Engine implementation strategy v0.2 (Phases 34–40, Arc 6). Phase 34 CR v0.2 (external service polling, ExternalProductionHandle). Phase 45 CR v0.1 (delegation contract, approval cards, OVA seam). Phase 10 CR v0.1 (RenderDispatchAgent, specialist registration). Queued directions v0.1 (external rendering services, metadata-driven runtime). Loompa five threads v0.1 (factory metaphor — the factory is the protocol, not the candy). Current status manifest v0.30.
The initial response to the Operator's question proposed that the Companion itself manage render processes directly — fire the render, monitor polling, evaluate failures, report to the Operator. The Companion as both relationship manager and process supervisor.
The Operator said: an agent should be assigned to a render process, manage it, and report to the Companion. The Companion manages the Operator relationship. The agent manages the process. Two concerns, two entities.
The prior position makes the Companion a monolith. Every new process domain (render supervision, shaping supervision, contribution assessment, external service management) adds judgment, state-tracking, and failure-handling logic to the Companion. The Companion grows in complexity with every capability.
The corrected position makes the Companion a manager. Every new process domain is a new subordinate agent type. The Companion's complexity stays approximately constant — it manages agents, not processes. The growth is in the agent population, not in the Companion's brain.
This is a structural distinction. The Companion-as-monolith scales linearly with capability. The Companion-as-manager scales with management capacity, which is a much flatter curve.
"Agents are probably better suited to managing very small and uncomplicated processes as well as large, long running, complicated ones." This extends the pattern beyond render supervision. It says: the agent fabric is the general mechanism for process management in Loomworks, at every scale. A two-second inline render and a three-day application build both get agents. The agent's complexity matches the process's complexity, but the pattern is the same.
"The future and the extensibility of Loomworks will rely heavily on this approach, especially as Companion becomes better at management for the Operator." This makes the agent fabric foundational, not optional. It's the extensibility surface. New capabilities don't change the engine or the Companion — they add agent types.
Operator ↔ Companion ↔ Task Agent ↔ Specialist / External Service
Each level has a defined role:
The Operator holds intent. "Build my website." "Draft a contract." "What's happening with my projects?" The Operator speaks in domain vocabulary. The Operator does not know about agents, specialists, or processes.
The Companion holds the relationship. It understands what the Operator wants, translates between Operator vocabulary and the engine, manages trust via the delegation contract, and orchestrates task agents. The Companion decides what the Operator needs to know and when. It receives reports from task agents and delivers them as conversational updates, notifications, or approval cards — whichever the moment requires. The Companion is the manager.
The Task Agent holds the process. It is spawned for a specific piece of work, manages that work through its lifecycle, makes domain-specific decisions within its authority (retry on transient failure, adjust polling intervals, escalate on structural failure), and reports to the Companion when there is something worth reporting. It does not talk to the Operator. The task agent is the worker's supervisor.
The Specialist / External Service does the work. Render specialists, external APIs, LLM services, 3D printing services. They implement the SDK contract and produce artifacts. They don't know about the Companion, the Operator, or the agent fabric. They are the workers.
A task agent is a process-scoped entity with the following properties:
Lifecycle. Born when a process starts. Dies when the process completes (success or terminal failure). The agent's lifespan matches the process's lifespan. A two-second inline render spawns an agent that lives for two seconds. A three-day application build spawns an agent that lives for three days. This is not waste — even the two-second agent provides attribution, event recording, and a uniform reporting interface.
Instruction set. Per R-A24, a versioned instruction set that carries the agent's domain knowledge. A render task agent knows about render mechanics: polling patterns, failure classification, retry policies, progress interpretation. A shaping task agent knows about shaping mechanics: specialist interaction, quality assessment, iteration triggers. The instruction set is the agent's expertise.
Authority. Delegated from the Companion, which holds it from the Operator via the delegation contract. The task agent's authority is scoped: it can manage its process, but it cannot reach outside that process. A render task agent can retry a failing specialist, adjust polling intervals, or escalate to the Companion — it cannot initiate a new engagement, send messages, or spend money.
Reporting obligation. The task agent reports to the Companion. Reports are structured: progress updates (for long-running processes), completion (success with artifact reference), failure (with classification and recommendation), and escalation (when the agent's authority is insufficient and a decision requires the Operator). The Companion decides which reports surface to the Operator and how.
Judgment. The task agent makes decisions within its domain. This is the key distinction from a mechanical dispatcher. Today's ExternalPollingLoop (Phase 34) polls at a fixed interval and transitions job rows. A task agent would evaluate each poll result: Is progress happening? Is the external service degrading? Should it retry? Should it try a different specialist? Should it escalate? The agent's instruction set carries the judgment criteria; the agent applies them.
The same pattern works at every scale. The differences are in the instruction set's sophistication and the agent's lifespan, not in the architecture.
Tiny process — inline text render. The specialist completes synchronously. The task agent is born, receives the result, writes the render event, reports completion to the Companion, and dies. Total lifespan: under a second. The agent's value at this scale is attribution and uniformity — every render, regardless of complexity, flows through the same reporting chain.
Medium process — LLM-produced specification. The shaping specialist runs for 10–30 seconds. The task agent is born, monitors progress, handles any specialist error (retry if transient, escalate if structural), writes the shape event on completion, reports to the Companion, and dies.
Large process — external application build. Claude Code Dispatch takes minutes to hours. The task agent is born, dispatches to the external service, polls at intervals, interprets progress hints from the external service, reports meaningful progress to the Companion ("scaffolding complete, deploying frontend"), handles timeouts and partial failures, writes the render event on completion, reports to the Companion, and dies. Total lifespan: minutes to hours. The agent's value at this scale is supervision — it's the entity that knows what's happening while the Operator is away.
Complex process — multi-step composition. Phase 37's adapter chaining produces a render through multiple steps: produce → review → translate → transform → validate. The task agent orchestrates the sequence, managing each step as a sub-process, pausing for Operator decisions at review steps (via the Companion's approval card pattern), and holding state between steps. Total lifespan: potentially days if a review step waits for the Operator. The agent's value at this scale is orchestration — it holds the multi-step lifecycle together.
The Companion's role changes from doer to manager. After the agent fabric is in place:
Before (Phase 45 pattern). The Companion receives a request_draft intent, checks delegation, creates an approval card or executes directly, fires the engine operation, and... that's it. Fire and forget. The Companion learns of the outcome when a separate trigger (Phase 44's event listener) fires a notification. The Companion doesn't supervise; it initiates and then learns of outcomes passively.
After (agent fabric pattern). The Companion receives the intent, spawns a task agent for the work, delegates authority to the agent, and the agent manages the process. The agent reports back to the Companion — progress, completion, failure, escalation. The Companion decides what the Operator needs to know. The Companion can answer "what's happening with my contract draft?" by querying its active task agents, not by scanning job tables.
The Companion's intelligence grows by learning to manage agents better, not by learning to do more things itself. A more capable Companion spawns agents more judiciously, interprets their reports more insightfully, correlates patterns across agents ("your last three renders from this specialist have failed — something may be wrong"), and makes better decisions about what to surface to the Operator and when. The growth is in management intelligence, not in domain breadth.
Individual task agents are process-scoped, but the Companion sees all of them. This creates a natural surface for cross-process intelligence:
Pattern detection. The Companion notices that a specialist has failed across multiple task agents. It doesn't need a dedicated monitoring agent for this — it aggregates from its agent reports.
Resource awareness. The Companion knows how many task agents are active and what they're doing. It can tell the Operator "you have three renders in flight and one waiting for review" without scanning operational tables.
Prioritization. When the Operator asks "what should I look at?", the Companion draws from its agent reports to surface the most decision-relevant items.
This is the Arc 4 (cross-project intelligence) thesis concretized. The Companion doesn't need exotic cross-engagement analysis — it needs good agent management and the intelligence to draw conclusions from what its agents report.
The protocol triangle (Loom remembers, OVA authorizes, FORAY audits) operates at each boundary in the chain.
Loom: The delegation contract lives in the personal engagement as committed assertions. The Companion's authority is recorded in Memory.
OVA: The verify_companion_authorization seam (Phase 45) checks delegation before action. Today it's assertion lookup; eventually it's OVA cryptographic verification.
FORAY: Every Companion action is attributable via ActorRef(kind="companion") with capability_ref and approval_mode. The audit trail is tamper-evident.
Loom: The task agent's creation, authority grant, and lifecycle events are recorded in the engagement's Memory. The agent's instruction set is a versioned MemoryObject (per R-A24). The agent's reports become Memory events. OVA: The task agent's authority is derived from the Companion's authority, which is derived from the Operator's delegation. This is sub-delegation — the OVA seam extends to verify that the Companion had the authority to delegate to the task agent, and that the task agent's actions fall within the delegated scope. FORAY: The task agent's actions produce FORAY-anchorable events. The chain of authority (Operator → delegation → Companion → task agent → action) is auditable.
Loom: The specialist's production is recorded as Memory events (render events, shape events). The task agent writes these events with full provenance — the specialist that produced, the instruction version in force, the inputs consumed. OVA: For external services, the OVA credential seam authenticates the request. The credential is bound to the person (via the Companion, via the task agent), not to the engine. FORAY: The external service call and its result are anchorable. The task agent's decision to dispatch, retry, or escalate is auditable.
The Companion as agent investigation (v0.1, §3.2) defined the delegation contract between Operator and Companion. The agent fabric adds a second delegation layer: Companion to task agent. This is sub-delegation — the Companion grants a subset of its authority to a task agent for a specific process.
Sub-delegation needs three properties:
Scoped. The task agent receives authority only for its process. A render task agent can manage its render job. It cannot access other render jobs, other engagements, or other capability tiers.
Bounded by the Companion's authority. The Companion cannot delegate what it doesn't have. If the Operator grants the Companion produce_specification but not produce_artifact, the Companion cannot spawn a render task agent — it doesn't have the authority to sub-delegate.
Auditable. The sub-delegation event is recorded. The chain of authority from Operator through Companion to task agent to action is reconstructable.
The Phase 45 OVA seam (verify_companion_authorization) currently checks Companion authority. The agent fabric extends this to verify_task_agent_authorization, which checks both: (a) the task agent has authority from the Companion, and (b) the Companion has authority from the Operator. Two-hop verification. The seam's interface shape accommodates this — the implementation changes from single-hop assertion lookup to two-hop chain verification.
BackgroundAgentRunner (Phase 3). Dispatches agent work as background asyncio tasks. Currently fire-and-forget — dispatch and move on. The task agent pattern needs the runner to support longer-lived agents with state, but the dispatch mechanism itself is sound.
Agent registry (Phase 3). Registration keyed by (engagement_id, agent_type) or (engagement_id, declared_render_type_ref). Currently holds persistent agents (one RenderDispatchAgent per engagement, one shaping agent per engagement). Task agents are ephemeral — they need a different registration pattern (see §5.1).
RenderDispatchAgent (Phase 10). Per-engagement agent that dispatches render jobs. Currently a mechanical dispatcher — looks up the specialist, enqueues a job, fires. In the agent fabric, this becomes the task agent spawner for renders: when a render is requested, the RenderDispatchAgent spawns a render task agent for that specific job.
ExternalPollingLoop (Phase 34). Polls external services at declared intervals. Currently a global background task that scans all awaiting_external jobs. In the agent fabric, the polling responsibility moves into the render task agent — the agent polls its own external work rather than a global loop scanning all jobs. The agent can adjust its polling based on context (poll more frequently as an estimated completion time approaches, back off on repeated timeouts).
Operational tables (shaping_jobs, render_jobs). Track job status. These remain — the task agent manages a row in the operational table, not replaces it. The table is the durable state; the agent is the intelligence that operates on it.
Delegation contract (Phase 45). The Companion's authority from the Operator. The agent fabric extends this with sub-delegation to task agents, but the contract's structure (capability, scope, constraints, approval_mode) is the same at both levels.
SSE channel (Phase 44). Push notifications from engine to frontend. Task agents don't push to SSE directly — they report to the Companion, and the Companion decides what to push. The SSE channel stays as it is.
Trigger evaluator (Phase 44). Periodic scan for notification-worthy events. In the agent fabric, many triggers become unnecessary — the task agent reports directly to the Companion rather than the trigger evaluator scanning for completed jobs. The trigger evaluator's role narrows to ambient awareness (time-based triggers, stale-engagement detection) rather than event-response.
Task agent lifecycle management. The engine needs to spawn task agents, track active agents, and clean up completed agents. This is a new concern. Today, agents are persistent (registered at engagement creation, live forever). Task agents are born and die with their processes. The engine needs a task agent registry that manages this lifecycle.
Agent-to-Companion reporting protocol. Task agents report to the Companion through a defined protocol. This doesn't exist today. The protocol needs to be lightweight (a task agent report is a structured message, not an assertion in Memory) but auditable (the report is recorded for FORAY purposes). The Companion needs a receive-and-process path for agent reports.
Sub-delegation verification. The OVA seam extends from single-hop (Companion authorized?) to two-hop (Companion authorized? Task agent sub-authorized?). The verify_companion_authorization function becomes verify_agent_authorization with chain verification.
RenderDispatchAgent evolution. Transforms from a mechanical dispatcher to a task agent spawner. When a render is requested, it creates a render task agent, grants it authority, and the task agent takes over. The dispatch agent's instruction set carries the spawn logic and the authority-granting policy.
ExternalPollingLoop absorption. The global polling loop is absorbed into render task agents. Each task agent polls its own external work. The global loop's responsibility shrinks to startup recovery (finding orphaned awaiting_external jobs and spawning task agents for them).
A registry that manages ephemeral agents alongside the existing persistent agents.
Registration. register_task_agent(engagement_id, process_type, job_id, instruction_set_ref, authority_grant) → agent_id. The agent is keyed by (engagement_id, process_type, job_id) — a unique process.
Lookup. get_active_task_agents(engagement_id) → list of active agents. get_task_agent(agent_id) → specific agent. The Companion uses these to answer "what's happening?"
Lifecycle. Agents transition through spawned → active → completed | failed | escalated. Completed and failed agents are retained for audit (FORAY anchoring) but marked terminal. A reaper removes terminal agents after a retention period (or on engagement close).
Recovery. On process restart, the registry recovers active task agents from their durable state (operational table rows). An awaiting_external render job row means a render task agent should exist; if it doesn't (process restart killed it), the registry spawns one.
class TaskAgent:
"""Process-scoped agent with lifecycle, judgment, and reporting."""
agent_id: UUID
engagement_id: UUID
process_type: str # "render", "shaping", "composition", etc.
job_id: UUID # The operational table row this agent manages
instruction_set_ref: MemoryRef # Per R-A24
authority_grant: AuthorityGrant # Sub-delegation from the Companion
status: Literal["spawned", "active", "completed", "failed", "escalated"]
async def run(self, *, db: AsyncSession) -> AgentReport:
"""Main lifecycle method. Called by the runner. Returns a report."""
...
async def handle_event(self, event: ProcessEvent, *, db: AsyncSession) -> AgentDecision:
"""React to a process event (poll result, specialist completion, timeout).
Returns a decision: continue, retry, escalate, complete, fail."""
...
def compose_report(self, *, event_type: str, detail: dict) -> AgentReport:
"""Create a structured report for the Companion."""
...
Task agents report to the Companion through structured reports:
Report types:
progress — the process is ongoing; here's what's happened since the last report. For long-running processes.completed — the process succeeded; here's the artifact reference and summary.failed — the process failed terminally; here's the classification (transient-exhausted, structural, specialist-error, timeout) and what was attempted.escalation — the agent's authority is insufficient for the next decision; here's the situation and the options.decision_needed — a review step or approval gate has been reached; here's what the Operator needs to decide.Report structure:
@dataclass
class AgentReport:
agent_id: UUID
engagement_id: UUID
process_type: str
job_id: UUID
report_type: Literal["progress", "completed", "failed", "escalation", "decision_needed"]
summary: str # Operator-vocabulary summary
detail: dict # Structured detail for the Companion's use
recommended_action: str | None # Agent's recommendation (Companion may override)
timestamp: datetime
The Companion receives reports and decides what to do with them. A completed report on a pre-authorized render might produce a brief SSE notification ("your contract draft is ready"). A failed report might produce an approval card ("the website build failed twice on timeout — retry with longer timeout? [Approve] [Decline]"). An escalation might produce a conversational message. The Companion's intelligence is in how it translates agent reports into Operator-appropriate communications.
The render task agent is the first concrete task agent type. It replaces the mechanical dispatch-and-poll pattern with supervised process management.
Spawned by: RenderDispatchAgent (evolved from mechanical dispatcher to task agent spawner). Manages: One render job row. One specialist interaction. Optional external polling. Instruction set carries: Retry policy (how many retries, on which failure types). Polling strategy (initial interval, backoff policy, maximum wait). Progress interpretation rules (how to read specialist-specific progress hints). Failure classification rules (which errors are transient, which are structural). Reports to: The Companion, via the agent report protocol.
Lifecycle for synchronous render:
completed to Companion. Dies.Lifecycle for external render:
external_production_dispatched event.still_running with progress → agent interprets progress, optionally reports progress to Companion.completed with artifact → agent writes the render event, reports completed to Companion. Dies.failed → agent classifies: transient (retry if within policy) or terminal (report failed to Companion). Dies on terminal.failed with timeout classification to Companion. Dies.Lifecycle for composition (Phase 37 multi-step):
decision_needed to Companion. Companion creates approval card. Agent pauses until decision arrives.completed with the final artifact chain. Dies.
@dataclass
class AuthorityGrant:
"""Sub-delegation from Companion to task agent."""
granting_companion_ref: ActorRef # The Companion that granted authority
delegation_ref: MemoryRef # The delegation assertion this derives from
capability: str # What the agent is authorized to do
scope: dict # Engagement, render type, shape type constraints
expires_with_process: bool = True # Authority dies when the process completes
The task agent's ActorRef includes the authority chain:
ActorRef(
kind="task_agent",
agent_id=<UUID>,
person_id=<the person's UUID>, # Ultimately acting on behalf of
companion_ref=<Companion ActorRef>, # Authorized by
authority_grant_ref=<MemoryRef>, # Under this grant
)
Every event the task agent writes carries this ActorRef, making the full authority chain (Operator → delegation → Companion → authority grant → task agent → action) reconstructable from the event log.
Task agents need to survive process restarts (the DUNIN7-M4 reboots, the FastAPI process restarts). Two options:
Option A — Durable task agent table. A new task_agents table with agent state, instruction set ref, authority grant, and status. On restart, the registry scans for non-terminal rows and respawns agents. Pro: explicit, queryable, clean recovery. Con: another table, another migration, another set of lifecycle queries.
Option B — Derive from operational tables. No dedicated task agent table. The registry infers active agents from operational table state: an awaiting_external render job row implies a render task agent should exist; a dispatched shaping job row implies a shaping task agent should exist. On restart, the registry scans operational tables and spawns agents for in-flight work. Pro: no new table; agents are projections of existing operational state. Con: requires each process type to have an operational table, and the inference logic is type-specific.
Leaning toward Option A because it provides a uniform surface for the Companion to query ("what agents are active?") without type-specific inference logic.
Phase 37's adapter chaining composes multi-step lifecycles. Does the composition task agent manage all steps directly, or does it spawn sub-agents for each step?
Direct management. One task agent, N steps. The agent holds the full composition plan and advances through it. Simpler. The risk: if a step is itself long-running (a review that waits days for the Operator), the agent is alive but idle for an extended period.
Sub-agents. The composition agent spawns a sub-agent for each step. The sub-agent manages the step and reports back to the composition agent, which reports to the Companion. More complex. The benefit: each sub-agent's lifecycle is clean (born for its step, dies when the step completes), and the composition agent's logic is simpler (manage sub-agents, not step mechanics).
No strong lean. The first implementation (§5.4 render task agent) doesn't need to decide this — composition is Phase 37 territory and the render task agent handles single-step renders. The decision can be made when composition surfaces as a build target.
Task agents can range from minimal (classify failure, retry or report) to sophisticated (analyze failure patterns across retries, propose alternative specialists, predict completion times from progress hints, suggest specification changes when a specialist repeatedly fails on the same element). The instruction set carries the intelligence — more sophisticated instruction sets produce more intelligent agents.
The immediate build should be minimal. Ship the architecture with agents that classify, retry, and report. Intelligence grows by revising instruction sets, not by changing the agent fabric. This matches the methodology's extensibility-first principle: the framework specifies the boundary, the intelligence fills it later.
Phase 44's trigger evaluator is a periodic scan for notification-worthy events. With the agent fabric, many of those events are reported directly by task agents. Does the trigger evaluator shrink, or does it become the mechanism by which the Companion processes agent reports?
Option A — Shrink. The trigger evaluator handles ambient triggers only (stale engagements, birthday reminders). Agent reports go directly to the Companion through a separate path.
Option B — Absorb. The trigger evaluator gains a new trigger type: agent-report triggers. When a task agent submits a report, it fires a trigger that the evaluator processes. The evaluator is already the place where engine events become Companion-visible — agent reports are just another kind of event.
Leaning toward Option B. The trigger evaluator already has the infrastructure for event → notification → SSE push. Agent reports flow through the same pipeline. One notification pathway, not two.
The agent fabric is not blocking anything immediate. Arc 2 is complete. The next build targets (Operator Layer frontend, external service connectors, specialist SDK hardening) can proceed without it. The agent fabric becomes load-bearing when:
The build can be staged:
Stage 1 — Render task agent. Ship the task agent base class, the render task agent, the agent report protocol, and the task agent registry. Absorb the ExternalPollingLoop into render task agents. This lands alongside or just before Arc 6 Phase B, which needs supervised external builds.
Stage 2 — Shaping task agent. Apply the pattern to shaping. The shaping agent (Phase 9) becomes a task agent spawner; individual shaping jobs get task agents. Lower priority — shaping jobs are fast and rarely fail.
Stage 3 — Composition agent. Apply the pattern to Phase 37 multi-step compositions. The composition agent orchestrates sub-processes and handles review gates. This is the test of whether the agent fabric handles complex workflows.
Stage 4 — External agency agents. Tiers 2–5 external capabilities get task agents. The payment agent, the messaging agent, the calendar agent. Each has its own instruction set and authority scope. This is where the OVA sub-delegation model becomes load-bearing.
The Loompa five threads document (2026-04-28, thread 3) named the insight: "The factory is the protocol, not the candy. Wonka didn't build a chocolate company — he built a production system. DUNIN7 didn't build a document company — it built a specification-to-production protocol."
The agent fabric extends this. The Oompa Loompas are the specialists — they read recipes and produce candy. But who supervises the Oompa Loompas? In a real factory, there are supervisors on the floor: people who watch the machines, handle jams, report to management, and make judgment calls about retries and escalations. They're not the workers and they're not the factory owner. They're the layer between.
The task agents are the floor supervisors. The Companion is the factory manager. The Operator is the owner. The specialists are the workers. The SDK is the recipe language. The engagement is the product line. The factory runs because each level has its own judgment and its own reporting chain.
The metaphor question from the five threads was: "What does the factory know that the individual Oompa Loompa doesn't?" The answer: the factory knows the production plan, the state of all the machines, which workers are available, which jobs are in flight, and what to do when something goes wrong. That's the Companion-plus-agent-fabric. The individual worker (specialist) just follows the recipe.
All seven phases are tagged and landed. The agent fabric builds on them but does not require reopening them. Phase 34's external polling infrastructure is absorbed into render task agents. Phase 37's composition lifecycle is managed by composition task agents. The engine's operational tables and dispatch patterns are unchanged — agents manage rows, not replace them.
Phases 41–45 shipped the Companion's reactive/proactive/agentic capabilities. The agent fabric extends Arc 2's agency from direct action to delegated action. The delegation contract (Phase 45) gains sub-delegation. The approval card pattern (Phase 45) gains agent-initiated escalations. The SSE channel (Phase 44) gains agent-report-driven notifications. None of these require reworking Arc 2 — they extend it.
The agent fabric and Arc 6 are complementary. Arc 6 defines the SDK contract that specialists implement. The agent fabric defines how the engine supervises specialist work. Arc 6 Phase B (application-rendering adapter) is the first case that needs supervised external builds — the natural point where the agent fabric becomes load-bearing.
Arc 4 (Cross-project intelligence) is now the Companion's management intelligence applied to its agent reports. The Companion draws connections across agents: "the FarmGuard soil analysis and the marketing engagement both reference the same constraint pattern — want me to link them?"
External agency arc (post-Arc 2) maps directly onto the agent fabric. Each external capability is a task agent type. The payment agent manages a Stripe transaction. The messaging agent manages a message send. The calendar agent manages an event creation. Each has authority from the Companion, each reports back, each is auditable.
The Operator's correction — that an agent manages the render and reports to the Companion — is not a feature request. It's an architectural thesis about how Loomworks grows. The Companion is a manager, not a worker. New capabilities are new agent types, not new Companion code. The protocol triangle operates at every boundary. The pattern works at every scale. The extensibility of Loomworks depends on this fabric.
The immediate build target is the render task agent (§5.4), timed to land alongside or just before Arc 6 Phase B. The architecture is designed so that the first task agent type validates the pattern, and subsequent types (shaping, composition, external agency) add capability without changing the fabric.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Agent Fabric Investigation — v0.1 — 2026-05-06