What is Agentic Prompting? Complete Mastery of Multi-Agent System Design

Introduction: The Limitations Left Behind by Episode 12

In Episode 12, we covered the ReAct pattern. A single agent repeats Thought → Action → Observation, reasoning and acting autonomously. And at the end, we left this preview:

"There are limits to what a single agent can achieve for complex goals. If you separate the agent that plans, the agent that executes, and the agent that reviews, you can obtain more sophisticated results."

Why is a single agent insufficient? Let's look at a concrete situation.

---

Suppose you made this request to AI:

"Analyze the latest blog posts from three competitors, find the weaknesses in our content strategy, and draft a content calendar for next month."

What would happen if a single ReAct agent handled this task?

Thought: Search for competitor A's blog first.
Action: web_search("Competitor A latest blog")
Observation: ...
Thought: Search for competitor B.
Action: web_search("Competitor B latest blog")
Observation: ...
(Repeat 10+ steps)
Thought: Now analyze and create the calendar.
Action: final_answer("...")

Several problems arise.

First, context explosion. As search results accumulate, the context window is consumed rapidly. Information collected early gets pushed out of the model's attention as we progress.

Second, quality degradation. When one agent does searching, analyzing, strategy planning, and document writing all at once, the quality of each step becomes averaged. The result is mediocre—neither a search expert, nor an analysis expert, nor a writing expert.

Third, no review possible. The agent reviews its own conclusions. It's hard for it to catch its own errors.

A multi-agent system solves these problems. One complex task is handled by multiple agents splitting the work. Each focuses on their own role, and an orchestrator manages the overall flow.

---

1. Structure of a Multi-Agent System

1.1. Four Core Roles

A multi-agent system typically has four roles. Not every system needs all four, but understanding this structure lets you design any task with agents.

Orchestrator The conductor managing the overall task. It decomposes the task, decides what to assign to which agent, and synthesizes the results. It doesn't execute directly—only coordinates.

Planner Receives a goal and creates an execution plan. It decides "what should be done in what order." When the plan changes, it sends updated instructions to the execution agents.

Executor Performs the actual work. Web search, code execution, document writing, API calls—concrete actions. A system can have multiple executors, each handling different tools.

Critic / Reviewer Evaluates the output. Finds errors, checks quality, and suggests improvements. Because the critic independently reviews the executor's results, it has higher error detection ability than a single agent.

1.2. Overall Flow

[User Request]
      ↓
[Orchestrator] ← Decompose and coordinate overall task
  ├── [Planner]     ← Establish execution order and strategy
  ├── [Executor A]  ← Search and collect data
  ├── [Executor B]  ← Analyze and organize
  └── [Critic]      ← Validate result quality
      ↓
[Final Output]

---

2. Practical Example 1: Content Strategy Development

Let's see how the "competitor analysis + content calendar writing" task we mentioned earlier changes when designed as a multi-agent system.

2.1. Orchestrator Prompt

<role>
  You are the orchestrator of a content strategy project.
  You receive the user's request, distribute tasks to subordinate agents,
  and synthesize results to create a final report.
</role>

<task>
  Analyze the latest content from 3 competitors (A, B, C),
  identify improvements to our content strategy,
  and present a draft content calendar for next month.
</task>

<agents>
  Available subordinate agents:
  - research_agent: Web search and data collection
  - analysis_agent: Data analysis and insight derivation
  - writer_agent: Final document and calendar writing
  - critic_agent: Result review and quality evaluation
</agents>

<process>
  1. Instruct research_agent to collect latest content from each competitor
  2. Instruct analysis_agent to analyze collection results
  3. Instruct writer_agent to draft the calendar
  4. Instruct critic_agent to review the draft
  5. Finalize by reflecting review feedback
</process>

2.2. Research Agent Prompt

<role>
  You are a content research specialist agent.
  You collect information from the web per the orchestrator's instructions
  and return them in structured form.
  Collecting is your only role. You do not analyze or offer opinions.
