Virtual Cast and Repair Agent Deep Implementation Awareness

Two compelling technologies, two independent decisions

Imagine a media-learning product with two ideas: a persistent photoreal virtual teaching cast reused across many lessons, and a Repair Agent that finds broken assets or code and proposes fixes. Both can look impressive in a demo. The problem is that demo quality proves neither product need nor production authority.

For a Virtual Cast, separately prove the recurring problem, the measured trigger that justifies a deeper pipeline, the identity/rights owner, the asset/capture/animation/render pipeline, the quality and performance target, the production owner, the cost, and whether a simpler alternative still solves the need. Current MetaHuman documentation describes a framework for creating, animating, and using rigged photoreal digital humans, including capture, animation, and crowd-oriented workflows. That is a capability fact, not MAKNOW adoption authority. [METAHUMAN]

For a Repair Agent, build a different gate: the failure must be reproducible; tool scope and write scope must be bounded; the patch plan, approval, guardrails, test/eval evidence, rollback, side-effect class, and audit trace must be reviewable. Current OpenAI Agents SDK documentation includes tools, guardrails, tracing, and human-in-the-loop mechanisms. HITL can pause sensitive tool calls for approval and resume the run after a decision, while tool guardrails can inspect or block custom function-tool calls before or after execution. Those mechanisms do not by themselves prove correctness, rollback, or production safety. [AGENTSDK] [AGENTHITL] [AGENTGUARD]

Lesson artifact: Virtual Cast/Repair Agent Deep-Implementation Gate v1, with two independent axes and bounded states: USE, PILOT, NOT_NOW, UNKNOWN, EVIDENCE_INCOMPLETE, OWNER_MISSING, REVIEW_REQUIRED, or HOLD.

Planned active time: 45 minutes.

Boundary: AWR-008 owns deep-implementation awareness for Virtual Cast and Repair Agent decisions. It does not absorb AWR-007 Multi-region/Autonomous Ad Buying or D3D-001 3D production-modeling outcomes. This lesson publishes no virtual cast and grants no agent production-write authority.

HARD prerequisite — AWR-005

You must be able to state the required AWR-005 boundary before entering this lesson. If that evidence is fragile, use a bounded bridge; do not fabricate prerequisite completion.

SOFT prerequisite — AWR-007

Carry forward only the boundary needed from AWR-007. The prerequisite remains valid and its outcome must not be rebuilt inside AWR-008.

Separate the two axes before choosing a tool

Answer four diagnostic questions:

1. If MetaHuman or another digital-human framework can create a photoreal character, does that capability prove your product needs a Virtual Cast?
2. If an agent fixes one synthetic bug, can it be treated as repository- or production-ready without tests, rollback, and bounded write scope?
3. If cast rights ownership is unknown but visual quality is excellent, is USE or PILOT allowed?
4. If Virtual Cast evidence is complete but the repair target reaches billing code and production data, must both axes receive the same verdict?

4/4 → Fast Path. 2–3/4 → Repair Path. 0–1/4 → Foundation Path.

Fast Path compresses definitions, not evidence requirements. Repair Path isolates the first broken evidence dimension. Foundation Path uses the full field map and a guided case. No route may collapse the two axes into one verdict.

Route self-check: separate capability from adoption trigger, quality from rights/ownership, guardrails from rollback/correctness, and recompute transfer independently for each axis.

Mental model: problem → trigger → authority → evidence → cost/control → decision

For each axis, preserve this order:

problem fit → measured trigger → owner/authority → technical evidence → cost or side-effect control → simpler alternative → bounded state → explicit stop/pivot condition + applicable review/migration/escalation trigger(s)

Two independent flows:

Virtual Cast → role/reuse trigger → identity & rights → asset/capture/animation/render → quality & budget → production owner → USE / PILOT / NOT_NOW / HOLD

Repair Agent → reproducible failure → tool/write scope → approval & guardrails → deterministic tests/eval → rollback & audit → USE / PILOT / NOT_NOW / REVIEW_REQUIRED

Do not mix three authority classes:

