==================== START: .fortura-core/reference/agent-type-guide.md ====================
<!-- Powered by Fortura™ Core -->

# Agent Type Selection Guide

This guide helps you determine the appropriate agent type based on your agent's purpose, capabilities, and operational context.

---

## Agent Type Overview

### 1. Planning Agent

**Purpose:** Research, analysis, strategy, design, documentation creation

**Characteristics:**
- Operates in planning/discovery phase (before code implementation)
- Creates structured documents from templates
- High dependency count (15-30 items) is acceptable
- Rich interactions with elicitation methods
- Template-driven workflows
- Heavy collaboration with user

**Context Constraints:**
- Doesn't need to preserve coding context
- Can load large knowledge bases
- May process multiple templates
- Extensive reference materials available

**Examples:**
- **Business Analyst** - Market research, competitive analysis, brainstorming, project briefs
- **Product Manager** - PRD creation, sprint planning, feature prioritization
- **Solution Architect** - Architecture design, technology selection, system specifications
- **UX Expert** - User research, wireframes, interaction design, usability analysis

**When to Choose:**
- Agent creates comprehensive documents before development
- Needs access to extensive reference materials
- Performs research or analysis work
- Heavy template usage expected
- User collaboration throughout process

**Design Implications:**
- Load all necessary templates and knowledge bases
- Use advanced elicitation methods (1-9 pattern)
- Include validation checklists for quality
- Provide comprehensive output formats
- Interactive mode default, YOLO as option

---

### 2. Development Agent

**Purpose:** Code implementation, testing, direct execution

**Characteristics:**
- Operates during implementation phase
- Minimal dependencies (3-8 items) **CRITICAL**
- Lean, focused on coding tasks
- Preserves maximum context for code
- Limited template usage
- Quick, efficient execution

**Context Constraints:**
- **CRITICAL:** Must preserve large context window for code files
- Cannot afford large knowledge bases
- Minimal documentation loaded
- Streamlined workflows only

**Examples:**
- **Full-Stack Developer** - Code implementation, refactoring, debugging
- **QA Engineer** - Test creation, test execution, bug validation

**When to Choose:**
- Agent writes or modifies code
- Needs to see multiple code files simultaneously
- Implements features from specifications
- Runs tests and validates implementations
- Context window primarily for code, not documentation

**Design Implications:**
- **Keep dependencies minimal** (under 8 total)
- No large knowledge bases or reference docs
- Simple, direct commands
- Lean checklists (just essentials)
- No complex elicitation workflows
- Focus on execution, not exploration

**Anti-Patterns to Avoid:**
- ❌ Loading architecture documents during coding
- ❌ Processing large templates while implementing
- ❌ Including brainstorming techniques
- ❌ Reference to market research or business analysis
- ❌ Any dependency not directly needed for coding

---

### 3. Coordination Agent

**Purpose:** Orchestration, workflow management, agent switching, team coordination

**Characteristics:**
- Meta-level view across agents
- Manages handoffs between agents
- Handles workflow routing
- Facilitates multi-agent collaboration
- Moderate dependencies (8-15 items)
- Hybrid interaction style

**Context Constraints:**
- Needs awareness of all agents' capabilities
- Maintains workflow state
- Manages transitions between phases
- Doesn't execute detailed tasks itself

**Examples:**
- **Orchestrator** - Agent switching, workflow guidance, command interpretation
- **Scrum Master** - Sprint facilitation, story grooming, backlog management

**When to Choose:**
- Agent manages other agents
- Handles transitions between work phases
- Provides workflow guidance
- Facilitates team collaboration
- Routes tasks to appropriate agents

**Design Implications:**
- Include knowledge of all agents and their roles
- Workflow management utilities
- Transition handoff procedures
- State tracking mechanisms
- Fuzzy matching for intent interpretation
- Multi-mode support (KB mode, party mode, etc.)

---

### 4. Process Agent

**Purpose:** Specialized, repeatable workflows; domain-specific procedures

**Characteristics:**
- Highly structured workflow
- Checklist-driven execution
- Deep expertise in specific process
- Narrow focus, deep capability
- Moderate dependencies (8-15 items)
- Step-by-step execution

**Context Constraints:**
- Focused on single process or domain
- Follows strict sequence
- Limited deviation from workflow
- Quality gates at key points

