AI Agents & Agentic Engineering
  • Context Engineering
  • Building AI Agents
  • Agentic Engineering Best Practices
  • Auto-Research and Self-Improving Agents
  • Self-Maintaining Agents
  • Scaling Long-Running Autonomous Coding
  • Data Agents
  • Agent Memory and Harness Ownership
LLM Internals & Training
  • Reinforcement Learning for LLMs
  • Cursor Composer 2
  • Training-Free GRPO
  • Prompt Repetition for Non-Reasoning LLMs
  • LLM Quantization
  • LLM Knowledge Bases
AI Safety & Security
  • Constitutional Classifiers
  • Project Glasswing
Graphics & Low-Level Programming
  • Shaders and GPU Programming
Personal Development & Mindset
  • Deep Focus and Productivity
  • Identity and Life Design
  • Self-Competition and Entrepreneurship

Building AI Agents

Building a fully functioning code-editing agent is simpler than it appears. The core pattern is an LLM, a loop, and tools. Everything else is refinement. This page covers the practical mechanics of agent construction and the key architectural patterns.

The Agent Loop (Amp Code Tutorial)

A tutorial from Amp Code demonstrates building a complete code-editing agent in under 400 lines of Go. The architecture:

  1. Chat loop: Read user input, append to conversation, send to Claude, print response, repeat
  2. Tool definitions: Each tool has a name, description, input schema (JSON schema), and an execution function
  3. Tool execution loop: When Claude's response contains tool_use blocks, execute the tool and send results back as a new user message, then re-invoke Claude

Three tools are sufficient for a code-editing agent:

  • read_file: Returns file contents given a relative path
  • list_files: Lists files and directories (like ls)
  • edit_file: String replacement: finds old_str in a file and replaces it with new_str

Key insight: You don't tell the model when to use tools. Modern LLMs are trained and fine-tuned for tool use. They infer when a tool call would help. Ask "what's in main.go?" and Claude will call read_file without being instructed to. Ask "what Go version are we using?" and it chains list_files then read_file("go.mod") on its own.

The tool-use protocol is just structured winking:

  1. You tell the model what tools are available (via API tool definitions or just in the system prompt)
  2. When the model wants to use a tool, it responds with a specially formatted message
  3. You execute the tool and return the result
  4. The model continues with that new information

The Anthropic SDK wraps this in type-safe APIs, but under the hood it all becomes strings in a system prompt.

On edit_file via string replacement: Claude 3.7 (and later models) handle string replacement well. The implementation: read the file, replace old_str with new_str, write it back. If the file doesn't exist and old_str is empty, create a new file. This is enough to build, debug, and iterate on real code.

Source: How to Build an Agent (Amp Code)

Agent Architecture Patterns

Several sources describe the patterns that make agents effective in practice:

Separating Research from Implementation

agentic-engineering-best-practices emphasizes that research and implementation should be separate agent tasks. Asking an agent to "build an auth system" forces it to research options, filling context with irrelevant alternatives. Instead: research first (in one session), decide on implementation details, then implement in a fresh session with only the relevant context.

Adversarial Multi-Agent Patterns

The "bug-finder / adversarial / referee" pattern exploits LLM sycophancy constructively:

  1. Bug-finder agent: Biased to find bugs (scored per bug severity). Over-reports.
  2. Adversarial agent: Biased to disprove bugs (penalized for false disprovals). Under-reports.
  3. Referee agent: Scores both agents' claims to find ground truth.

Contracts and Stop Conditions

Agents know how to start tasks but not how to end them. Effective patterns:

  • Tests as milestones: "Unless these X tests pass, your task is NOT complete; you are NOT allowed to edit the tests"
  • Task contracts: A {TASK}_CONTRACT.md specifying tests, screenshots, and verification required before session termination
  • Stop hooks: Prevent agent termination until all contract conditions are met

Planners and Workers

For multi-agent systems, scaling-autonomous-coding found that a hierarchy works better than flat coordination:

  • Planners explore the codebase and create tasks (can spawn sub-planners)
  • Workers focus on completing assigned tasks without coordinating with each other

Related Topics

  • agentic-engineering-best-practices - Principles for maximizing agent output
  • scaling-autonomous-coding - Multi-agent coordination at scale
  • auto-research - Agents that improve through self-experimentation
  • context-engineering - Why context management is the core skill
  • agent-memory-and-harnesses - Why harnesses are permanent and memory creates lock-in