The table asset aligns the two axes row by row. The flow asset shows the gates that must precede a positive state. If visual rendering is unavailable, the source table and ordered text flow remain sufficient.

Shared foundations for deep-implementation awareness

1. Capability is not adoption need

MetaHuman is documented as a framework for creating, animating, and using rigged photoreal digital humans, with Creator, Capture, Animator, and Crowds workflows. [METAHUMAN] This does not tell you that your product needs a persistent cast, many characters, performance capture, or a dedicated production pipeline.

The Agents SDK includes agents, tools, guardrails, HITL, and tracing. [AGENTSDK] These primitives make technical controls possible; they do not establish that repair automation is justified or safe for your problem.

2. Virtual Cast starts with ownership, not render quality

Before model, rig, or capture choices, identify cast roles, character count, identity/rights ownership, and production ownership. If ownership is unresolved for the proposed cast, high visual quality cannot convert OWNER_MISSING into USE.

3. A quality target without a cost/performance target is incomplete

A character can meet the visual bar while exceeding the render or animation budget. That is real negative evidence. Quality pass is only one gate.

4. A Repair Agent needs a reproducible failure

“Files sometimes break” is not enough. A failure signature and fixture must show which input reproduces the problem. Without reproducibility, patch success cannot be evaluated reliably.

5. Tool scope and write scope are different

An agent may be allowed to read, search, propose patches, or run tests while still lacking write authority. PROPOSE_ONLY can be a useful low-risk alternative. SANDBOX_PATCH_ONLY is narrower than repository or production write access.

6. Approval and guardrails are controls, not correctness proof

Agents SDK HITL can pause a sensitive tool call for human approval. [AGENTHITL] Tool guardrails can validate or block custom function-tool invocations before or after execution. [AGENTGUARD] But a guardrail does not automatically undo side effects, and approval alone does not prove a patch is correct. Tests/evaluation and rollback remain independent requirements.

7. Typed non-success is a valid result

NOT_NOW can mean a simpler alternative still meets the need or the trigger is weak. EVIDENCE_INCOMPLETE means decisive data is missing. OWNER_MISSING means authority is unresolved. REVIEW_REQUIRED means scope or side effects need a higher review. These states prevent false confidence; they are not learning failures.

Build Virtual Cast/Repair Agent Deep-Implementation Gate v1

Step 1 — Create two decision axes

Use separate VIRTUAL_CAST and REPAIR_AGENT rows. Do not create a shared final state. One axis may be PILOT while the other is NOT_NOW.

Step 2 — State the problem and measured trigger

For Virtual Cast, the trigger can be recurring cast reuse, identity consistency, production volume, or another measured need. “Photoreal looks better” is not a trigger.

For Repair Agent, the trigger should be a recurring failure pattern and the observable cost or latency of repair. “The agent can write code” is not a trigger.

Step 3 — Resolve authority/ownership before a positive state

Virtual Cast: identity_rights_owner and production_owner. Repair Agent: production owner, approval owner, and scope owner.

Unknown authority means a typed non-success state.

Step 4 — Map the pipeline or control surface

Virtual Cast: asset pipeline, capture requirement, animation requirement, render target, frame/latency budget, and quality target.

Repair Agent: failure signature, tool scope, write scope, patch plan, and side-effect class.

Step 5 — Add testable evidence

Virtual Cast: quality evidence plus render/animation cost against the declared budget. Repair Agent: deterministic test fixture, evaluation result, guardrail state, approval state, rollback plan, and audit trace.

Step 6 — Evaluate a simpler alternative

Virtual Cast alternatives can include recorded human video, a stylized avatar, or a limited presenter workflow. Repair alternatives can include human repair, a deterministic fix script, a proposal-only agent, or sandbox-only automation.

If the simpler alternative meets the trigger with lower cost or risk, NOT_NOW can be the correct result.

Step 7 — Never make the decision stronger than the evidence

USE or PILOT requires the decisive dimensions for that axis to be explicit. Do not fill a missing owner, test, or rollback plan with confident language.

Step 8 — Make the stop/pivot condition explicit and name applicable governance triggers

