Version. 0.1 Date. 2026-05-08 Status. Investigation. Thinking material — architectural pattern crystallized, not yet specified for build. Author. Claude.ai (investigation layer). Operator: Marvin Percival. Provenance. Conversation initiated by the Operator's question about whether a render in a closed-loop engagement could evaluate outcomes and add to memory. The conversation moved through three refinements: render-can't-but-the-pathway-exists, Companion-versus-render as attribution channel, and the worked example of an ad-management engagement that surfaced the auto-trigger question. Informed by. Methodology v0.20 (Companion identity, executor opacity, full assertion lifecycle, Memory expectations). Methodology v0.17 and v0.18 (the unsettled "feedback from running artifacts back to memory" area). Phase 10 CR (Memory-as-sole-write-target). Phase 41 (Companion identity and personal engagement). Phase 42 (intent classification, reactive Companion). Phase 43 (personal memory contribution, held + conversational commit). Phase 45 CR (delegation contract, approval cards, OVA seam). Companion-as-Agent Investigation v0.1 (capability tiers, attribution model). Agent Fabric Investigation v0.1 (task agent reports to Companion). Queued Directions v0.2 (consumer-as-contributor, parameterized Shapes, composite specialists).
The Operator opened with: In a closed-loop engagement, can a render (task) evaluate outcomes and add to memory?
The phrasing carries an implicit use-case class. A closed-loop engagement — not yet a named term in the methodology — is one where the engagement consumes its own renders rather than shipping deliverables externally. The render is a task; performing the task produces outcomes; outcomes inform subsequent work in the same engagement. This is structurally different from an engagement that ships a contract draft, a story, or an ad creative for someone else to use.
The question implicitly proposes a fast loop: render → action → outcome → memory → next derivation → next render.
The architectural form of the answer is:
The render does not evaluate. The render does not write. Outcomes flow back through the ordinary assertion lifecycle, with the Companion as attribution channel when the source is non-human, with provenance threading from the new outcome assertion back to the render event (and, under the agent fabric model, to the supervising agent's ActorRef chain).
The Companion authors the outcome assertion in held state. The Operator commits — today by per-action approval, in the Phase 45+ world by pre-authorized delegation contract for outcome categories the Operator has signed off on as a class.
Closed-loop is the use-case class that motivates several already-queued directions to integrate: consumer-as-contributor, performance-observation as a recurring outcome category, and the memory-commit auto-trigger question (queued below in §6).
Initial framing under consideration. The render or specialist evaluates the outcome and writes to Memory directly.
Why it fell. Two reasons. First, the render is content, not an actor — "render evaluates" puts agency in the artifact, which is a category error. Second, even if the specialist (the actor that produced the render) did the writing, that violates Memory-as-sole-write-target by creating a second write path with unclear remediation semantics. Phase 10 worked exactly this discipline out: drift detected at the Render layer routes upstream to the Memory or Shape layer, and the Render is invalidated, never edited.
What landed. Outcomes flow back through the existing assertion contribution lifecycle. An observer (Operator, agent, executor, consumer) contributes the outcome as a held assertion; provenance points at the render event. Human-attributability for commit (R-B19/R-B20) is preserved. No new primitive is required. The methodology already names the unsettled piece as "feedback from running artifacts back to memory" (v0.17 and v0.18); the architecture for the contribution path is settled, the use-case naming and product surfaces are not.
Question raised. Of the available pathways, which is more appropriate and flexible — a render-side mechanism (specialist or render-layer outcome events) or the Companion?
Initial framing under consideration. Render-side mechanism — specialists become outcome-aware, the render layer carries an outcome event kind, each render type has its own observation pathway.
Why it fell. Render-side machinery requires per-render-type observation pathways, makes specialists stateful (they would have to track their own renders' fates), introduces a second write semantics for the engine to reason about, and pays a large architectural cost for marginal benefit. Even in its strongest case (fully automated outcomes from a build pipeline or a render farm), the Agent Fabric Investigation already proposes that a task agent observes and the Companion is the attribution channel — so render-side does not win even on its strongest case.
What landed. The Companion. Already a contributor primitive (ActorRef(kind="companion") from Phase 41, held-authoring from Phase 43). Domain-agnostic — every new render type uses the same contribution lifecycle. Composes with existing flows: Phase 42 classification handles "I tried that, here's what happened" already; Phase 43 held + commit handles the write; Phase 45 approval cards handle standing authority when the Operator wants to delegate.
A finer distinction surfaced inside turn two and is worth filing on its own. What is distributed across many possible parties is observation. What is centralized in the Companion is attribution.
All of those route their observation through the Companion to land in Memory as a held assertion. Provenance points at both the observer and the render event. The Operator commits.
This collapses "render vs. Companion" into "many possible observers, single attribution channel." It also matches the agent fabric's separation of concerns at the contribution layer: domain-specialized agents handle process detail; the Companion is uniform.
The Operator proposed a concrete engagement: an engagement tasked with creating Facebook ads, placing them, and reviewing performance, where if the system considered a modification appropriate it would recommend a modification to engagement Memory through the Companion, which would re-engage the pipeline.
Two refinements landed.
Refinement A — the observer is probably not the render specialist. A creative specialist's contract is "given a confirmed shape, produce ad creative." A placement specialist's contract is "given creative, place it on Facebook's API." A performance-observation contract is "watch metrics over time and report back." Three contracts, three concerns. Conflating them into one specialist makes the specialist stateful and long-lived in a way that fights the executor-opacity discipline. The Agent Fabric Investigation's render task agent already separates supervision from production for exactly this reason.
The cleaner version: a performance-observer agent (a different specialist, or a task agent supervising the placement specialist's continuing lifecycle) is the one watching metrics. It reports progress or decision_needed to the Companion when something crosses a threshold or when a hypothesis crystallizes. The render specialist that produced the creative may have died long ago.
Composition is allowed — an ad-management specialist that orchestrates creative, placement, and observation as a single Operator-facing surface (parameterized-Shapes / composite-specialists pattern from queued directions). Under the hood it is still three roles.
Refinement B — the pipeline does not auto-trigger from memory commit, today. This is the larger refinement. In current substrate:
Methodology v0.18 settled the information layer: when memory changes, the engagement can tell the Operator what is now affected downstream. It deliberately left the decision to re-derive with the Operator. So today the pattern is: Companion adds the held outcome assertion → Operator commits → memory-status surface signals "the previous ad's manifestation is stale" → Operator triggers a new shape (or doesn't).
For the fully-automatic loop the worked example assumes, two things would need to be true that are not true today.
The Companion is the attribution channel through all of it. The agent fabric is what makes the observer's reporting clean. The delegation contract is what determines how much of this loop runs without the Operator in the per-action seat.
A name for engagements where the renders are consumed within the engagement (or by the Operator's executing role) rather than shipped externally. Distinct from delivery-class engagements (contract draft, ad creative for an external campaign, story for a reader). The naming would clarify which engagement-design patterns apply: tight feedback expectations, performance-observation as a first-class outcome category, parameterized Shapes likely, the auto-trigger question (§6.2) most acute here.
If this becomes a recurring engagement shape it should land in the methodology document — probably as a section under engagement classes or under the four-room pipeline, alongside delivery-class.
Today's auto-triggers anchor to confirmation events (shape_confirmed, render_confirmed). They do not anchor to commit events on assertions. For closed-loop engagements where the Operator's intent is precisely "keep iterating as new performance data lands," a category-scoped commit trigger would close the automation loop:
outcome_class="performance_observation").performance_observation commits, propose a shape candidate against [ad-revision shape type]."Genuinely open: whether this is useful or over-reach. The argument against — every commit re-deriving downstream work is noisy and may produce shapes the Operator was not ready for. The argument for — in tight feedback engagements (ads, content optimization, A/B testing), this is precisely what the Operator wants. A category marker plus a category-scoped trigger is probably the cleaner shape than "any commit triggers anything."
File this as a queued direction. Lights up when a real closed-loop engagement use case comes through and the Operator finds themselves manually triggering a new shape every time a performance assertion commits.
Across closed-loop engagements (ads, content, optimization, ops), "outcome of an executed render" has a small number of recurring shapes — performance metric, qualitative report, error or failure, downstream effect. Worth a working list when more than one closed-loop engagement is on the books, since the categorization feeds the auto-trigger question (§6.2) and likely the delegation-contract category schema (Phase 45+).
Settled.
Partially settled.
Unsettled.
This investigation was produced through a four-turn conversation. The Operator's first question proposed a render-evaluates pathway; the response established that renders cannot evaluate but the loop closes through the assertion lifecycle. The Operator's second question asked which approach (render-side or Companion) was more appropriate; the response established the Companion as the attribution channel and surfaced the observation/attribution separation. The Operator's third question proposed the Facebook Ads worked example; the response identified the observer-versus-producer separation and the auto-trigger gap. The Operator's fourth turn directed that this be filed for consideration.
The trajectory matters for the Discovery record because the framing changed twice in significant ways. The first reframing was the Operator's implicit move from "render evaluates" to "Companion attributes" — visible in turn two's question. The second was the Operator's introduction of a concrete worked example, which surfaced the auto-trigger question that is not architectural-decision-ready and properly belongs in queued directions.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Closed-loop Engagement Investigation — v0.1 — 2026-05-08