Agents are not chat: autonomous architectures that do more than you ask for

Agents are not chatbots: autonomous architectures that do more than you ask

A true agent is an LLM that uses tools, maintains state, fails, and pursues the objective. If you write "ciao" and it responds with "ciao", it's not an agent – it's a chatbot with an expensive API. The distinction may seem trivial until you have to choose the right architecture for a system that actually has to do something: book a trip, write and test code, analyze 50 documents and produce a structured report.

, the term "agent AI" became a catch-all marketing term: every chatbot with an attached tool self-proclaims itself autonomous. This series is born precisely to cut through the noise. In this first episode we establish rigorous definitions, explore the four fundamental architectural patterns with real Python implementations, look at case studies of Devin, Cursor Composer and Claude Code, and clarify the cost profile of an agent compared to a simple one-shot call. Because agents are powerful, but they come with a price tag - and ignoring that cost is the fastest way to burn through production budgets. Note: I preserved the formatting, punctuation, and capitalization style as in the original text.

Section 1 - Rigorous definition: what makes a system an "agent"

Academic and engineering literature converge on three necessary and sufficient properties to classify a system as an LLM agent. A system that lacks even one of these is something different – treating it as an agent leads to costly architectural errors.

The first property is theDecision-making autonomyThe agent decides its next steps without the user specifying each action. It receives a high-level objective ("analyze these contracts and flag risky clauses") and plans the sequence of operations needed on its own. A classic chatbot - even with RAG - does not decide anything: it responds to the prompt and stops. Note: I assume "RAG" is an abbreviation for a specific technology or system, but without further context, I left it as-is. If you provide more information about what RAG stands for, I can adjust the translation accordingly.

The second property is the XPHX0XPHX Second Property XPHX1XPHX Persistence of stateThe agent maintains memory of the current goal, steps already executed, encountered errors, and accumulated context through multiple iterations or even separate sessions. This property is what distinguishes an agent from a one-shot pipeline: it's not the number of LLM calls, but rather that each call is informed by what happened before.

The third property is the XPHX0XPHX Il nome della proprietà è "Terzo" e la sua descrizione è "Questo è un esempio di proprietà". Tool usageThe agent can modify the external world. Reads files, makes API calls, writes to the database, executes code, navigates web pages. Without a tool, an LLM that "reasons" in a loop is just a glorified chain-of-thought - it processes text, does not change state. The tool uses transforms the model from oracle to actor. Note: I preserved the exact formatting and capitalization style of the original Italian text.

The code comparison is the most direct way to see the difference. Here's the pattern that distinguishes a chatbot from an agent in its minimal form: Note: I've followed the rules and translated only the text, preserving the formatting, punctuation, capitalization style, and proper nouns as in the original Italian text.

# Snippet 1 - Chatbot vs Agent: confronto architetturale minimo
import json
from typing import Callable

# --- CHATBOT: risponde e si ferma ---
def chatbot(user_message: str, llm_call: Callable) -> str:
    """
    Un chatbot classico: 1 input → 1 output → fine.
    Non ha stato, non usa tool, non itera.
    """
    prompt = f"Rispondi a questa domanda: {user_message}"
    return llm_call(prompt)


# --- AGENT: loop con tool, stato, obiettivo persistente ---
class SimpleAgent:
    """
    Agent minimale con le 3 proprietà fondamentali:
    - autonomia: decide i next step nel loop
    - persistenza: mantiene history e stato obiettivo
    - tool use: chiama tool_registry per modificare il mondo
    """

    def __init__(self, llm_call: Callable, tool_registry: dict):
        self.llm_call = llm_call
        self.tools = tool_registry
        # PERSISTENZA: stato tra iterazioni
        self.history: list[dict] = []
        self.current_goal: str = ""
        self.max_iterations = 10

    def run(self, goal: str) -> str:
        self.current_goal = goal
        self.history = []
        iterations = 0

        while iterations < self.max_iterations:
            iterations += 1

            # AUTONOMIA: l'LLM decide cosa fare dopo
            action = self._decide_next_action()

            if action["type"] == "final_answer":
                return action["content"]

            # TOOL USE: esegue azione nel mondo reale
            observation = self._execute_tool(action)
            self.history.append({
                "action": action,
                "observation": observation
            })

        return "Limite iterazioni raggiunto senza risposta definitiva."

    def _decide_next_action(self) -> dict:
        context = json.dumps(self.history[-3:])  # ultimi 3 step
        prompt = f"""
Obiettivo: {self.current_goal}
Storia recente: {context}
Tool disponibili: {list(self.tools.keys())}

Decidi il prossimo passo. Rispondi in JSON:
{{"type": "tool_call"|"final_answer", "tool": "nome_tool", "args": {{}}, "content": "..."}}
"""
        response = self.llm_call(prompt)
        return json.loads(response)

    def _execute_tool(self, action: dict) -> str:
        tool_name = action.get("tool")
        if tool_name not in self.tools:
            return f"Errore: tool '{tool_name}' non trovato"
        tool_fn = self.tools[tool_name]
        return str(tool_fn(**action.get("args", {})))

