Agent Anatomy
Every autonomous agent — from a simple inbox monitor to a fleet managing your entire business — is built from six core components. This lesson dissects each one, shows you how they map to real code, and lets you build your own agent config from scratch.
The Six Components
Strip away the framework-specific jargon and every agent has the same anatomy. Whether you are using Claude Agent SDK, LangGraph, CrewAI, or building from scratch — these six pieces are always present, even if they go by different names.
Here is each component explained:
Who the agent is. Its name, role, personality, and voice. Identity is not decoration — it shapes every decision the agent makes. An agent with the identity "cautious security auditor" will behave very differently from one with the identity "creative marketing writer," even given the same tools and inputs.
In practice, identity is encoded in the system prompt. Claude Agent SDK calls this the instructions field. LangChain calls it system_message.
What the agent knows and remembers. Three types: short-term (the current conversation window — fast but ephemeral), long-term (stored in a database — survives across sessions), and shared (accessible to other agents — the communication bus). Memory is what makes an agent smarter over time.
What the agent can do. API calls, database queries, file operations, sending messages, running shell commands. Tools are the agent's hands — without them, it can only think. In Claude's API, tools are defined as JSON schemas. MCP standardizes this across all clients.
What the agent is trying to achieve. Goals drive the decide phase of the agent loop. They can be persistent (always active, like "keep the server healthy") or triggered (activated by events, like "respond to this support ticket"). A common mistake is vague goals like "be helpful." Effective goals are specific: "Respond to all support tickets within 5 minutes."
What the agent must NOT do. Boundaries, safety rules, ethical constraints, and hard limits. Guardrails operate at a higher priority than goals. A goal says "send marketing emails." A guardrail says "never send more than 100 emails per hour." When they conflict, the guardrail wins.
When and how the agent runs. Three modes: event-driven (reacts to triggers like webhooks), cron-based (runs on a fixed schedule), or always-on (continuously monitoring). Always-on agents respond instantly but consume the most resources. Event-driven agents balance responsiveness and efficiency.
How This Maps to Real Code
Here is what a complete agent configuration looks like as a Python dataclass. This is a pattern you will see in nearly every agent framework:
from dataclasses import dataclass, field
from typing import List, Optional
@dataclass
class AgentConfig:
# Identity
name: str
role: str
voice: str = "neutral"
# Goals
goals: List[str] = field(default_factory=list)
# Tools — list of callable functions
tools: List[str] = field(default_factory=list)
# Guardrails — hard limits that override goals
guardrails: List[str] = field(default_factory=list)
# Memory config
memory_type: str = "short_term" # or "long_term", "shared"
# Schedule
schedule: Optional[str] = None # cron expression
trigger: Optional[str] = None # event name
# Example: a support agent
support_agent = AgentConfig(
name="Atlas",
role="Tier 1 Support",
voice="friendly, concise",
goals=["Resolve tickets within 5 min", "Escalate P0s immediately"],
tools=["search_kb", "send_reply", "escalate_ticket", "log_resolution"],
guardrails=["Never share internal docs", "Never close without resolution"],
memory_type="long_term",
trigger="on_new_ticket"
)Every field maps directly to one of the six components. When you use a framework like Claude Agent SDK, you are filling in these same fields — just through a different interface.
Common Design Mistakes
Most agent failures trace back to a misconfigured component. Watch for these:
An agent with 50 tools gets confused about which one to use. LLMs perform better with 5-15 focused tools. If you need more, split into multiple specialized agents.
"You are a helpful assistant" produces generic behavior. "You are a senior DevOps engineer who prioritizes stability over speed and always explains trade-offs" produces targeted, useful behavior.
An agent without guardrails will optimize its goals at any cost. A sales agent told to "maximize conversions" with no guardrails might start making false promises. Always define what the agent must NOT do.
Component Interactions
The six components do not operate in isolation — they form a connected system. Understanding how they interact prevents common design failures:
An agent's identity (system prompt) directly affects which tools it chooses and how it interprets goals. A "cautious security auditor" will refuse risky actions that a "move-fast developer" would execute immediately. The same tools and goals produce different behavior with different identities.
Long-term memory stores past outcomes. If the agent remembers that a particular approach failed last time, it adjusts its goal-pursuit strategy. Without memory, the agent repeats mistakes indefinitely. Memory is the mechanism by which agents learn.
Guardrails sit above goals, tools, and identity in the priority hierarchy. A guardrail that says "never delete production data" cannot be overridden by a goal that says "clean up old records." This precedence is critical — without it, goal-oriented agents will optimize past safety boundaries.
An always-on agent consumes compute 24/7. An event-driven agent consumes nothing until triggered. Choosing the wrong schedule wastes money (always-on for a weekly report) or misses events (cron for real-time alerts). Match the schedule to the use case.
The Agent Config Pattern in Frameworks
Every major framework maps to these six components. Here is how the terminology translates:
| Component | Claude SDK | LangGraph | CrewAI |
| Identity | instructions | system_message | role + backstory |
| Memory | conversation + tools | state / checkpointer | memory flag |
| Tools | tools (JSON schema) | tools (bound) | tools list |
| Goals | in instructions | in system_message | goal field |
| Guardrails | guardrails config | conditional edges | in backstory |
| Schedule | external (cron/trigger) | external (cron/trigger) | process type |
Different names, same anatomy. Learn the six components once and you understand every framework.
Building Your First Agent Config
Start with these questions for each component. Answer them before writing any code:
Memory: Does it need to remember across sessions? Does it share state with other agents?
Tools: What 5-10 actions does this agent need? (Start narrow — you can always add more.)
Goals: What specific, measurable outcomes is this agent pursuing?
Guardrails: What must this agent NEVER do? What are the hard limits?
Schedule: Should it run on a timer, respond to events, or loop continuously?