As AI moves from code completion and Q&A assistance toward executing complex tasks, the way engineers work is changing. AI used to be a set of single-purpose tools; it can now be organized into a virtual investigation team, with separate roles handling information collection, factual research, content writing, visual expression, and process coordination. This article provides a checklist and a practical method for multi-agent investigation, so engineering teams can upgrade one-off AI prompts into a reusable automated analysis pipeline.

The scenario used here is: investigate an open source project author’s working habits, technical path, and the reasons the project gained attention quickly. Rather than relying on a single model or a single prompt, the AI engineer dispatched five types of agents: collector, researcher, writer, illustrator, and orchestrator. Working toward the same goal, the five agents extracted key information from 1,343 public discussion records and produced structured investigation conclusions. The point of the case is not “have AI write an article.” The point is an engineering pattern: a complex information task can be decomposed into distinct agent responsibilities, and task orchestration, context management, evidence-chain construction, and quality review can make an automated system deliver results that are traceable, verifiable, and ready to hand off.

1. Five Agent Roles: Decomposing a Complex Task into Executable Units

A multi-agent system cannot be differentiated by role names or prompt styling alone. Every agent needs a clear goal, inputs, outputs, tool boundaries, and acceptance criteria. The table below is a role and acceptance matrix that can be reused directly.

Agent	Input	Output	Tool boundary	Acceptance criteria
Collector agent	List of public sources, time window, field rules	Structured evidence base, deduplicated records, credibility tags	Publicly accessible content only; no private-area login, no bypassing access controls	Complete fields, traceable sources, explainable deduplication rules
Research agent	Evidence base, analysis framework, confidence rules	Independent profile, hypothesis conclusions, risk points, conflicts	Does not publish content directly, does not generate claims without evidence	Every conclusion carries an evidence ID or is explicitly marked as unconfirmed
Writing agent	Evidence summaries, outline, citation rules	Article draft, section summaries, citation mapping	Can only express what the evidence base supports; no expansion into unsupported facts	No isolated strong claims; citation coverage meets the threshold
Illustrator agent	Article topic, chapter structure, key concepts	Flowcharts, diagrams, illustration suggestions	Does not fabricate a real architecture, does not replace technical explanation	Diagrams accurately express the flow or structure
Orchestrator agent	Task status, quality metrics, human feedback	Schedule plan, review comments, final delivery package	Does not bypass human review, does not automatically execute high-risk actions	Closed-loop task status; conflicts, gaps, and retries are all recorded

The core of role design is not making AI “better at talking.” It is making every role know four things: what I am allowed to read, what I am allowed to do, what I must deliver, and when I have to stop.

2. The 1,343-Item Evidence Standard: Making Conclusions Reproducible and Auditable

The most common mistake in multi-agent investigation is treating “AI-generated content” as a “factual conclusion.” A safer approach is to build the evidence chain first, then let the model express only what the evidence supports. For 1,343 public discussion records, the collection scope, source boundaries, field definitions, and deduplication rules must all be defined explicitly.

2.1 Source Platforms and Time Window

Public information in this case can come from public developer communities, public project repositories, public documentation, public demo materials, and publicly accessible discussion pages. The collection scope includes publicly accessible content only: no private messages, no post-login data, no materials with unclear licensing, and no unpublished material.

A practical time window is “from the project’s first public appearance to the investigation start date,” prioritizing the most recent 12 months. The clearer the time window, the easier the conclusions are to reproduce. The 1,343 items are the full collection for this run; all records are retained in structured form, and for high-risk conclusions, at least 10% of the supporting evidence is extracted for manual review.

2.2 Unified Field Definitions

Raw material may include long articles, short posts, comments, quotations, and image captions. The collector agent must standardize it first:

{
  "evidence_id": "E0001",
  "summary": "The main factual point of this content",
  "published_at": "normalized timestamp format",
  "source_type": "public discussion / public documentation / public demo",
  "keywords": ["automation", "code review", "parallel tasks"],
  "credibility": "high / medium / low",
  "citation_status": "uncited / cited"
}

The value of this step is that research, writing, and review all operate on the same evidence structure, instead of repeatedly cleaning raw text.