</role>

<output_format>
  Return only in the format below:
  {
    "company": "Company name",
    "posts": [
      {
        "title": "Post title",
        "date": "Date",
        "topic": "Topic",
        "key_points": ["Key point 1", "Key point 2"]
      }
    ]
  }
</output_format>

2.3. Analysis Agent Prompt

<role>
  You are a content analysis specialist agent.
  You receive data collected by the research agent and derive patterns and insights.
  You do not collect new data or speculate.
  You analyze only based on the given data.
</role>

<instructions>
  Analyze the following:
  1. Topics competitors commonly cover (= what the market wants)
  2. Topics competitors don't cover (= our opportunity)
  3. Areas overlapping with our content (= where differentiation is needed)
  4. Our strengths and weaknesses vs competitors
</instructions>

2.4. Critic Agent Prompt

<role>
  You are a quality review specialist agent.
  You find errors and improvement points in results created by other agents.
  You do not praise. You only present problems and improvement directions.
</role>

<checklist>
  You must review these items:
  - [ ] Are there claims unsupported by data?
  - [ ] Are there logically weak connections?
  - [ ] Are there unexecutable plans?
  - [ ] Are important competitor trends missing?
</checklist>

<output_format>
  Problems: (List of found issues)
  Severity: High / Medium / Low
  Improvement Direction: (Specific correction method)
  Requires Rework: YES / NO
</output_format>

---

3. Practical Example 2: Code Review System

The most practical application of multi-agents in software development.

[User] Review this PR code

[Orchestrator]
  → security_agent: Scan security vulnerabilities
  → performance_agent: Analyze performance issues
  → style_agent: Review code style and readability
  → test_agent: Verify test coverage
  → summary_agent: Synthesize overall review

Security Agent Prompt

<role>
  You are a code security specialist agent.
  You find vulnerabilities based on OWASP Top 10 standards.
  You do not evaluate if functionality is correct. You only look at security.
</role>

<focus_areas>
  - SQL injection possibilities
  - XSS vulnerabilities
  - Missing authentication/authorization
  - Sensitive information exposure (API keys, hardcoded passwords)
  - Missing input validation
</focus_areas>

<output_format>
  [Vulnerability Level: CRITICAL / HIGH / MEDIUM / LOW]
  Location: (filename:line_number)
  Problem: (Specific vulnerability description)
  Fix Method: (Include code examples)
</output_format>

Performance Agent Prompt

<role>
  You are a code performance specialist agent.
  You find time complexity, space complexity, and unnecessary operations.
  You do not evaluate security or style. You only look at performance.
</role>

<focus_areas>
  - Loops with O(n²) or higher
  - Unnecessary database N+1 queries
  - Memory leak possibilities
  - Sections where caching can be applied
</focus_areas>

Because each agent focuses only on their specialty, the result is much more precise than a single agent doing an "overall review."

---

4. Orchestrator Design Principles

The most important thing in a multi-agent system is the orchestrator. If the orchestrator is poorly designed, the entire system collapses.

4.1. Task Decomposition — What to Whom

The orchestrator's first role is task decomposition. It breaks large tasks into independently executable units.

# Bad decomposition — Too many dependencies between agents
Agent A: Collect data, analyze it, and write a draft
Agent B: Based on A's draft, review it and edit it too

# Good decomposition — Clear roles for each
Agent A: Collect only data and return as JSON
Agent B: Analyze only A's returned JSON and return insights
Agent C: Write a draft only based on B's insights
Agent D: Review only C's draft and return problems

The key is clearly defining each agent's input and output. Clear input lets the agent work without confusion, and clear output lets the next agent use the result.

4.2. Order Control — Sequential vs Parallel

The orchestrator also decides the order in which agents run.

Sequential Execution: The previous agent's output becomes the next agent's input

Research → Analysis → Writing → Review
(Changing order breaks it)