Write the condition that forces this axis to stop or pivot. Then name only the governance triggers that actually apply to the case—review, migration, escalation, or a combination of them. Do not mechanically require every trigger category. Examples include more characters, a rights change, a new render budget, a higher side-effect class, wider write scope, a new failure signature, or a target change.

Step 9 — Recompute transfer from zero

In a second product, a single recurring presenter may have documented rights and a stable pipeline while repair tasks touch billing code and production data. Virtual Cast may advance while repair automation remains REVIEW_REQUIRED or NOT_NOW. Independent recomputation is the skill being tested.

Worked example: one product, two different verdicts

This example is separate from the executable lab and does not pre-solve it.

Synthetic product SYNTH-MEDIA-B has three recurring presenters. Rights are documented for two, but the third has no identified rights owner. The asset pipeline and render target are known and the quality prototype is strong. The bounded Virtual Cast state cannot be positive; OWNER_MISSING is more faithful until ownership is resolved.

The same product has a Repair Agent limited to synthetic lesson assets. The failure signature is explicit, writes occur only in a sandbox, approval precedes the write, a deterministic test suite passes, rollback restores a snapshot, and an audit trace is retained. That evidence can justify a bounded PILOT without granting production write or billing-code repair authority.

The lesson is not that repair always deserves PILOT. It is that axis-specific evidence creates axis-specific verdicts. If the repair target later moves to production data, discard the baseline verdict and recompute.

Shortcuts that create false confidence

1. “The photoreal demo is good, so we need Virtual Cast.” Repair: prove problem/trigger and compare a simpler alternative.
2. “The framework solves identity rights.” Repair: keep rights ownership local and explicit.
3. “Quality passed, so cost no longer matters.” Repair: compare render/animation estimate with the target budget.
4. “The agent fixed one bug, so repair automation is ready.” Repair: require reproducibility, deterministic tests, and transfer.
5. “Human approval makes side effects safe.” Repair: separate approval from rollback and correctness. [AGENTHITL]
6. “Guardrails make every tool call safe.” Repair: record the exact scope and timing; guardrails are controls, not proof. [AGENTGUARD]
7. “PROPOSE_ONLY means the agent is useless.” Repair: evaluate it as a lower-risk alternative; deep write authority may not be needed.
8. “Both axes should share one maturity level.” Repair: decisions are independent.
9. “Vendor documentation is adoption authority.” Repair: separate FACT from MAKNOW DESIGN.
10. “The baseline passed, so transfer uses the same answer.” Repair: recompute every changed constraint from zero.

Experienced bridge: treat this as two state machines

If you already build virtual production or agentic tooling, the value here is not tool taxonomy. It is versioned authority and evidence.

For Virtual Cast, build the state machine around rights → production pipeline → quality/performance → budget → owner. For Repair Agent, use failure → tool/write authority → approval/guardrails → tests/eval → rollback/audit.

Two professional separations matter:

• “Can perform” is different from “is allowed to perform.”
• “Succeeded once” is different from “reproducible and recoverable.”

In design review, identify which fields are hard gates, advisory evidence, or escalation points. Avoid synthetic weighted scores that hide the difference between rights, budget, and side effects.

Trade-offs without a permanent winner

Virtual Cast vs recorded human video: a cast can provide consistency and reuse but needs an asset/capture/animation/render pipeline, rights, and production ownership. Human video may be simpler and cheaper but less reusable or editable.

Photoreal cast vs stylized avatar: photorealism can meet a specific quality target but may add render/capture cost and identity sensitivity. A stylized approach may solve the product problem with less complexity.

Human repair vs proposal-only agent: humans are slower but have explicit authority. A proposal-only agent can accelerate triage without file writes and may be the right current step.

Sandbox repair vs repository/production repair: sandbox scope limits blast radius and makes tests/rollback easier. Billing-code or production-data writes need a much higher bar for review, permission, observability, and recovery; this lesson does not grant that authority.

HITL vs fully autonomous execution: approval can be a meaningful gate but adds latency and operational load. Removing it requires stronger evidence for scope, tests, side effects, and rollback. [AGENTHITL]

Guided and independent practice

Part A — Build the baseline without a prefilled final state