**Examples:**
- **Product Owner** - Backlog management, story refinement, epic breakdown
- **Release Manager** - Deployment procedures, release validation, rollback protocols

**When to Choose:**
- Agent follows specific, repeatable process
- Domain expertise required (e.g., Agile ceremonies, release management)
- Workflow has clear sequence and validation points
- Specialization more valuable than generalization

**Design Implications:**
- Sequential workflow with clear phases
- Validation checkpoints throughout
- Domain-specific checklists
- Specialized templates for process outputs
- Strict adherence to methodology
- Process compliance validation

---

### 5. Conversational Agent

**Purpose:** Dialogue, Q&A, tutoring, customer support, general assistance

**Characteristics:**
- Natural dialogue focus
- Context maintenance across turns
- Empathetic, engaging responses
- Flexible, adaptive interaction
- Moderate dependencies (5-12 items)
- Relationship building

**Context Constraints:**
- Conversational context primary
- Less structured than other types
- Adapts to user's communication style
- Maintains personality consistency

**Examples:**
- **Customer Support Agent** - Answer questions, troubleshoot issues, provide guidance
- **Tutor** - Explain concepts, provide examples, assess understanding
- **Advisor** - Provide recommendations, discuss options, guide decisions

**When to Choose:**
- Primary interaction is dialogue, not task execution
- Needs to understand context across multiple turns
- Personality and rapport important
- Flexible, adaptive responses valued over rigid workflows

**Design Implications:**
- Conversational persona with clear personality
- Context awareness across dialogue turns
- Empathetic response patterns
- Question-answering capabilities
- Knowledge base for domain expertise
- Minimal rigid workflows (unless specific procedure requested)

---

## Decision Framework

### Step 1: Primary Activity

What is the agent's main activity?

| If agent primarily... | Consider type... |
|-----------------------|------------------|
| Creates strategic documents before development | **Planning** |
| Writes or modifies code | **Development** |
| Routes work between agents | **Coordination** |
| Executes specific repeatable workflow | **Process** |
| Engages in dialogue and answers questions | **Conversational** |

---

### Step 2: Context Requirements

How much context does the agent need?