Parallel Execution: Independent tasks run simultaneously to save time

Competitor A Research ─┐
Competitor B Research ─┼→ [Synthesis] → Analysis → Writing
Competitor C Research ─┘
(Three researches are independent so can run simultaneously)

Parallel execution saves significant time, but requires a step to synthesize each agent's results.

4.3. Result Validation — When to Re-run

After receiving an agent's result, the orchestrator decides whether to proceed to the next step or re-run.

def orchestrate(task: str) -> str:
    # 1. Establish plan
    plan = planner_agent(task)

    # 2. Research (parallel)
    results = parallel_execute([
        research_agent(company) for company in COMPANIES
    ])

    # 3. Analyze
    analysis = analysis_agent(results)

    # 4. Write draft
    draft = writer_agent(analysis)

    # 5. Review — rework if problems
    review = critic_agent(draft)
    if review.needs_revision:
        draft = writer_agent(analysis, feedback=review.feedback)

    return draft

Limit rework loops to 2–3 iterations maximum. If the reviewer keeps saying "rewrite," you'll get stuck in an infinite loop.

---

5. Inter-Agent Communication Design

How agents exchange information with each other is the core technology of multi-agent systems.

5.1. Structured Output — Pass JSON

Inter-agent communication is much more stable with structured formats than natural language. The content from Episode 9 (Structured Output) applies directly here.

# Bad communication — Pass results in natural language
Research agent output:
"Competitor A has been writing a lot about AI recently,
 and especially content about prompt engineering is very popular..."

# Good communication — Pass structured JSON
{
  "company": "Competitor A",
  "recent_topics": ["AI Prompt", "LLM Usage", "ChatGPT Practice"],
  "top_performing": {
    "title": "Complete Guide to Prompt Engineering",
    "estimated_traffic": "high",
    "engagement": "very_high"
  },
  "content_frequency": "3x per week",
  "avg_length": "3000 characters"
}

The next agent receiving JSON can process the data directly without natural language parsing. Error possibility decreases and consistency increases.

5.2. Shared Memory — A Space All Agents Can See

Information that agents need to commonly reference is stored in shared memory.

# Shared memory structure
shared_context = {
    "task": "Competitor analysis + content calendar",
    "target_company": "Our company",
    "our_recent_posts": [...],
    "constraints": {
        "budget": "Max 20 posts per month",
        "team_size": "2 people",
        "publish_schedule": "2x per week"
    },
    "collected_data": {},   # Filled by research agent
    "analysis": {},         # Filled by analysis agent
    "draft": "",            # Filled by writer agent
    "review_feedback": []   # Filled by critic agent
}

Each agent writes its result to shared memory, and the next agent reads from there. The structure is simpler than the orchestrator passing data directly between agents.

---

6. Practical Example 3: Automated Report Generation System

A commonly used multi-agent pattern. A pipeline that collects data and creates reports.

[Input] "Analyze last month's service usage data and create an executive report"

[Data Collection Agent]
Input: Analysis period (last month)
Output: {
  "dau": [daily DAU array],
  "revenue": [daily revenue array],
  "churn_rate": 0.032,
  "new_users": 1423,
  "top_features": ["Feature A", "Feature B", "Feature C"]
}

[Analysis Agent]
Input: Above JSON
Output: {
  "highlights": ["DAU up 12% vs previous month", "Churn rate improved 0.3%p"],
  "concerns": ["Weekend DAU sharp decline pattern", "Feature C usage down"],
  "recommendations": ["Strengthen weekend push notifications", "Feature C UI needs improvement"]
}

[Writing Agent]
Input: Analysis results
Role: Transform into report format easy for executives to read
Output: Completed report in markdown

[Critic Agent]
Input: Draft report
Check: Numerical errors / logical leaps / executive report suitability
Output: Revision points or final approval

Because each agent's role is clearly separated, you can replace the analysis agent without affecting the others. Maintenance is easy and improvement is straightforward.