2.3 Deduplication and Conflict Tagging

Public discussions frequently contain repeated statements, paraphrases, and similar opinions. Without deduplication, the system may count the same event multiple times. A sample of explainable deduplication thresholds:

• Text similarity greater than or equal to 0.85;
• Publication time difference less than or equal to 24 hours;
• Matching subject consistency;
• Merged items tagged as belonging to the same fact cluster.

These thresholds are examples only and must be calibrated against corpus size, language style, and platform characteristics. When items are similar but their conclusions differ, they should not be merged directly. They should be tagged as “conflicting evidence” and handed to the research agent and orchestrator agent.

2.4 Credibility Grading

Different evidence carries different reference value. Three levels are recommended:

• High credibility: explicit statements by the author, public code notes, reproducible demos;
• Medium credibility: repeatedly cited, complete context, no obvious contradictions;
• Low credibility: paraphrase, speculation, unclear context, or unverifiable source.

The research agent should prioritize high-credibility evidence, downgrade low-credibility evidence, and state the uncertainty in its conclusions.

3. From Research to Delivery: Turning Evidence into Shippable Content

3.1 Research Agent: Independent Dual-Model Profiling and Cross-Validation

The research agent is not a summarizer. It builds an analysis framework on top of the evidence base. In this case, the system called two deep research models to produce independent profiles. The goal is not two duplicate documents; the goal is to expose potential bias through differences in judgment between models.

Research dimensions can include:

• Technical output: project types, code style, toolchain choices, engineering habits;
• Collaboration style: whether execution depends on automation, whether multiple task instances run in parallel;
• Decision patterns: how the human reviews critical checkpoints, how models take on execution tasks;
• Community feedback: public discussion of efficiency, stability, and usability;
• Risk analysis: quality, security, and compliance problems introduced by automation.

When the two models agree, confidence is relatively high. When they conflict, the system must enter a review flow, and the orchestrator agent decides whether to collect additional evidence, lower the conclusion’s confidence, or retain the disagreement with an explicit uncertainty note.

3.2 Writing Agent: Evidence-Constrained Writing

The writing agent handles structured expression. To prevent free improvisation, the standard practice is evidence-constrained writing:

• Every claim must map to an evidence ID;
• Strong claims without support in the evidence base are not allowed;
• Uncertain content must use explicit qualifiers;
• Important conclusions must pass manual review.

The writing agent’s value is speed: fast first drafts and multiple expression variants. Final published content should still go through human review.

3.3 Illustrator Agent: Using Diagrams to Express Flows

Visual content in a technical article does not need to be elaborate. The key is that it accurately expresses structure. Based on topic and chapter structure, the illustrator agent can generate illustration suggestions such as:

• An agent collaboration flow diagram;
• An evidence-chain construction flow diagram;
• A human-in-the-loop review cycle diagram;
• A task orchestration and state transition diagram.

The illustrator agent’s output should not replace a real architecture description. It works best as supporting expression that helps readers grasp a complex flow quickly.

4. Mapping Evidence to Conclusions About a Technical Person: Avoiding Direct Assertions

When investigating a technical person, model-generated descriptions must not be treated as facts. The safer approach is to build an evidence mapping for each key conclusion, including example evidence IDs, an evidence summary, and a confidence level.

Key conclusion	Example evidence IDs	Evidence summary	Confidence	Notes
The author tends to delegate code production to AI coding tools and focuses human effort on reviewing key parts	E0018, E0037, E0109	Multiple public discussions show extensive use of AI coding tools for basic implementation, together with explicit emphasis on human review of critical modules	High	Cross-corroborated by multiple sources, with explicit statements about human review
The author runs multiple AI instances in parallel	E0214, E0301	Public content mentions running several task instances simultaneously to increase throughput and compare results	Medium	Mentioned, but execution details are incomplete
The author uses scheduled tasks and AI assistance to handle social noise	E0421, E0518	Public content mentions periodically scanning social mentions and using AI to identify spam replies	Medium	Platform rules and authorization boundaries need to be added
The author mines product direction from community discussions	E0702, E0825	Public content shows the author crawling developer community discussions, building a local database, and analyzing pain points	Medium	Data usage boundaries need to be stated

