Path 1: You Build It

The traditional approach — your team writes the agent from scratch:

Your Code
  ├── Agent loop (prompt → LLM → action → observe → repeat)
  ├── Tool integrations (file I/O, APIs, databases)
  ├── Memory management (context, history, RAG)
  ├── Error handling and retry logic
  ├── Guardrails and safety checks
  └── Monitoring and logging

When to choose Path 1:

• You need full control over every decision
• You have AI/ML engineering expertise on your team
• Your use case has unique requirements no framework covers
• You're building a product where the agent IS the product

Frameworks that help:

• LangChain — most popular, huge ecosystem
• CrewAI — multi-agent orchestration
• AutoGen — Microsoft's multi-agent framework
• Anthropic Agent SDK — Claude-native agent building

Typical timeline: 2-6 months for a production-ready agent

Path 1: Example Architecture

Building a code review agent from scratch:

// Simplified agent loop
async function agentLoop(task) {
  const context = await gatherContext(task);
  let done = false;

  while (!done) {
    // Reason: ask LLM what to do next
    const plan = await llm.chat({
      system: SYSTEM_PROMPT,
      messages: [...context.history, { role: 'user', content: task }],
      tools: AVAILABLE_TOOLS,
    });

    // Act: execute the chosen tool
    if (plan.tool_calls) {
      for (const call of plan.tool_calls) {
        const result = await executeTool(call);
        context.history.push({ role: 'tool', content: result });
      }
    }

    // Observe: check if we're done
    done = plan.stop_reason === 'end_turn' && !plan.tool_calls;
  }

  return context.history;
}

This is the core pattern every agent framework implements. Understanding it helps you evaluate frameworks and debug issues.

Path 2: Agent Builds It

The meta-approach — use an existing AI agent to build your system:

You: "Build me a customer support chatbot that..."
Claude Code:
  → Creates Express server with WebSocket support
  → Implements RAG pipeline with vector database
  → Builds admin UI for managing knowledge base
  → Writes tests for all components
  → Deploys to Docker

When to choose Path 2:

• You have a clear spec but limited AI engineering expertise
• You want rapid prototyping (hours, not months)
• The agent itself is not your product — it's a tool for your business
• You need something working fast and can iterate

The workflow:

1. Write a detailed spec (AGENTS.md style)
2. Use Claude Code or OpenCode to build the system
3. Review and test the generated code
4. Iterate on specific issues
5. Deploy and monitor

Typical timeline: 1-5 days for a working prototype, 2-4 weeks for production

Path 2: What Works and What Doesn't

Works well with agent-built systems:

• CRUD APIs and web applications
• Chatbots with well-defined knowledge domains
• Data processing pipelines
• Monitoring and alerting scripts
• CLI tools and automation

Doesn't work well:

• Novel algorithms (AI can't innovate beyond training data)
• Performance-critical systems (AI doesn't optimize well)
• Security-critical flows (AI may miss edge cases)
• Systems requiring formal verification

The hybrid approach: Let the agent build 80% of the scaffolding, then hand-craft the critical 20% (security, performance, core algorithms).

Path 3: Agent IS the Backend

The most radical approach — the agent doesn't generate code, it IS the application:

Traditional:
  User → [Your App Code] → Database

Path 3:
  User → [AI Agent] → Tools (DB, APIs, files)
  No traditional application code at all.

Example — AI-native customer portal: Instead of building screens for "view order", "request refund", "update address":

User: "Where's my order?"
Agent: *queries order DB* → "Your order #4521 shipped yesterday
        and arrives Thursday. Here's the tracking link."

User: "Actually, I need to change the delivery address"
Agent: *calls shipping API* → "Done! Updated to 456 Oak St.
        Your delivery date is still Thursday."

No screens to build. No forms to design. No routes to code. The agent IS the interface.

Path 3: When It Works

Ideal for Path 3:

• Internal tools where users are flexible (employees, not customers)
• Complex workflows with many branching paths
• Tasks that are hard to design traditional UIs for
• Rapid experimentation and exploration

Not ideal for Path 3:

• High-volume transaction processing (too slow, too expensive)
• Tasks requiring precise, repeatable outcomes (use deterministic code)
• Compliance-heavy operations (need audit trails of code, not AI reasoning)
• Simple CRUD operations (traditional code is simpler)

The cost equation:

• Traditional app: $0 per request (code is free to run)
• Agent-as-backend: $0.01-0.50 per interaction (LLM cost)
• At 10,000 daily interactions: $100-5,000/day

Path 3 is expensive at scale but extremely cheap to develop. Perfect for internal tools with low-to-medium volume.

Choosing Your Path

Factor	Path 1: Build It	Path 2: Agent Builds	Path 3: Agent IS It
Timeline	2-6 months	1-4 weeks	1-3 days
Control	Full	High	Medium
Cost to build	High	Medium	Low
Cost to run	Low	Low	High
Team needed	AI engineers	Developers	Anyone
Scalability	Excellent	Excellent	Limited
Flexibility	Maximum	High	Maximum

Most teams use a combination:

• Path 2 to build the initial version
• Path 1 to optimize critical components
• Path 3 for internal tools and prototypes

Start with Path 2 or 3 to validate your idea quickly. Graduate to Path 1 only for the components that need custom engineering.

---quiz question: What is "Path 2" in agentic system development? options:

• { text: "Building the agent framework from scratch", correct: false }
• { text: "Using an existing AI coding agent to build your system from a detailed spec", correct: true }
• { text: "Using the agent as the application backend directly", correct: false } feedback: Path 2 means using AI coding agents (like Claude Code) to generate the system based on your specifications. It's faster than building from scratch (Path 1) while giving you actual code you can deploy and maintain.

---quiz question: When is "Path 3: Agent IS the Backend" most appropriate? options:

• { text: "For high-volume e-commerce transactions", correct: false }
• { text: "For internal tools with low-to-medium volume where rapid development matters", correct: true }
• { text: "For any application that needs a user interface", correct: false } feedback: Path 3 is ideal for internal tools and low-to-medium volume use cases where the speed of development (days, not months) outweighs the per-request cost of running an LLM for every interaction.

---quiz question: What is the recommended hybrid approach for most teams? options:

• { text: "Only use Path 1 for everything", correct: false }
• { text: "Start with Path 2 or 3 to validate quickly, then use Path 1 to optimize critical components", correct: true }
• { text: "Use Path 3 for everything to save development time", correct: false } feedback: Most successful teams validate their idea quickly with Path 2 or 3, then invest in custom engineering (Path 1) only for the components that genuinely need it — like security, performance, or novel algorithms.