Engineering Multi-Agent Interactive Content: A Production Pipeline for Roles, Isolation, Rendering, and Review

In generative AI content creation, having multiple agents praise, critique, and tease one another around the same topic may look like a lightweight entertainment segment. In practice, it involves role modeling, input consistency, process control, result traceability, audio-video composition, and risk governance.

Without clear engineering design, different agents may receive different versions of the task, or one participant may see another participant’s answer early and let it affect later judgment. If raw outputs are not preserved, video production may suffer from rewritten lines, polished tone, or subtitles that do not match the voiceover. This type of content should therefore be managed as a small multi-agent experiment, not just as a chat.

1. Abstract the Content Structure: From Chat to Executable Task

A typical multi-agent interactive task can be split into four object types:

1. Participant roles: for example, Agent A, Agent B, Agent C, and Agent D.
2. Fixed inputs: persona descriptions, task rules, character limits, and output format.
3. Staged actions: in the first round, name, praise, and critique the other participants; in the second round, respond after reading what others said about the agent.
4. Final presentation: convert text results into subtitles, voiceover, visuals, animation, and video.

The benefit of this split is that creators can clearly separate model generation from post-production orchestration. The model proposes content, the orchestration system controls order, and the rendering system handles visual and audio presentation. These three should not be mixed together.

A participant can be described with a data structure such as:

{
  "id": "agent_a",
  "display_name": "Agent A",
  "persona": "Strong in rigorous analysis; restrained in expression but occasionally humorous",
  "voice": "voice_a",
  "avatar": "avatar_a",
  "constraints": {
    "max_chars": 120,
    "tone": "light, friendly, no attacks on real individuals"
  }
}

The key is not the field names, but explicitly recording role, tone, visual assets, and output constraints. Whether the model, voice method, or animation template changes later, the same data structure can be reused.

2. Ensure Experiment Fairness: Unified Inputs, Isolated Outputs

The most important engineering principle for multi-agent content is “consistent input, isolated process, traceable results.”

2.1 Consistent Inputs

All participants should receive the same task description, including:

• activity background;
• brief personas for the four roles;
• rules for the first and second rounds;
• character limits;
• prohibited content;
• output format;
• whether metaphors, puns, and exaggeration are allowed.

If one role receives a more detailed character introduction or a looser character limit, the final results are no longer comparable.

2.2 Process Isolation

During first-round generation, agents should not see one another’s answers. Otherwise, later content may be influenced by earlier results, creating an obvious order bias.

A common approach is to split the process into two stages:

Stage 1: Send the exact same task template to all four agents separately.
Stage 2: Collect the four raw results, organize them consistently, and send them back to each agent.

In the second stage, each agent reads only “what others said about this agent,” or reads the full results if the task requires it. The scope should be explicit in the rules; otherwise, the model may misunderstand the context.

2.3 Traceable Results

At minimum, each request should preserve:

• request time;
• role template used;
• full input;
• full output;
• content version number;
• generation status;
• manual edit records;
• final segments adopted.

To further demonstrate that an answer was not replaced later, a digest value can be calculated for the raw text after generation and written into the log. A digest value can only verify integrity; it cannot prove that the content itself is true or objective, but it can help detect file modification.

3. Design Prompts: Specific Rules, Clear Boundaries

For this type of task, a prompt should not merely say “please humorously evaluate the other agents.” A more stable approach is to split requirements into four parts: identity, task, format, and constraints.

A sample template:

You are Participant A.
You will interact lightly with three other agents.
Complete the following tasks:
1. Give each of the other three participants a nickname.
2. Write one specific compliment for each participant.
3. Write one good-natured tease for each participant.
4. Do not evaluate real individuals, refer to sensitive identities, or use insulting language.
5. Keep each item within the specified character limit.
6. Output strictly in JSON format without additional explanation.
Output fields:
{
  "target": "...",
  "nickname": "...",
  "praise": "...",
  "tease": "..."
}

“Good-natured teasing” must have explicit boundaries. The model can be asked to describe expression habits, answer style, and reasoning approach humorously, while avoiding appearance, region, illness, occupational discrimination, and attacks on real people.

Structured output is also easier to process later than plain text. If the model cannot reliably produce strict formatting, the program side can add parsing, validation, and retry mechanisms:

1. Try to parse the structured result.
2. Check whether required fields are present.
3. Check whether field lengths exceed limits.
4. Check for prohibited terms.
5. Retry if validation fails.
6. After repeated failures, move to manual revision.

4. Second-Round Responses: Keep Context Controllable

The second round creates the strongest interaction effect, but it is also the part most likely to suffer from context contamination.

It is better to construct an independent context for each agent. For example, Agent A receives:

You are Participant A.
The following is what other participants said about you:
- Participant B: ...
- Participant C: ...
- Participant D: ...
Write a short response:
1. You may accept reasonable observations.
2. Use humor to rebut exaggerated points.
3. Do not attack other participants.
4. Do not rewrite the first-round content.
5. Stay within the specified character limit.

This avoids indiscriminately inserting all raw text into every context and reduces interference from irrelevant information. For content that needs to show “who praises best and who roasts best,” labels can be added at the data layer, but automatic scoring should not be the only basis.

Because “roast intensity” and “praise ability” are subjective, a more reliable approach is multidimensional evaluation:

• specificity: does it point to a clear characteristic?
• novelty: does it use distinctive expression?
• friendliness: does it stay within the boundary of attack?
• readability: is it suitable for subtitles and voiceover?
• character consistency: does it fit the agent’s persona?
• audience engagement: is it likely to spark comments and discussion?

Final entertainment rankings can be completed through manual voting or audience comments rather than claiming an absolutely objective “best result.”

5. From Text to Video: Build a Layered Production Pipeline