The purpose of this table is to move conclusions from “the model thinks” to “the evidence supports.” Under evidence constraints and human review, a multi-agent system can produce output close to a structured research report. The preconditions are that public material is traceable, key facts are verifiable, and the risk level stays manageable.

5. Compliance Boundaries for Automated Social Handling

Analysis of someone’s working habits may surface details such as “using AI to identify spam replies and then perform blocking actions.” Automation like this improves information governance efficiency, but it requires compliance boundaries.

Recommended principles:

• Respect the target platform’s rules; do not use automation to bypass platform limits;
• Process only data from accounts you own or accounts with explicit authorization;
• Set human review thresholds for actions such as blocking, blacklisting, deleting, and publishing;
• Do not execute high-risk actions automatically, for example permanent bans, bulk deletion, or public posting;
• Provide a misjudgment appeal and rollback mechanism;
• Set a circuit breaker for repeated misjudgments, for example suspending the automated task after three consecutive errors of the same type.

The goal of such a system is not “zero humans.” It is handing repetitive actions to automation while keeping risk judgment with people.

6. Engineering Architecture: How a Multi-Agent System Runs Reliably

Sustained collaboration among five agents cannot rely on natural language prompts alone; it needs engineering support.

6.1 Orchestration Layer

The orchestration layer handles task decomposition, state management, and dependency control. It needs to know which tasks can run in parallel, which must run sequentially, and which need retries after failure.

Example flow:

initialize task
-> collect public content
-> build evidence base
-> launch dual-model independent research
-> merge research results
-> generate writing outline
-> generate article draft
-> generate illustration suggestions
-> orchestrator review
-> human confirmation
-> final delivery

Task states can include: pending, in progress, awaiting review, completed, failed and retrying, and rejected by a human.

6.2 Context Management Layer

One of the challenges of multi-agent systems is context that is either too long or too scattered. The system needs to maintain different context for different roles:

• The collector agent needs data cleaning rules;
• The research agent needs an evidence base summary;
• The writing agent needs structure templates and citation rules;
• The orchestrator agent needs global progress and quality metrics.

A layered strategy works well:

• Short-term context: current task inputs and outputs;
• Medium-term context: evidence summaries and interim conclusions;
• Long-term context: project goals, templates, rules, and audit logs.

Layered management avoids stuffing everything into one context window, which reduces the risk of degraded model attention and misreading.

6.3 Permission and Security Control Layer

If agents hold external operation permissions, such as network access, file writes, code modification, content publishing, or account operations, a permission tiering mechanism is mandatory.

Recommended principles:

• Read-only by default: reading public data is the only permission allowed by default;
• Least privilege: grant only the capabilities required to complete the task;
• Human confirmation for sensitive operations: deletion, publishing, blacklisting, payments, and other high-risk actions require human approval;
• Full audit: log agent actions, inputs, outputs, and results;
• Anomaly circuit breaker: suspend the task on consecutive failures or abnormal behavior.

6.4 Observability and Cost Governance

Multi-agent systems generate large numbers of calls, so observability work is required. Recommended records include:

• Input summary for each agent;
• Output summary for each agent;
• Call duration;
• Failure reasons;
• Evidence citation status;
• Human modification rate;
• Model call cost;
• Task retry count.

If a team wants to productize similar capabilities, it can build on mainstream cloud service components, such as object storage, message queues, container platforms, logging services, and monitoring and alerting, to handle task scheduling, data persistence, runtime monitoring, and alerting. This gradually converts a one-off agent experiment into a production-grade system that can run continuously.

7. Quality Control: Preventing Output from Becoming “Professional-Looking Hallucination”

Multi-agent collaboration improves efficiency, but without quality control it can also produce hallucination at scale. A multi-layered quality mechanism is needed.

7.1 Citation Coverage Template

Every important conclusion in the article should be linked to an evidence ID. The following template can be used for automated checks:

Conclusion ID	Conclusion summary	Evidence IDs	Confidence	Reviewer	Status
C001	Some conclusion	E0001, E0025	High	TBD	Pending review
C002	Some conclusion	E0071	Medium	TBD	Needs more evidence