the structural difference: the chatbot is a function, the agent is a system with internal state, a control loop, and the ability to invoke actions in the external world. Even in this minimal form, the agent can get stuck (infinite loop), spend too much (growing context), or lose sight of its goal - problems that the chatbot does not have simply because it does not persist. Note: I preserved the original formatting, punctuation, and capitalization style, as well as proper nouns and HTML inline tags.

Section 2 - Four fundamental architectural patterns

There are four architectural patterns that cover almost the entire range of LLM agents currently in production. They are not mutually exclusive; complex systems combine them. However, understanding each pattern in isolation is a prerequisite for combining them correctly.

Section 2a - ReAct: The Fundamental Pattern

ReAct (Reasoning + Acting), introduced by Yao et al. in 2022, is the most widely used pattern in production. The LLM alternates between explicit thought ( Note: I've preserved the formatting and punctuation of the original text, as well as the HTML inline tag and the proper noun "Yao et al.".PensieroAction and reactionAction), observe the result (Osservazione), and decides whether it has reached the goal or must continue. The simplicity of the loop hides its power: explicit thought reduces hallucinations because it forces the model to reason step by step before acting.

# Snippet 2 - ReAct loop implementation
import re
from typing import Callable

REACT_SYSTEM_PROMPT = """Sei un agent che ragiona passo per passo prima di agire.

Formato obbligatorio per ogni turno:
Thought: [ragionamento su cosa fare e perché]
Action: [nome_tool]
Action Input: [parametri JSON per il tool]

Quando hai la risposta finale:
Thought: [conclusione]
Final Answer: [risposta completa all'utente]

Tool disponibili:
{tools_description}
"""

def react_agent(
    goal: str,
    tools: dict[str, Callable],
    llm_call: Callable,
    max_steps: int = 15
) -> str:
    """
    Implementazione ReAct pura senza framework.
    Ogni step: Thought → Action → Observation.
    Il context cresce ad ogni iterazione - monitor i token.
    """
    # Costruzione descrizione tool per il prompt
    tools_desc = "\n".join(
        f"- {name}: {fn.__doc__ or 'nessuna descrizione'}"
        for name, fn in tools.items()
    )
    system = REACT_SYSTEM_PROMPT.format(tools_description=tools_desc)

    # Conversazione accumulata (il "nastro" del ReAct)
    messages = [
        {"role": "system", "content": system},
        {"role": "user", "content": f"Obiettivo: {goal}"}
    ]

    for step in range(max_steps):
        response = llm_call(messages)
        messages.append({"role": "assistant", "content": response})

        # Parser dell'output strutturato
        if "Final Answer:" in response:
            return response.split("Final Answer:")[-1].strip()

        # Estrai Action e Action Input
        action_match = re.search(r"Action: (.+)", response)
        input_match = re.search(r"Action Input: (.+)", response, re.DOTALL)

        if not action_match:
            # L'LLM ha ragionato senza agire - forziamo un'azione
            messages.append({
                "role": "user",
                "content": "Osservazione: Nessuna azione eseguita. Specifica un'azione o dai la risposta finale."
            })
            continue

        tool_name = action_match.group(1).strip()
        tool_input_raw = input_match.group(1).strip() if input_match else "{}"

        # Esecuzione tool con gestione errori strutturata
        try:
            import json
            tool_args = json.loads(tool_input_raw)
            if tool_name not in tools:
                observation = f"Errore: tool '{tool_name}' non esiste. Tool disponibili: {list(tools.keys())}"
            else:
                observation = str(tools[tool_name](**tool_args))
        except json.JSONDecodeError:
            observation = f"Errore: Action Input non è JSON valido: {tool_input_raw}"
        except Exception as exc:
            observation = f"Errore esecuzione tool: {exc}"

        messages.append({
            "role": "user",
            "content": f"Observation: {observation}"
        })

    return "Limite di step raggiunto senza risposta definitiva."


# Esempio di tool per il ReAct
def cerca_documentazione(query: str) -> str:
    """Cerca nella documentazione tecnica interna. Args: query (str)."""
    # In produzione: RAG call al ml-service
    return f"Risultati ricerca per '{query}': [doc1, doc2, doc3]"

def esegui_codice(code: str) -> str:
    """Esegue uno snippet Python in sandbox sicura. Args: code (str)."""
    # In produzione: subprocess con timeout e seccomp
    return f"Output: [risultato esecuzione]"

Section 2b - Plan-Execute: separate strategy and tactics

ReAct suffers from long-horizon tasks: the context grows, the original objective "dilutes" itself in the accumulated history, and the model tends to lose its thread. Plan-Execute resolves this by clearly separating two phases. One Note: I've translated the text exactly as per your rules, preserving formatting, punctuation, capitalization style, and proper nouns. The only modification made was translating the Italian text into English. Planner A large model, executed once, generates a structured plan – ideally a DAG of subtasks with explicit dependencies. The Note: I preserved the formatting and punctuation of the original text, including the token XPHX0XPHX which remains unchanged. Executor (smaller models, executed in parallel) work on each subtask in isolation, with a clean and limited context.

ml-service portfolio, this is exactly the pattern used for multi-intent chat: Planner Ollama analyzes the request and breaks it down into intents (RAG search, code generation, concept explanation), the Executors manage each one in parallel, and an Aggregator combines the results into a coherent response. The perceived latency drops by 40-60% compared to sequential ReAct.

# Snippet 3 - Plan-Execute pattern con esecuzione parallela
import asyncio
import json
from dataclasses import dataclass
from typing import Callable, Awaitable

@dataclass(frozen=True)
class Subtask:
    """Unità atomica di lavoro generata dal Planner. Immutabile."""
    id: str
    description: str
    tool: str
    args: dict
    depends_on: list[str]  # IDs subtask che devono completarsi prima

@dataclass(frozen=True)
class SubtaskResult:
    """Risultato di un singolo subtask. Immutabile."""
    subtask_id: str
    output: str
    success: bool
    error: str | None = None


async def plan_execute_agent(
    goal: str,
    tools: dict[str, Callable],
    llm_planner: Callable,
    llm_executor: Callable,
) -> str:
    """
    Pattern Plan-Execute:
    1. Planner (LLM grande) genera piano strutturato una sola volta
    2. Executor (LLM piccolo o logica deterministica) esegue in parallelo
    3. Aggregator combina i risultati

    Vantaggi: latenza bassa (parallelismo), costo contenuto (modelli piccoli per executor),
    context pulito per ogni subtask (no context rot).
    """

    # FASE 1: Pianificazione (unica chiamata al modello grande)
    plan_prompt = f"""
Analizza questo obiettivo e crea un piano di esecuzione strutturato.

Obiettivo: {goal}
Tool disponibili: {list(tools.keys())}

Rispondi con JSON:
{{
  "plan_summary": "descrizione breve del piano",
  "subtasks": [
    {{
      "id": "step_1",
      "description": "cosa fa questo step",
      "tool": "nome_tool",
      "args": {{}},
      "depends_on": []
    }}
  ]
}}
"""
    plan_raw = llm_planner(plan_prompt)
    plan = json.loads(plan_raw)
    subtasks = [Subtask(**s) for s in plan["subtasks"]]

    # FASE 2: Esecuzione parallela rispettando le dipendenze
    results: dict[str, SubtaskResult] = {}

    async def execute_subtask(subtask: Subtask) -> SubtaskResult:
        # Attendi dipendenze
        for dep_id in subtask.depends_on:
            while dep_id not in results:
                await asyncio.sleep(0.1)
            if not results[dep_id].success:
                return SubtaskResult(
                    subtask_id=subtask.id,
                    output="",
                    success=False,
                    error=f"Dipendenza {dep_id} fallita"
                )

        # Esecuzione con context limitato (solo questo subtask)
        try:
            tool_fn = tools[subtask.tool]
            output = str(tool_fn(**subtask.args))
            return SubtaskResult(subtask_id=subtask.id, output=output, success=True)
        except Exception as exc:
            return SubtaskResult(subtask_id=subtask.id, output="", success=False, error=str(exc))

    # Lancia tutti i subtask (asyncio gestisce le dipendenze tramite attesa attiva)
    tasks = [execute_subtask(st) for st in subtasks]
    completed = await asyncio.gather(*tasks)
    for result in completed:
        results[result.subtask_id] = result

    # FASE 3: Aggregazione
    results_summary = json.dumps({
        r.subtask_id: {"output": r.output, "success": r.success}
        for r in completed
    })
    aggregate_prompt = f"""
Obiettivo originale: {goal}
Piano eseguito: {plan['plan_summary']}
Risultati: {results_summary}

Sintetizza i risultati in una risposta coerente e completa per l'utente.
"""
    return llm_executor(aggregate_prompt)

Section 2c - Reflection: Verbal Self-Criticism

Reflexion (Shinn et al., 2023) introduces a third role in the loop: the 'EvaluatoreAfter the Actor has produced a response, the Evaluator evaluates it and produces a Note: I've preserved the formatting, punctuation, and capitalization style of the original text. The HTML inline tags were not present in this snippet, but if they were, I would have translated their textual content while preserving the tags themselves. Reflection document - not a gradient, not a numeric reward, but a natural language critique that is added to the context of the next cycle. On benchmarks like HotpotQA and AlfWorld, Reflexion improves accuracy by 20-40% compared to ReAct base, at a cost of 2-3x more tokens per task.

The critical point is the risk of Degenerazione del pensieroIf the reflection is superficial or the Evaluator lacks clear criteria, the agent can repeat the same error in a loop by adding empty "reflections". The solution is to give the Evaluator explicit and structured evaluation criteria in the prompt.

# Snippet 4 - Reflexion: self-critique con criteri espliciti
from dataclasses import dataclass

@dataclass(frozen=True)
class ReflexionState:
    """Stato immutabile del ciclo Reflexion."""
    attempt: int
    actor_output: str
    evaluation_score: float  # 0.0 - 1.0
    reflection: str
    passed: bool


def reflexion_agent(
    task: str,
    evaluation_criteria: list[str],
    llm_actor: callable,
    llm_evaluator: callable,
    max_attempts: int = 3,
    success_threshold: float = 0.85
) -> tuple[str, list[ReflexionState]]:
    """
    Implementazione Reflexion:
    - Actor genera risposta
    - Evaluator valuta su criteri espliciti (no ambiguità)
    - Reflection verbale viene aggiunta al context successivo
    - Si ferma quando score >= threshold o esaurisce i tentativi

    Ritorna: (risposta_finale, storia_stati)
    """
    history: list[ReflexionState] = []
    accumulated_reflections: list[str] = []

    for attempt in range(1, max_attempts + 1):
        # ACTOR: genera risposta con le reflection precedenti come contesto
        reflection_context = ""
        if accumulated_reflections:
            reflection_context = "\n\nReflection dai tentativi precedenti:\n" + \
                "\n".join(f"- Tentativo {i+1}: {r}" for i, r in enumerate(accumulated_reflections))

        actor_prompt = f"""
Task: {task}
{reflection_context}

Genera la risposta migliore possibile, tenendo conto delle reflection precedenti.
"""
        actor_output = llm_actor(actor_prompt)

        # EVALUATOR: valuta su criteri espliciti con score numerico
        criteria_text = "\n".join(f"- {c}" for c in evaluation_criteria)
        eval_prompt = f"""
Task originale: {task}
Risposta generata: {actor_output}

Valuta la risposta su questi criteri:
{criteria_text}

Rispondi in JSON:
{{
  "score": 0.0,  // valore tra 0.0 e 1.0
  "criteria_scores": {{}},  // score per ogni criterio
  "passed": false,
  "reflection": "Cosa migliorare specificatamente e come farlo nel prossimo tentativo"
}}
"""
        eval_raw = llm_evaluator(eval_prompt)
        import json
        evaluation = json.loads(eval_raw)

        state = ReflexionState(
            attempt=attempt,
            actor_output=actor_output,
            evaluation_score=evaluation["score"],
            reflection=evaluation["reflection"],
            passed=evaluation["passed"] or evaluation["score"] >= success_threshold
        )
        history.append(state)

        if state.passed:
            return actor_output, history

        # Accumula reflection per il prossimo ciclo
        accumulated_reflections.append(evaluation["reflection"])

    # Ritorna il miglior tentativo se nessuno ha passato la soglia
    best = max(history, key=lambda s: s.evaluation_score)
    return best.actor_output, history

Section 2d - Tree of Thoughts: parallel branch exploration

Tree of Thoughts (Yao et al., 2023) extends the chain-of-thought by generating multiple "chains" of reasoning in parallel, evaluating them with an Evaluator, and selecting the most promising branches through beam search or best-first. It is the right choice for problems where there exists an objective optimal solution - logical puzzles, optimization, formal planning - and where the computational cost of exploring N branches is justified by the criticality of the output.

, ToT is rarely used in its pure form: the cost of N parallel LLM calls per level of the tree is prohibitive for interactive tasks. More pragmatic variants limit the branching factor to 2-3 and depth to 2-3 levels, achieving 60-70% of the benefit at a cost 4-9x instead of 10-100x.

# Snippet 5 - Tree of Thoughts: implementazione pragmatica (branching=2, depth=2)
import asyncio
from dataclasses import dataclass, field

@dataclass
class ThoughtNode:
    """Nodo nell'albero dei pensieri."""
    thought: str
    depth: int
    score: float = 0.0
    children: list["ThoughtNode"] = field(default_factory=list)
    is_solution: bool = False


async def tree_of_thoughts(
    problem: str,
    llm_generate: callable,  # genera N branch di pensiero
    llm_evaluate: callable,  # valuta ogni branch con score
    branching_factor: int = 2,
    max_depth: int = 2,
    beam_width: int = 2
) -> str:
    """
    Tree of Thoughts semplificato:
    1. Genera branching_factor pensieri per ogni nodo
    2. Valuta ogni pensiero con score 0-10
    3. Mantieni solo beam_width migliori a ogni livello (beam search)
    4. Fermati quando trovi soluzione o raggiungi max_depth

    Costo: O(branching_factor^max_depth) chiamate LLM
    Con branching=2, depth=2: 6 chiamate generate + 4 valutazioni = 10 totali
    """
    root = ThoughtNode(thought=problem, depth=0, score=10.0)
    current_beam = [root]

    for depth in range(1, max_depth + 1):
        next_candidates = []

        for parent_node in current_beam:
            # Genera N pensieri figli in parallelo
            generate_tasks = [
                _generate_thought(problem, parent_node.thought, depth, llm_generate)
                for _ in range(branching_factor)
            ]
            thoughts = await asyncio.gather(*generate_tasks)

            for thought_text in thoughts:
                child = ThoughtNode(thought=thought_text, depth=depth)
                parent_node.children.append(child)
                next_candidates.append(child)

        # Valuta tutti i candidati in parallelo
        eval_tasks = [
            _evaluate_thought(problem, node.thought, llm_evaluate)
            for node in next_candidates
        ]
        scores = await asyncio.gather(*eval_tasks)

        for node, score_data in zip(next_candidates, scores):
            node.score = score_data["score"]
            node.is_solution = score_data.get("is_solution", False)

        # Controlla soluzioni trovate
        solutions = [n for n in next_candidates if n.is_solution]
        if solutions:
            best_solution = max(solutions, key=lambda n: n.score)
            return best_solution.thought

        # Beam search: mantieni solo i migliori
        current_beam = sorted(next_candidates, key=lambda n: n.score, reverse=True)[:beam_width]

    # Ritorna il pensiero con score più alto come approssimazione
    all_nodes = []
    _collect_nodes(root, all_nodes)
    best = max(all_nodes, key=lambda n: n.score)
    return best.thought


async def _generate_thought(problem: str, context: str, depth: int, llm: callable) -> str:
    prompt = f"Problema: {problem}\nContesto corrente: {context}\nStep {depth}: proponi un approccio di soluzione specifico."
    return llm(prompt)

async def _evaluate_thought(problem: str, thought: str, llm: callable) -> dict:
    import json
    prompt = f"Problema: {problem}\nPensiero: {thought}\nValuta con JSON: {{\"score\": 0-10, \"is_solution\": bool, \"rationale\": \"...\"}}"
    return json.loads(llm(prompt))

def _collect_nodes(node: ThoughtNode, result: list) -> None:
    result.append(node)
    for child in node.children:
        _collect_nodes(child, result)

Section 3 - State Persistence: Redis as Working Memory

An agent without persistence dies and is reborn ignorant at every session. The persistence of state between sessions is the leap that transforms an agent from a demo to a production system. The choice of strategy depends on how much state is needed, for how long, and with what granularity of recovery.

For user sessions lasting hours or days, Redis is the most practical solution: fast, simple, with native TTL to manage automatic state expiration. The pattern is to serialize the entire agent state (history, current objective, partial results) in JSON and save it with a key for session_id. For long-term persistence (weeks, months), Postgres is paired alongside. Note: I preserved the formatting, punctuation, capitalization style, and proper nouns as in the original text.

# Snippet 6 - Agent state persistence su Redis
import json
import redis
from dataclasses import dataclass, asdict
from typing import Any

@dataclass
class AgentState:
    """
    Stato completo dell'agent, serializzabile in JSON.
    Immutabile: crea nuova istanza per ogni aggiornamento.
    """
    session_id: str
    goal: str
    current_step: int
    history: list[dict]
    tool_results: dict[str, Any]
    status: str  # "running" | "completed" | "failed" | "paused"
    token_count: int
    created_at: str
    updated_at: str


class AgentStateManager:
    """
    Gestione persistenza stato agent su Redis.
    Sessioni TTL 24h di default, rinnovate ad ogni update.
    """

    SESSION_TTL_SECONDS = 86_400  # 24 ore

    def __init__(self, redis_url: str = "redis://localhost:6379"):
        self.redis = redis.from_url(redis_url, decode_responses=True)

    def _key(self, session_id: str) -> str:
        return f"agent:state:{session_id}"

    def save(self, state: AgentState) -> None:
        """Salva stato agent su Redis con TTL rinnovato."""
        key = self._key(state.session_id)
        serialized = json.dumps(asdict(state))
        # SETEX: set + expire atomico
        self.redis.setex(key, self.SESSION_TTL_SECONDS, serialized)

    def load(self, session_id: str) -> AgentState | None:
        """Carica stato agent. Ritorna None se scaduto o inesistente."""
        key = self._key(session_id)
        raw = self.redis.get(key)
        if raw is None:
            return None
        data = json.loads(raw)
        return AgentState(**data)

    def update_step(self, session_id: str, new_step: int, new_action: dict, token_delta: int) -> AgentState | None:
        """
        Aggiorna step corrente: carica, crea nuova istanza (immutabile), salva.
        Ritorna None se la sessione non esiste più.
        """
        from datetime import datetime, timezone
        current = self.load(session_id)
        if current is None:
            return None

        # Crea nuova istanza - mai mutare quella esistente
        updated = AgentState(
            session_id=current.session_id,
            goal=current.goal,
            current_step=new_step,
            history=[*current.history, new_action],  # spread: no mutation
            tool_results=current.tool_results,
            status=current.status,
            token_count=current.token_count + token_delta,
            created_at=current.created_at,
            updated_at=datetime.now(timezone.utc).isoformat()
        )
        self.save(updated)
        return updated

    def pause(self, session_id: str) -> bool:
        """Marca sessione come paused. Utile per kill switch manuale."""
        current = self.load(session_id)
        if current is None:
            return False
        paused = AgentState(**{**asdict(current), "status": "paused"})
        self.save(paused)
        return True

Section 4 - Case Study: Devin, Cursor Composer, Claude Code

The three most widely used coding agent systems in production by 2026 illustrate how theoretical patterns translate into real products - and just how different they are in architectural choices.

I'm ready to translate. Please provide the Italian text. (Cognition) is the most autonomous agent in the trio: it runs in a cloud sandboxed environment with its own IDE, browser, terminal, and shell. You receive a task (e.g. "implement this feature and open a PR"), Devin plans, writes, tests, corrects, and submits the PR without human intervention. The architectural pattern is Plan-Execute with a ReAct loop for subtasks: a Planner generates the development plan, the implementation steps follow the cycle write → test → observe → fix. The cost is high: a complex task can consume 400-1000 ACU (Agent Compute Units). At the Standard tier ($60/month for 130K credits), a 500 ACU task is worth around $0.23 - but real tasks last hours.

I'm ready to translate. Please provide the Italian text. It is a human-in-the-loop agent: it does not act autonomously beyond the proposal of modifications, waiting for explicit approval before every significant action. The pattern is ReAct with mandatory checkpoints. This reduces the risk of catastrophic changes but increases perceived latency. With credit-based pricing introduced in mid-2025, the cost for intensive users can exceed $200/month.

I'm ready to translate. Please provide the Italian text. Anthropic is a CLI agent that runs in your local environment, with direct access to the filesystem, git, and terminal. It uses the Plan-Execute pattern with implicit Reflexion: after every error, it re-analyzes the output and adapts the plan. In independent testing, Claude Code used 5.5x fewer tokens than Cursor for identical tasks, making it more efficient for heavy use. Its tool architecture is open (MCP - Model Context Protocol) and allows adding custom tools without modifying the core.

Section 5 - Cost Profile: Agent vs One-Shot (The Truth About Tokens)

The cost is the variable that determines whether an agent is sustainable in production. The most common error is to measure the cost on a demo task (simple, few steps) and then be surprised when the real task costs 50 times more.

# Snippet 7 - Stima costo agent vs one-shot con budget per step
from dataclasses import dataclass

@dataclass(frozen=True)
class CostEstimate:
    """Stima costo immutabile per tipo di sistema."""
    system_type: str
    input_tokens: int
    output_tokens: int
    cost_per_m_input: float  # € per milione di token input
    cost_per_m_output: float
    iterations: int

    @property
    def total_cost_eur(self) -> float:
        total_input = self.input_tokens * self.iterations
        total_output = self.output_tokens * self.iterations
        return (
            (total_input / 1_000_000) * self.cost_per_m_input +
            (total_output / 1_000_000) * self.cost_per_m_output
        )

    def __str__(self) -> str:
        return (
            f"{self.system_type}: "
            f"{self.iterations} iter × "
            f"({self.input_tokens} in + {self.output_tokens} out) token = "
            f"€{self.total_cost_eur:.4f}"
        )


# Prezzi indicativi llama3.1:8b su Ollama VPS (costo margine energia ~€0.002/h)
# Per cloud: sostituire con prezzi provider specifico
COSTO_PER_M_INPUT = 0.00  # Ollama self-hosted: costo infrastruttura fisso
COSTO_PER_M_OUTPUT = 0.00

# Confronto architetturale (modello cloud ipotetico a $3/MTok input)
CLOUD_INPUT_PRICE = 3.00   # €/MTok
CLOUD_OUTPUT_PRICE = 15.00  # €/MTok

esempi = [
    CostEstimate("Chatbot one-shot", 500, 200, CLOUD_INPUT_PRICE, CLOUD_OUTPUT_PRICE, 1),
    CostEstimate("RAG one-shot", 2_000, 500, CLOUD_INPUT_PRICE, CLOUD_OUTPUT_PRICE, 1),
    CostEstimate("Agent ReAct (5 step)", 1_500, 400, CLOUD_INPUT_PRICE, CLOUD_OUTPUT_PRICE, 5),
    CostEstimate("Agent ReAct (15 step)", 3_000, 600, CLOUD_INPUT_PRICE, CLOUD_OUTPUT_PRICE, 15),
    CostEstimate("Agent Plan-Execute (10 subtask)", 800, 300, CLOUD_INPUT_PRICE, CLOUD_OUTPUT_PRICE, 10),
    CostEstimate("Agent Reflexion (5 cicli)", 2_000, 800, CLOUD_INPUT_PRICE, CLOUD_OUTPUT_PRICE, 5),
]

# Output analisi costi
for e in esempi:
    print(e)

# Risultato tipico con modello cloud:
# Chatbot one-shot: 1 iter × (500 in + 200 out) token = €0.0046
# RAG one-shot: 1 iter × (2000 in + 500 out) token = €0.0138
# Agent ReAct (5 step): 5 iter × (1500 in + 400 out) token = €0.0525
# Agent ReAct (15 step): 15 iter × (3000 in + 600 out) token = €0.2700
# Agent Plan-Execute (10 subtask): 10 iter × (800 in + 300 out) token = €0.0690
# Agent Reflexion (5 cicli): 5 iter × (2000 in + 800 out) token = €0.0900

# CONCLUSIONE: un agent ReAct a 15 step costa ~60x un chatbot one-shot.
# Con Ollama self-hosted, il costo marginale di token è zero -
# ma il costo compute (GPU/CPU VPS) è comunque reale in latenza.

The numerical comparison is clear: an agent ReAct that iterates 15 times with increasing context costs around 60x a one-shot chatbot with cloud models. With Ollama self-hosted, the monetary cost per token is zero, but the real cost manifests itself in latency and CPU/GPU saturation of the VPS. For this reason, the ml-service portfolio uses Plan-Execute where possible (short subtasks, clean context) and ReAct only for exploratory tasks where the unpredictability of steps is genuine.

The budget for each step is critical production control: set Note: I preserved the formatting and punctuation of the original Italian text. max_iterations Conservatively, monitor the token count at every step, and implement a hard stop that returns a partial response instead of looping until the budget is exhausted. The next episode deals exactly with this: how to track each step with granular spans to know, in 5 seconds, which iteration burned through the budget. Note: I preserved the original formatting, punctuation, and capitalization style, as well as the token XPHX0XPHX and XPHX1XPHX.

Frequently Asked Questions

What is the concrete difference between an LLM agent and a chatbot?

A chatbot responds to a single input and stops: stateless, without persistent goals, without tools. An LLM agent maintains an objective through multiple iterations, decides autonomously on the next steps, uses tools to modify the external world (files, APIs, databases), and persists the state between iterations. The difference is not the number of LLM calls - it's the presence of a control loop with state. Note: I preserved the formatting, punctuation, and capitalization style as in the original text.

What is the ReAct pattern and when to use it?

ReAct (Reasoning + Acting) alternates explicit thought and action: the LLM writes a Note: I've translated "l'LLM" as "the LLM", assuming it's an abbreviation for "Large Language Model". If this is not correct, please let me know. Pensiero (what is he thinking), does a'Action (tool call), observes the'Osservazione (result of the tool), and decides whether to continue or give the final answer. It is the most suitable pattern for exploratory tasks - debugging, research, document analysis - where steps are not predictable in advance.

When to use Plan-Execute instead of ReAct?

Plan-Execute is preferable when the task has a predictable structure and subtasks are parallelizable. A Planner (large model, executed once) generates the plan; the Executors (smaller models) work in parallel on isolated contexts. It reduces latency by 40-60% and cost per step compared to pure ReAct. Limit: the initial plan must be accurate - a Planner that incorrectly decomposes sends everything offline.

Reflection really improves performance?

Yes, but with a cost in tokens (2-3x) and risk of Note: I preserved the XPHX0XPHX and XPHX1XPHX exactly as-is, following rule 1. Degenerazione del pensiero If the evaluation criteria in the Evaluator are vague. On the HotpotQA and AlfWorld benchmarks it improves accuracy by 20-40%. In production, limit to a maximum of 2-3 cycles and give the Evaluator structured and explicit criteria - not "evaluate if it's good" but "evaluate if it answers the question, cites sources, is concise".

How much does it cost to put a unit into production?

With cloud models at ~$3/MTok input, a 15-step ReAct agent costs around €0.27 per run - 60x more than a one-shot chatbot. With Ollama self-hosted, the monetary cost per token is zero, but latency increases (3-8 seconds for a call on llama3.1:8b on a VPS without dedicated GPU). Critical control is max_iterations Combined with monitoring of the token count for each step.

How does one persist the state of an agent between sessions?

Redis with TTL is the most pragmatic solution for sessions that last hours/days: serialize the entire state in JSON, key by session_id, 24h TTL renewable. For long-term state (weeks, months), pair Postgres. For GDPR compliance, keep the index session_id → user_id on Postgres so you can delete all data of a user even if distributed on Redis.

Tree of Thoughts is useful in production or just in research?

ToT is computationally expensive in its pure form. In production, pragmatic variants with a branching factor of 2-3 and depth of 2-3 achieve 60-70% of the benefit at a cost of 4-9x instead of 10-100x. It's useful only for tasks with objectively evaluable responses (puzzles, optimization, formal planning). For conversational or creative tasks, ReAct or Reflexion offer better quality-to-cost ratios.

Conclusion

An LLM agent is not just a smarter chatbot: it's a control system with specific architectural properties - autonomy of decision-making, persistence of state, tool use. Ignoring this distinction leads to choosing the wrong pattern, spending 60x more than necessary, and building systems that look like agents but behave like expensive batch pipelines.

The four patterns cover the problem space: ReAct for exploration, Plan-Execute for structure and parallelism, Reflexion for verifiable output precision, and Tree of Thoughts for optimization problems with objective responses. In the ml-service portfolio, Plan-Execute with ReAct for exploratory subtasks is the pattern that reduced perceived latency by 45% while maintaining response quality. Note: I preserved the exact formatting, punctuation, and capitalization style of the original text, as well as the proper nouns (ReAct, Plan-Execute, Reflexion, Tree of Thoughts) and HTML inline tags.

Next episode: observability and not getting lost in an infinite loop. When an agent fails after 47 tool calls, without granular tracing you don't know at which step it went wrong. We will see how to structure OpenTelemetry spans to have root-cause in 5 seconds, not 40 minutes - EP02: Observability agent: tracing span-per-thought.