Open lab://AWR-008/AWR-008-LAB1. baseline_fixture.json contains synthetic evidence for both axes but leaves both decisions null. Populate gate_evidence.template.json, bind fixture_ref to the exact shipped fixture identifier, and for each axis record the state, bounded rationale, explicit stop-or-pivot condition, and applicable governance triggers independently. Do not fabricate evidence.

The checker validates only the visible consistency rules plus exact binding to the shipped fixture. CONSISTENT means the submitted evidence matches the declared fixture and the visible rules; it is not adoption approval, legal rights clearance, or production-safety certification.

Part B — Diagnose mutations independently

1. add more characters without adding a rights/production owner;
2. keep visual quality but exceed the render budget;
3. restrict the Repair Agent to PROPOSE_ONLY;
4. add repository writes while removing deterministic tests or rollback;
5. move the repair target to billing code and production data.

For each mutation, record the broken assumption, consequence, and minimum repair or decision change.

Part C — Recompute transfer

transfer_fixture.json has one recurring presenter with documented rights and a stable pipeline, while repair tasks affect billing code and production data. Do not copy baseline verdicts. The two axes may legitimately end in different states.

Verification: a reviewer must reconstruct each axis without guessing

For Virtual Cast, a reviewer should trace:

1. problem and trigger;
2. cast role/count;
3. identity/rights owner;
4. asset/capture/animation/render pipeline;
5. quality evidence;
6. production owner;
7. cost/budget;
8. simpler alternative;
9. bounded state, explicit stop/pivot condition, and applicable review/migration/escalation trigger(s).

For Repair Agent:

1. reproducible failure signature;
2. repair target;
3. tool scope and write scope;
4. patch plan and side-effect class;
5. approval requirement/owner;
6. guardrail state;
7. deterministic test fixture and eval result;
8. rollback plan;
9. audit trace;
10. simpler alternative;
11. bounded state, explicit stop/pivot condition, and applicable review/migration/escalation trigger(s).

If a decisive field is missing, preserve a typed non-success state. The checker may not infer missing evidence or emit a preferred answer.

Assessment and transfer

The summative assessment has four blocking parts:

1. explain the owned AWR-008 boundary, name one adjacent non-goal, and separate external FACT from MAKNOW DESIGN authority;
2. build Virtual Cast/Repair Agent Deep-Implementation Gate v1 for the baseline synthetic fixture with two independent decisions;
3. diagnose “add more characters without adding a rights/production owner,” identifying the invalidated field/state and minimum repair;
4. for a second product, recompute a Virtual Cast with one rights-cleared recurring presenter independently from a Repair Agent that touches billing code/production data.

The rubric has five critical dimensions: identity_and_contract, exact_evidence_binding, negative_evidence, bounded_decision, and transfer.

AI may organize synthetic evidence, surface missing fields, or perform deterministic comparisons. It may not invent rights ownership, adoption triggers, repair success, approval, or production authority.

References, freshness, and claim boundaries

[AWR-008-K1 / FACT] MetaHuman documentation describes a framework for creating, animating, and using rigged photoreal digital humans, including Creator, Capture, Animator, and Crowds workflows. [METAHUMAN] This does not prove product need or rights/production readiness.

[AWR-008-K2 / FACT] The OpenAI Agents SDK includes agents, tools, guardrails, tracing, and human-in-the-loop mechanisms. [AGENTSDK] HITL can pause sensitive tool calls for approval and resume the run after a decision. [AGENTHITL] This is not repository/production write authority.

[AWR-008-K3 / FACT] Tool guardrails for custom function tools can validate or block calls before and after execution. [AGENTGUARD] This does not prove patch correctness or automatic rollback.

[AWR-008-K4 / DESIGN] The two-axis gate, state vocabulary, acceptance evidence, and lab rules in this lesson are MAKNOW design authority; vendor documentation does not define them.

The four official sources were reviewed on 2026-09-07 and continue to support the capability boundaries stated above. The next scheduled review is 2026-12-02; review earlier if the cited digital-human pipeline, agent tool/approval/guardrail behavior, or source availability changes materially.

The source labels used in this lesson identify the corresponding official references.