The system can automatically check:

• Which paragraphs have no citations;
• Which citations map to multiple pieces of evidence;
• Which evidence was never used;
• Whether any isolated conclusions exist.

Low citation coverage signals that the content relies too heavily on model generation and needs to be reviewed again.

7.2 Conflict Detection

When two research models give different conclusions on the same question, the system should not simply pick one. It should enter a conflict-handling flow:

• Check evidence strength;
• Check whether the context is consistent;
• Determine whether the difference comes from different time ranges;
• Collect additional evidence if necessary;
• Retain an explicit uncertainty statement.

7.3 Human Review Checkpoints

However high the level of automation, human review cannot be skipped. The focus of human review is not rewriting the whole document, but confirming:

• Whether the facts are accurate;
• Whether the conclusions are overstated;
• Whether the citations are sufficient;
• Whether the expression is compliant;
• Whether there are misleading implications.

8. Risks and Prohibited Practices: Automated Investigation Does Not Replace Engineering Judgment

Multi-agent investigation is efficient, but it carries clear risks. The following prohibitions should be made explicit in practice:

• Do not collect unpublished data;
• Do not bypass platform access restrictions;
• Do not make personality inferences or apply labels to individuals;
• Do not automatically publish sensitive content;
• Do not generate strong conclusions when evidence is insufficient;
• Do not let agents automatically perform high-risk account operations.

Common risks include:

1. Hallucination risk: the model may produce plausible-sounding conclusions when evidence is thin. The remedies are evidence binding, citation checks, and human review.
2. Privacy and compliance risk: public information does not mean unlimited use. Collection, storage, analysis, and publication all need to consider authorization scope, privacy protection, and platform rules.
3. Over-automation risk: if the system automatically performs high-risk actions such as blacklisting, publishing, or modifying code, a wrong judgment can cause irreversible damage.
4. Difficult quality assessment: multi-agent output often looks complete while its actual quality may be low. Quantifiable metrics are needed rather than subjective impressions.

9. A Reusable Methodology: From a Single Investigation to a Long-Term Capability

This case can be abstracted further into a general method.

9.1 Define the Goal and the Boundaries

Before any multi-agent task begins, define the goal: produce a report, analyze code, investigate a person, monitor risk, or support content production? Also define the boundaries: which data may be collected, which operations must never be executed, and which conclusions must never be generated automatically.

9.2 Decompose the Task into Roles

The clearer the roles, the more stable the system. Each role should have explicit inputs, explicit outputs, explicit tools, explicit acceptance criteria, and an explicit failure-handling path.

9.3 Establish a Unified Evidence Structure

The evidence structure is the foundation of automated research. Without a unified structure, downstream analysis easily turns into free-form model output.

9.4 Introduce Dual-Track or Triple-Track Validation

A single model’s judgment is easily influenced by expression style. Adding multiple research agents or independent verification agents improves conclusion stability.

9.5 Keep a Human Loop

Automated systems suit repetitive, structured, verifiable tasks. When the work involves value judgments, compliance judgments, and final publication, a human loop remains necessary.

9.6 Measure and Optimize Continuously

Long-term tracking of these metrics is recommended:

• Task success rate;
• Average completion time;
• Human modification rate;
• Citation coverage;
• Conflict resolution rate;
• Cost per task;
• Error interception rate.

These metrics help a team determine whether a multi-agent system genuinely improves efficiency rather than creating a new management burden.

Conclusion: The Engineer’s New Role Is System Designer and Reviewer

On the surface, this case is about an AI engineer dispatching five types of agents to investigate a technical person. In substance, it shows a shift in AI-native development practice. When AI can take on collection, research, writing, visual generation, and task coordination, the engineer’s core capability is no longer writing every line of code. It is defining the problem, decomposing tasks, designing how agents collaborate, building evidence and validation systems, controlling security and compliance boundaries, and reviewing the final output.

A multi-agent system is not a way to replace people with AI. It hands repetitive, verifiable, decomposable work to an automated pipeline while keeping judgment, decisions, and accountability with people. Mature AI engineering practice does not chase “full automation.” It builds a human-machine collaboration system that is controllable, auditable, and iterable.