| Context Need | Suitable Types | Unsuitable Types |
|--------------|----------------|------------------|
| Large (templates, knowledge bases, references) | Planning, Coordination | Development |
| Minimal (lean, code-focused) | Development | Planning |
| Moderate (workflow-specific) | Process, Conversational | Development |
| Meta (all agents' capabilities) | Coordination | Development |

---

### Step 3: Interaction Style

How does the agent interact with users?

| Interaction Style | Best Type |
|-------------------|-----------|
| Template-driven document creation with elicitation | Planning |
| Direct commands, quick execution | Development |
| Workflow guidance, agent switching | Coordination |
| Step-by-step procedure with validation gates | Process |
| Natural dialogue, Q&A | Conversational |

---

### Step 4: Output Format

What does the agent produce?

| Primary Output | Best Type |
|----------------|-----------|
| Comprehensive documents (PRDs, architecture, research reports) | Planning |
| Code, tests, implementations | Development |
| Workflow state, handoff artifacts | Coordination |
| Process compliance artifacts (stories, backlogs, release notes) | Process |
| Answers, explanations, recommendations | Conversational |

---

### Step 5: Dependency Count

How many dependencies are appropriate?

| Agent Type | Dependency Range | Why |
|------------|------------------|-----|
| Planning | 15-30 | Needs extensive reference materials, templates, knowledge bases |
| Development | 3-8 | **CRITICAL:** Must preserve code context, minimal documentation |
| Coordination | 8-15 | Needs workflow tools, agent directories, transition procedures |
| Process | 8-15 | Workflow-specific templates, checklists, domain knowledge |
| Conversational | 5-12 | Domain knowledge, FAQ databases, conversational patterns |

---

## Hybrid Agents (Advanced)

Some agents may combine characteristics of multiple types. Handle these carefully:

### Planning + Process

**Example:** Product Manager who both creates PRDs (planning) and manages sprint workflows (process)

**Approach:**
- Design as Planning agent with process-specific tasks
- Include both document templates and workflow checklists
- Separate commands for planning vs. process activities
- Use mode switching if workflows are very different

---

### Coordination + Conversational

**Example:** Orchestrator who both routes tasks and engages in natural dialogue about capabilities

**Approach:**
- Design as Coordination agent with conversational persona
- Natural language command interpretation
- Dialogue for clarification, execution for routing
- Fuzzy matching for intent understanding

---

### Process + Conversational

**Example:** Tutor who follows teaching methodology (process) through dialogue (conversational)

**Approach:**
- Design as Conversational agent with structured curriculum
- Teaching methodology as background process
- Dialogue-driven progression through curriculum
- Checkpoints for assessment within conversation

---

## Migration and Evolution

Agents can evolve over time. Common transitions:

### From Conversational to Process

**When:** Repetitive workflows emerge from dialogue patterns

**How:**
- Extract common workflows into tasks
- Add structured templates for frequent outputs
- Maintain conversational wrapper around process

---

### From Planning to Coordination

**When:** Agent starts managing handoffs to other agents

**Approach:**
- Add coordination capabilities as commands
- Include agent directory and workflow mapping
- Separate planning from coordination commands clearly

---

### From Process to Planning

**When:** Process agent needs richer document creation

**Approach:**
- Add templates and elicitation methods
- Increase dependencies for reference materials
- Maintain process workflow as core, add planning capabilities

---

## Common Mistakes

### Mistake 1: Development Agent with Planning Dependencies

**Problem:**
```yaml
# BAD: Development agent
dependencies:
  data:
    - market-research-techniques.md
    - brainstorming-methods.md
    - competitor-analysis-framework.md
  templates:
    - prd-template.yaml
    - architecture-template.yaml
  tasks:
    - create-comprehensive-documentation.md
```

**Why Bad:** Development agent needs code context, not planning materials.

**Solution:** Create separate Planning agent for documentation. Development agent stays lean:
```yaml
# GOOD: Development agent
dependencies:
  checklists:
    - story-definition-of-done.md
  tasks:
    - implement-story.md
```

---

### Mistake 2: Conversational Agent with Rigid Workflow

**Problem:**
```yaml
# BAD: Conversational agent with strict process
tasks:
  - step-1-initialization.md
  - step-2-data-collection.md
  - step-3-analysis.md
  - step-4-reporting.md
```

**Why Bad:** Conversational agents should adapt to dialogue flow, not force sequence.

**Solution:** Use conversational patterns with embedded guidance:
```yaml
# GOOD: Conversational agent
data:
  - conversation-patterns.md
  - domain-knowledge.md
  - faq-database.md
```

---

### Mistake 3: Unclear Type Leading to Bloat

**Problem:** Agent tries to be everything—creates docs, writes code, manages workflow, tutors users.

**Why Bad:** No clear focus. Dependencies and commands grow endlessly. User doesn't know when to use it.

**Solution:** Split into multiple specialized agents:
- Planning agent for documentation
- Development agent for code
- Coordination agent for workflow
- Conversational agent for tutoring

---

## Validation Questions

Before finalizing agent type, answer these:

1. **Context Question:** Will this agent need to see large code files simultaneously?
   - Yes → Must be Development type
   - No → Can be other types

2. **Output Question:** Does this agent primarily produce code?
   - Yes → Development type
   - No → Other types

3. **Interaction Question:** Is rigid step-by-step workflow required?
   - Yes → Process type
   - No → Planning or Conversational

4. **Collaboration Question:** Does this agent manage other agents?
   - Yes → Coordination type
   - No → Other types

5. **Dependency Question:** Will this agent need 15+ dependencies?
   - Yes → Planning type (only)
   - No → Development, Process, Coordination, or Conversational

If answers conflict, you may need to split into multiple agents.

---

## Summary: Quick Reference

| Type | Dependencies | Output | Interaction | When to Use |
|------|--------------|--------|-------------|-------------|
| **Planning** | 15-30 | Documents | Template + Elicitation | Before development, research, design |
| **Development** | 3-8 | Code | Direct commands | During implementation, coding |
| **Coordination** | 8-15 | Workflow state | Guidance + Routing | Managing agents, transitions |
| **Process** | 8-15 | Process artifacts | Step-by-step | Repeatable workflows, domain expertise |
| **Conversational** | 5-12 | Dialogue | Natural language | Q&A, tutoring, support |

==================== END: .fortura-core/reference/agent-type-guide.md ====================