---

7. Multi-Agent Failure Patterns

7.1. Role Contamination — Agents Do Other Agents' Jobs

# Bad case
Research agent output:
"Competitor A writes a lot about AI.
 (Analysis) This is because the AI market is growing,
 (Suggestion) so we should also increase AI content."
 ← Research agent did analysis and suggestion too

When role contamination occurs, the input the analysis agent receives is already subjective interpretation mixed with data. Errors propagate to the next agent.

The solution is to explicitly state "what not to do" in the system prompt.

<role>
  You are a data collection specialist agent.
  You only collect. You absolutely never analyze or offer opinions.
  Never use expressions like "seems to be ~" or "should ~".
  Return only observed facts.
</role>

7.2. Hallucination Propagation — Errors Amplify

When agent A outputs wrong information and agent B accepts it as fact and analyzes it, agent C works on top of even more concrete errors. By the end of the pipeline, a completely different problem appears from the initial error.

Research agent: "Competitor A gets 500K monthly visitors." (← Actually 50K, error)
Analysis agent: "Based on 500K, we only have 2% market share..."
Writing agent: "In this dire situation of just 2% market share..."
→ Entire report written on wrong numbers

There are two solutions.

First, instruct the critic agent to verify the source of every figure.

<instructions>
  Demand original source for every numerical claim.
  Figures without explicit source are marked "source unknown"
  and classified as items needing verification.
</instructions>

Second, include confidence level in agent output.

{
  "claim": "Competitor A gets 500K monthly visitors",
  "source": "SimilarWeb estimate",
  "confidence": "medium",
  "note": "Estimate with ±30% possible error"
}

7.3. Responsibility Vacuum — No One Makes Final Decision

Agents defer decisions to each other and nobody reaches a final conclusion.

Analysis agent: "Seems the writing agent should judge this."
Writing agent: "This decision should be made by the analysis agent."
Orchestrator: ???

The solution is to give the orchestrator clear final decision authority.

<role>
  You are the final decision maker.
  When subordinate agents' opinions conflict or are unclear,
  you judge and decide directly.
  "I'll ask the agent again" is not an option.
  Make the best decision with available information.
</role>

7.4. Over-Differentiation — Making Simple Things Complex

Attaching an orchestrator, planner, writer, and critic to write a 3-line email is over-engineering. Each LLM API call costs money and increases latency.

# These tasks are fine with a single agent
- Answer simple questions
- Translate short text
- Transform data into set format

# Multi-agent needed for:
- Synthesizing multiple data sources
- Multiple specialized reviews needed
- When errors have serious consequences
- Stage-by-stage quality assurance required

---

8. Single Agent vs Multi-Agent

In practice, choose based on task complexity and quality requirements. Attaching multi-agent to simple tasks only increases cost with no benefit. Conversely, assigning complex multi-step tasks to a single agent results in poor quality.

---

Conclusion: How to Design an Agent Team

Episodes 1–12 covered writing good prompts. Better questions, clearer structure, more accurate context. Episode 12 covered the ReAct pattern where a single agent judges and acts autonomously.

Episode 13 is one level up. Not designing a single agent, but designing an agent team. Like human organizations, a team with clear roles and structured communication solves complex problems better than a genius working alone.

The core principle is simple: Give each agent one role, make input/output clear, and have the orchestrator coordinate the whole.

Summary of Core Principles

Toward Episode 14

Once you can design multi-agent systems, a natural next question emerges.

"How do I make these agents reason more complexly?"

Recently emerged Reasoning Models (o1, o3, Claude 3.7 Sonnet, etc.) think differently from existing models. They go through lengthy internal reasoning before producing answers—prompting these models requires different approaches than before.

[Episode 14: Prompting Reasoning Models – How to Properly Leverage o1, o3] covers how Reasoning Models work, their differences from existing models, and prompting strategies specialized for these models.