An AI agent is a system that uses an LLM to plan, act, and iterate toward a goal without step-by-step human guidance. Unlike a chatbot that responds once and stops, an agent loops: it observes, decides, calls tools, evaluates results, and repeats until the task is done or it hits a limit. The distinction matters because agents introduce new failure modes — tool misuse, infinite loops, context explosion — that don’t exist in single-turn prompting.
What separates an agent from a prompt chain
A prompt chain is a fixed sequence: prompt A feeds prompt B feeds prompt C. The developer hardcodes the flow. An agent, by contrast, chooses its own next step at runtime. The LLM receives a system prompt describing available tools and a high-level objective, then decides which tool to invoke (or whether to answer directly). After each tool call, the result goes back into context and the model decides again.
# Simplified agent loop
def run_agent(objective: str, tools: dict, max_steps: int = 10):
messages = [{"role": "system", "content": SYSTEM_PROMPT},
{"role": "user", "content": objective}]
for step in range(max_steps):
response = llm_complete(messages, tools=tools)
if response.tool_calls:
for call in response.tool_calls:
result = tools[call.name](**call.arguments)
messages.append({"role": "tool", "tool_call_id": call.id,
"content": result})
else:
return response.content # Agent decided it's done
raise RuntimeError("Max steps exceeded")The loop is the defining characteristic. No loop, no agent — just a workflow.
Core components every agent needs
Tools are typed functions the model can call: search, code execution, API requests, database queries. Each tool needs a JSON schema so the model knows what arguments to pass. Bad schemas cause hallucinated arguments; good schemas include descriptions, required fields, and enums where appropriate.
{
"name": "query_database",
"description": "Run a read-only SQL query against the analytics warehouse",
"parameters": {
"type": "object",
"properties": {
"sql": {"type": "string", "description": "SELECT statement only"}
},
"required": ["sql"]
}
}Memory comes in two flavors. Short-term memory is the conversation history — tool calls, results, and model reasoning — that fits in the context window. Long-term memory requires external storage: vector databases for semantic recall, key-value stores for facts, or structured logs for audit trails. Most production agents need both.
Planning can be implicit (the model reasons step by step in its output) or explicit (a separate planning phase produces a task list before execution). Explicit planning helps with complex multi-step tasks but adds latency and token cost. Implicit planning works for simpler tasks but can drift.
Guardrails prevent runaway behavior: step limits, token budgets, tool allowlists, and human-in-the-loop checkpoints for destructive actions. Without them, an agent with a delete_database tool will eventually find a reason to use it.
Why agents matter for engineering teams
Agents shift the integration surface from “call an LLM” to “give an LLM capabilities and constraints.” This changes three things:
You design tool interfaces, not prompts. The prompt becomes a stable system description. Iteration happens on tool schemas, error handling, and evaluation — not on wording tweaks.
Observability becomes non-optional. You need to see every tool call, its arguments, its result, and the model’s reasoning. Without traces, you cannot debug why the agent chose the wrong tool or hallucinated a parameter.
Evaluation moves from “vibe check” to regression suites. You define task scenarios with expected tool sequences and outcomes. CI runs them on every tool schema change. n4n.ai’s per-token metering and usage logs make this practical by letting you tie cost to specific agent runs.
Concrete example: a code-review agent
Objective: “Review PR #247 for security issues and suggest fixes.”
Tools:
fetch_pr_diff(repo, pr_number)→ unified difffetch_file(repo, path, ref)→ file content at a commitpost_review_comment(pr_number, file, line, body)→ GitHub APIrun_semgrep(rules, code)→ static analysis findings
The agent fetches the diff, identifies changed files, fetches each file at the new commit, runs semgrep with security rules, then posts inline comments for each finding. If semgrep returns nothing, the agent might still reason about patterns the rules miss — hardcoded secrets, unsafe deserialization — and comment on those.
# Agent reasoning trace (abbreviated)
Step 1: fetch_pr_diff("myorg/myrepo", 247)
→ 12 files changed, 340 lines added
Step 2: For each file, fetch_file at HEAD
→ retrieved 12 file contents
Step 3: run_semgrep(security_rules, file_contents)
→ 3 findings: SQL injection in user_service.py:42,
hardcoded API key in config.py:17,
path traversal in upload.py:88
Step 4: post_review_comment for each finding
→ Comments posted with suggested fixes
Step 5: No more tool calls → "Review complete. Found 3 security issues."This agent replaces a 20-minute manual review with a 30-second automated pass. It doesn’t replace human judgment — it surfaces the obvious issues so humans focus on architecture and business logic.
Common misconceptions
“Agents are just prompt engineering.” Prompt engineering is part of it, but the hard problems are tool design, state management, error recovery, and evaluation. A well-designed tool with a mediocre prompt outperforms a perfect prompt with a broken tool.
“Agents need GPT-4-class models.” Smaller models work for narrow, well-scoped agents with good tools. A 7B model driving a SQL agent with a solid schema and few-shot examples often beats a frontier model guessing table names. Match model capacity to task complexity.
“Agents replace engineers.” Agents amplify engineers. They handle the mechanical parts — grep, diff, boilerplate, API pagination — so engineers spend time on decisions. The agent above doesn’t decide whether the SQL injection is exploitable in context; it flags it.
“Autonomy is a slider.” Autonomy is a set of discrete choices: which tools exist, whether the agent can spawn sub-agents, whether it can write code that runs, whether it can spend money. Each choice adds failure surface. Start with the minimum autonomy that solves the problem.
“RAG makes agents unnecessary.” RAG retrieves documents. Agents act on systems. They compose: an agent uses RAG as a tool. The distinction is read vs. write. If your task only needs reading, you don’t need an agent.
Failure modes to plan for
Tool hallucination. The model invents a tool name or passes invalid JSON. Mitigation: strict schema validation, retry with error feedback, fallback to a “clarify” tool that asks the user.
Context overflow. Long-running agents accumulate history until they exceed the window. Mitigation: summarization steps, sliding window with pinned critical facts, or hierarchical agents where a planner delegates to short-lived workers.
Loop traps. The agent oscillates between two states — calling tool A, getting result B, calling tool A again. Mitigation: step limits, deduplication of recent tool calls, explicit “stop and ask” tool.
Silent failures. A tool returns an error but the model treats it as success because the error is in the content, not the HTTP status. Mitigation: tools return structured results with success: boolean, and the system prompt instructs the model to check it.
Cost explosion. An agent with a code-execution tool in a loop can burn thousands of tokens in minutes. Mitigation: token budgets per run, per-step limits, and hard caps enforced by the gateway.
Where to start
Pick one repetitive, well-defined task your team does manually: triaging alerts, generating test stubs, checking dependency updates. Build a single-tool agent first — no planning, no memory, just a loop that calls one tool until done. Instrument it. Evaluate it. Then add a second tool.
The best agent architectures are boring: a clear system prompt, a small set of reliable tools, structured logging, and a step limit. The excitement comes from what they automate, not from the architecture itself.