The Agent Control Loop: Architecture & State

An agent is fundamentally a stateful control loop wrapped around a Large Language Model (LLM) equipped with external capabilities (tools) and transient or persistent storage (memory).

   ┌────────────────────────────────────────────────────────┐
   │                     Agent Control Loop                 │
   │                                                        │
   │   User Input ───► [ Thought / Plan ]                   │
   │                          │                             │
   │                          ▼                             │
   │                  [ Action / Tool Call ] ──► Tool API   │
   │                          │                      │      │
   │                          ▼                      │      │
   │                  [ Observation ] ◄──────────────┘      │
   │                          │                             │
   │                          ▼                             │
   │                  [ Final Answer ] ───► Deliver Output  │
   └────────────────────────────────────────────────────────┘

💡

Key Rule: Keep tool definitions minimal and atomic. Overloading an agent with 30 tools degrades prompt adherence and spikes token costs exponentially.

The Three Core Pillars of Agent Architecture

1. Planning & Reasoning Strategies

ReAct (Reason + Act): Interleaves thinking tokens with tool executions. Enables step-by-step corrections.
Plan-and-Solve: Generates an explicit DAG (directed acyclic graph) of tasks first, then executes tasks deterministically.
Reflection / Self-Correction: A secondary pass where a critique prompt checks the output against constraints before returning to the caller.

2. Tool Calling & Interface Boundaries

When an agent calls a tool, enforce strict JSON schemas. Never allow free-form string outputs from external tools without validation.

{
  "name": "query_database",
  "description": "Execute read-only SQL queries against user workspace data.",
  "parameters": {
    "type": "object",
    "properties": {
      "sql": { "type": "string", "description": "Parametrized SQL statement" },
      "limit": { "type": "integer", "default": 20 }
    },
    "required": ["sql"]
  }
}

3. Memory & Context Window Management

Context windows are finite and expensive. Modern production agents split memory into:

Working Memory: In-flight message history trimmed to the current subtask.
Episodic Memory: Vector search over past conversation summaries.
Semantic State: Structured key-value storage (e.g. Postgres or Redis) holding verified facts.

⚠️

Failure Mode: Never dump raw tool execution payloads (like massive 100KB HTML pages) into the agent's context. Always parse and summarize in code before passing back to the LLM.

Architecture Checklist

Are all tool calls idempotent or explicitly guarded with human-in-the-loop confirmation?
Is there a hard ceiling on maximum loop iterations (e.g. max 10 iterations)?
Are error traces intercepted and simplified before being passed back into the prompt?