A complete video generation workflow can be divided into five layers.

5.1 Text Layer

The text layer stores final lines, character order, shot notes, and subtitle information. Each line should have a unique ID, for example:

{
  "line_id": "round1_a_to_b",
  "speaker": "agent_a",
  "text": "Sample line",
  "duration_hint": 3.2,
  "emotion": "light",
  "scene": "scene_02"
}

Unique IDs allow subtitles, voiceover, animation, and review records to reference one another.

5.2 Audio Layer

Voiceover can use local speech synthesis or other compliant voice generation methods, but it must clearly state that the voice is synthetic and should not make viewers mistake it for the official voice of a real person or organization.

After audio generation, check:

• whether the line is complete;
• whether pronunciation is correct;
• whether pauses are natural;
• whether emotion matches the scene;
• whether volume is consistent;
• whether there is clipping, truncation, or background noise.

If a video contains multiple roles, set stable timbre and speaking rate for different characters, but do not overly imitate a specific real person’s voice.

5.3 Visual Layer

Visuals can be implemented with web technologies, including layout, fonts, character cards, dialogue bubbles, progress bars, and transitions. A web-based approach is reusable, easy to debug, and easy to adapt to different resolutions.

For example, character cards can be data-driven:

const speakers = [
  { id: "agent_a", name: "Agent A", color: "#6b8cff" },
  { id: "agent_b", name: "Agent B", color: "#ff9b6a" }
];
function renderSpeakerCard(speaker, text) {
  return `
    <section class="speaker-card" style="--accent:${speaker.color}">
      <h2>${speaker.name}</h2>
      <p>${text}</p>
    </section>
  `;
}

Do not concatenate lines directly into unescaped HTML. Real projects should escape text to prevent special characters from breaking the page structure.

5.4 Animation Layer

Animation does not need to be complex, but it should support information delivery. Options include:

• highlighting the current speaker;
• reducing opacity for other characters;
• revealing lines character by character;
• slightly enlarging keywords;
• using different colors for second-round responses;
• adding consistent transitions between chapters.

Animation timing should be driven by audio duration rather than fixed frame counts. Otherwise, any slight voiceover change will misalign subtitles and visuals.

5.5 Rendering Layer

Web animations ultimately need to become video. A stable process is usually:

Load page
→ Wait for fonts and assets to finish loading
→ Advance scenes along the timeline
→ Capture screenshots or record frame by frame
→ Composite audio
→ Generate subtitle track
→ Check audio-video sync
→ Export final file

If frame-by-frame rendering is used, fix canvas size, frame rate, fonts, and color configuration to avoid differences across machines. For long videos, split by scene so failed segments can be re-rendered locally instead of starting from scratch each time.

6. Copyright, Likeness, and Disclosure Management

These projects often use character illustrations, original avatars, fonts, sound effects, and background music. Engineering practice should maintain a registry for every asset:

Asset	Source type	Scope of use	Attribution required	Notes
Character artwork	Original or licensed	Video and thumbnail	Per license terms	Keep license records
Fonts	Compliant fonts	Subtitles and visuals	Per license terms	Check commercial-use restrictions
Sound effects	Self-made or compliant assets	Video	Follow license	Keep source files
Voiceover	Synthetic voice	Video	Disclose synthetic nature	Do not imply a real person is speaking

If characters are derivative works, clearly distinguish among homage, adaptation, and official authorization. If the project has no partnership with a relevant organization, state this objectively in the ending credits or description to avoid viewer misunderstanding.

In addition, thumbnails, titles, and comment prompts should avoid creating a false sense of authority. Viewers can be invited to vote on “who praises best and whose response is most interesting,” but subjective entertainment results should not be packaged as a scientific ranking of model capabilities.

7. Review and Publishing: Automated Checks Cannot Replace Human Judgment

Before publishing, establish three review gates.

Automated Checks

• Are prohibited terms present?
• Are character limits exceeded?
• Are any character lines missing?
• Do subtitles match the voiceover text?
• Are video duration and aspect ratio correct?
• Is every external asset recorded?

Content Review

Focus on whether sarcasm has turned into attack, whether real identity labels, sensitive topics, unverified facts, or misleading statements appear.

Viewing Review

Watch the final video at least once in full, focusing on:

• whether characters have crossed audio tracks;
• whether subtitles block important visuals;
• whether transitions are too fast;
• whether jokes fail because of poor pauses;
• whether voiceover sounds mechanical;
• whether the ending voting rules are clear.

8. Extensibility: From a Single Video to a Reusable System

After the first episode, the workflow can be further abstracted into a configuration-driven production tool. Put roles, personas, rules, lines, audio, and scenes into configuration files; later episodes only need a new topic.

Additional capabilities can include:

1. Version management: keep records of every prompt and line change.
2. Manual review checkpoints: model output must be confirmed by an editor before voiceover.
3. Multilingual subtitles: generate auxiliary subtitles without changing the original lines.
4. Comment data analysis: analyze audience preferences for characters, nicknames, and responses.
5. Quality scoring dashboard: evaluate the final video across sync, completeness, friendliness, and readability.
6. Failure retry mechanism: redo only abnormal scenes instead of regenerating everything.

Overall, the real value of the multi-agent nickname-exchange format is not simply “letting several models chat.” It demonstrates a complete intelligent content engineering workflow: unified rules ensure fairness, isolated context reduces bias, structured data improves maintainability, hash-based traceability strengthens verifiability, web rendering lowers production barriers, and human review protects expression boundaries.

When these components are modularized, the project no longer depends on one-off inspiration. It becomes a stable, reusable, and auditable content production process. Even if models, voices, or visual styles change in the future, the core task orchestration and quality control methods remain applicable.