Three Paths to Agentic Systems
There are three fundamentally different ways to build agentic systems. Choosing the right path depends on your team, timeline, and ambition.
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:
- Write a detailed spec (AGENTS.md style)
- Use Claude Code or OpenCode to build the system
- Review and test the generated code
- Iterate on specific issues
- 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.