CoT, ToT, ReAct, AOT, ATOM y MCP: arquitectura de prompts para desarrolladores, explicado sin rodeos

Cuando empiezas a trabajar en serio con LLMs, más allá de hacer algunas preguntas en un chat, sino construyendo sistemas reales, tarde o temprano te encuentras con estas abreviaciones. CoT. ToT. ReAct. AOT. ATOM. MCP. Al principio parecen más abreviaciones innecesarias, pero en realidad son conocimiento estructurado que necesitas como desarrollador de aplicaciones en cuanto integres AI en flujos de trabajo reales.

Ya hemos publicado varios artículos sobre temas relevantes en IA:

• Multiagentensysteme mit KI Agenten Frameworks
• Python Frameworks 2026
• Progressive Web Apps (PWAs)
• Hackathons und Coding Challenges 2026

Tal vez quieras revisarlos después.

Te lo explico paso a paso, con ejemplos y fragmentos de código, y también te diré cuándo no necesitas un concepto.

Arquitectura de Prompts con IA

CoT: Chain of Thought ToT: Tree of Thoughts ReAct: Reasoning and Action AOT: Ahead of Time ATOM: Atomic Task Management (o Agent Task Oriented Modeling / Atomic Prompting) MCP: Model Context Protocol

---

¿Qué es la arquitectura de prompts?

Antes de empezar: La arquitectura de prompts se refiere a cómo estructuras un prompt para que un modelo de lenguaje haga de forma confiable lo que quieres. No se trata de ser educado o formularse de manera creativa. Se trata de estructura, control y previsibilidad.

Muchos se quedan en la arquitectura estándar de prompts porque ya consiguen buenos resultados, pero “quedarse” no es nuestro objetivo. Si eres principiante, la estructura base de cualquier solicitud debería verse así:

La estructura clásica del prompt:

Rol: ¿Quién es el modelo?
Contexto / Situación actual: ¿Cuál es la situación?
Tarea: ¿Qué debe hacerse concretamente?
Formato: ¿Cómo debe ser la respuesta?
Restricciones: ¿Qué debe evitarse?

Un ejemplo práctico breve con instrucciones de depuración.

Eres un desarrollador Python experimentado especializado en programación de redes.

Tengo un bot IRC en Python que se conecta, pero no responde a mensajes PRIVMSG.
El bot usa socket directamente, sin framework.

Escribe una función parse_message() que analice la cadena IRC sin procesar
y devuelva Prefix, Command y Parameters.

Dame la función como código Python con un docstring breve.
Sin bibliotecas externas, sin framework, solo stdlib.

Este prompt ya te ahorrará mucho tiempo porque tendrás que hacer menos correcciones cuando intente usar otras bibliotecas, etc. Pero esto es solo un ejemplo breve.

En el futuro, el tiempo que pases discutiendo con una IA será muy relevante. Como desarrollador de aplicaciones, ya se espera que entregues resultados y soluciones rápidamente.

El prompt correcto no solo hace que la IA sea efectiva, sino que también te hace más productivo a ti.

Como desarrollador de aplicaciones, ya conoces este principio en el código: una función que lo hace todo de una vez es difícil de probar y depurar. Los prompts funcionan igual. Si le das demasiado al modelo de una vez, la calidad se desmorona.

Si aún no eres un desarrollador experimentado, sigue aprendiendo sobre orientación a objetos y arquitectura de software. También tenemos artículos sobre eso.

---

Empecemos con el primer concepto:

CoT: Chain of Thought

Categoría: Reasoning Prompting Conceptos clave: Chain of Thought, Reasoning, Intermediate Steps, Step-by-Step, Deliberation

¿Qué es CoT?

Chain of Thought significa obligar al modelo a crear explícitamente pasos intermedios en lugar de saltar directamente a la respuesta. Lo obligas a pensar en voz alta. El principio es simple: los modelos funcionan mejor en tareas complejas cuando documentan el camino de la solución antes de entregar la respuesta.

Como ves el “proceso de pensamiento” de la IA, también identificas los problemas en los que podría caer:

Ejemplos de problemas en el pensamiento de la IA causados por prompts confusos:

• ¿Se refería a Bach o a Bash? Probablemente Bash, ya que está escribiendo un programa. Asumiré Bash.
• ¿Con “Framework” se refiere a un web framework o a un testing framework? Sin contexto, la IA podría elegir el incorrecto.
• Con “optimiza el código” es ambiguo si se trata de rendimiento, legibilidad o consumo de memoria. La IA podría optimizar la métrica equivocada.

¿Cómo se ve CoT (Chain of Thought) en la práctica?

Sin CoT:

Prompt: ¿Cuántos segundos tiene un día?
Respuesta: 86400

Con CoT:

Prompt: ¿Cuántos segundos tiene un día? Piensa paso a paso.
Respuesta: Un día tiene 24 horas. Una hora tiene 60 minutos. Un minuto tiene 60 segundos.
          Entonces: 24 * 60 * 60 = 86400 segundos.

En preguntas simples, la diferencia no importa. En tareas complejas, como depuración de código, análisis de requisitos o cálculos multietapa, CoT hace una diferencia notable en la calidad. Aquí también te ayuda la experiencia de programar por tu cuenta. Es como jugar ajedrez, cuantos más errores cometes tú mismo, mejor los reconoces.

En la práctica como API Prompt

system_prompt = """
Eres un asistente de desarrollo. Cuando recibas una tarea:
1. Analiza el problema primero.
2. Lista los pasos intermedios.
3. Luego proporciona la solución.
No omitas pasos.
"""

Actualmente estoy configurando una interfaz API en una empresa para diferentes proveedores de IA. Este tipo de system prompt es útil en todos los modelos y proveedores de IA.

Cuándo CoT no es necesario

Para búsquedas simples o respuestas cortas, CoT consume tokens y tiempo sin aportar valor real. “¿Cuál es la capital de Francia?” no necesita Chain-of-Thought. El uso tiene sentido a partir de complejidad media.

Si volvemos al ejemplo de API, mi recomendación de “es apropiado” puede arruinarte rápidamente. Tienes razón al decir: “De ninguna manera es apropiado si tu API solo recibe preguntas simples sobre capitales. Entonces estás desperdiciando dinero, tiempo y tokens.”

El DevOps experimentado ajusta el system prompt en estos casos, extendiéndolo para preguntas cortas y largas. Reflexiona un momento: ¿tu recomendación de prompt podría perjudicarte con otros patrones de uso?

Ten en cuenta también que cuanto más largo es el system prompt, más cara resulta cada solicitud y cada respuesta subsecuente.

Con estos ejemplos solo quería darte puntos de reflexión, para que pienses en las arquitecturas y entiendas por qué tiene sentido hacerlo. En nuestra empresa procesamos múltiples archivos de 10 megabytes. El prompt puede hacer una solicitud entre 30 y 50 por ciento más económica, con la misma calidad de respuesta.

Pasemos ahora a Tree of Thoughts.

---

ToT – Tree of Thoughts

Categoría: Advanced Reasoning
Conceptos clave de IA: Tree of Thoughts, Branching, Search, Evaluation, Decision Tree

¿Qué es ToT (Tree of Thoughts)?

Tree of Thoughts va un paso más allá que CoT. En lugar de seguir un único hilo de razonamiento, dejas que el modelo explore múltiples caminos de solución en paralelo, los evalúa y elige el mejor.

La mayoría ya conocemos estos caminos en diferentes algoritmos. Aquí también se trata indirectamente del costo de los caminos.

Imagina un árbol de decisiones: cada nodo es un pensamiento intermedio, cada rama es un camino posible. El modelo recorre este árbol, descarta las ramas malas y continúa las prometedoras.

Ejemplo de árbol de decisiones para elegir una solución Job-Queue:

Inicio: Sistema Job-Queue requerido
├── Rama 1: Redis + BullMQ
│   ├── Ventaja: Rápido, en memoria
│   ├── Desventaja: Memoria limitada
│   └── Evaluación: Bueno para < 1.000.000 jobs
├── Rama 2: RabbitMQ
│   ├── Ventaja: Confiable, persistencia de mensajes
│   ├── Desventaja: Configuración más compleja
│   └── Evaluación: Bueno para sistemas críticos
└── Rama 3: Cola basada en Postgres
    ├── Ventaja: ACID, sin infraestructura adicional
    ├── Desventaja: Más lento que Redis
    └── Evaluación: Bueno para carga moderada, integración simple

Decisión: Cola basada en Postgres (mejor equilibrio para 10.000 jobs/hora)

Por qué es relevante

Con problemas que tienen múltiples enfoques posibles, como diseño de algoritmos, decisiones arquitectónicas o tareas creativas, ToT produce resultados cualitativamente mejores que un único hilo de razonamiento lineal.

Ejemplo: Decisión arquitectónica

Prompt:
Necesito una solución para un sistema Job-Queue. Explora tres enfoques diferentes:
1. Redis + BullMQ
2. RabbitMQ
3. Cola basada en Postgres (como pgqueue)

Para cada enfoque:
- Describe el enfoque central
- Menciona dos ventajas
- Menciona dos desventajas

Luego decide qué enfoque es mejor para un sistema con 10.000 jobs/hora.

Aquí fuerzas manualmente al modelo a una estructura ToT. En sistemas agentes reales, esto sucede programáticamente.

Cuándo ToT es excesivo

Si tu tarea está claramente definida y no hay espacio para múltiples caminos de solución, ToT es sobrecarga. “Corrige el error de sintaxis en este código Python” no necesita ramificación.

Pero acostúmbrate a enumerar o investigar primero todas las herramientas y posibilidades de implementación necesarias. Si no las conoces, siempre deberías ejecutar estos escenarios en “plan mode”. Es frustrante cuando el programa está listo después de 120 horas y se basa en una biblioteca Python antigua solo porque tiene más ejemplos disponibles. Y sí, esto me pasó exactamente.

Generative KI mit Python: KI im Unternehmenskontext

Dominar Python te ayuda enormemente, por eso una recomendación comercial:

Python para Ciencia de Datos y Machine Learning

Fundamentos de programación Python con enfoque en aplicaciones de IA y ejemplos prácticos para desarrollo de agentes.

---

ReAct – Reasoning y Action

Categoría: Agentensistemas
Conceptos clave: ReAct, Reasoning, Action, Tool Use, Agents, Retrieval, Function Calling, Iterative Reasoning

Y no, no me refiero al framework React.

¿Qué es ReAct?

ReAct es la combinación de Reasoning, es decir pensar, y Action, es decir actuar. Un agent, un sistema de IA autónomo, reflexiona sobre qué necesita, luego invoca una herramienta mediante Function Calling, por ejemplo una API o base de datos, recupera los datos mediante Retrieval, evalúa el resultado e itera el proceso si es necesario, eso es Iterative Reasoning.

En pocas palabras: pensar, actuar, verificar, seguir pensando.

ReAct combina razonamiento con acción. De nuevo: el modelo reflexiona, ejecuta una acción (por ejemplo, invocar una herramienta), verifica el resultado y luego continúa reflexionando. Este es el corazón de los agentes de IA modernos.

Ya lo has leído dos veces, ¿se siente mejor ahora?

El esquema se ve así: (Enfoque filosófico)

Thought: ¿Qué sé? ¿Qué necesito?
Action: [Invocar herramienta, por ejemplo web_search("precio actual de Bitcoin")]
Observation: [Resultado de la herramienta]
Thought: ¿Qué significa este resultado? ¿Cuál es el próximo paso?
Action: [Siguiente herramienta o respuesta final]

Por qué es importante para desarrolladores

Porque con esto construyes sistemas verdaderamente autónomos. Un agent ReAct puede, por ejemplo:

• Consultar una base de datos
• Interpretar el resultado
• Invocar una API
• Escribir el resultado de la API en un reporte

Todo sin intervención manual entre pasos.

Ejemplo simple con OpenAI Function Calling

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_db_records",
            "description": "Leets registros de la base de datos",
            "parameters": {
                "type": "object",
                "properties": {
                    "table": {"type": "string"},
                    "limit": {"type": "integer"}
                },
                "required": ["table"]
            }
        }
    }
]

# El modelo decide por sí solo si y cuándo invocar la herramienta
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Muestra los últimos 10 pedidos"}],
    tools=tools
)

Esto es ReAct en acción: el modelo reflexiona, se percata de que necesita datos, invoca la herramienta y procesa el resultado.

Cuándo ReAct no es la solución adecuada

ReAct solo tiene sentido si necesitas acceso a herramientas. El modelo debe interactuar con sistemas externos. La generación de texto puro no requiere ReAct.

Por supuesto, no todos los prompts producen buenos resultados y pueden interrumpirse antes de tiempo si la primera parte no ha generado información útil.

---

AOT – Ahead of Time

Categoría: Arquitectura de prompts, Diseño de agentes Conceptos clave de IA: AOT, Ahead of Time, Planning, Task Decomposition, Workflow Design, Agentic AI, Multi-Step Reasoning, Execution Plan

¿Qué es entonces AOT?

AOT significa “Ahead of Time”. El modelo planifica la solución completa antes de comenzar la ejecución. El flujo es:

Pregunta -> Crear plan -> Revisar plan -> Ejecutar -> Respuesta

En lugar de responder de inmediato, el modelo genera primero un plan de ejecución. Solo cuando el plan está listo se ejecuta.

¿Por qué es mejor que la ejecución directa?

La ejecución directa provoca alucinaciones porque el modelo toma decisiones sobre la marcha sin ver el panorama completo. Con AOT, el modelo tiene el contexto total al crear el plan y luego lo sigue de manera disciplinada.

Ejemplo concreto: Pipeline de revisión de código

Sin AOT:

Prompt: Revisa este código en busca de errores.
[El modelo comienza a comentar directamente, posiblemente omitiendo partes]

Con AOT:

System: Primero crea un plan completo de revisión. Lista todos los aspectos
        que verificarás: sintaxis, errores lógicos, seguridad, rendimiento, legibilidad.
        Luego ejecuta el plan punto por punto.

User: [Insertar código]

El resultado es más estructurado, más completo y menos propenso a omisiones.

Casi toda IA funciona con listas de tareas.

AOT como plantilla de prompt

aot_template = """
Tarea: {task}

Paso 1 - Planificación:
Crea un plan de ejecución completo con pasos numerados.
No escribas la solución aún, solo el plan.

Paso 2 - Revisión del plan:
Verifica tu plan. ¿Faltan pasos? ¿Es lógico el orden?

Paso 3 - Ejecución:
Ejecuta el plan paso a paso.
"""

Cuándo no necesitas AOT

Las tareas simples de un solo paso no requieren un plan previo. “Traduce este texto al inglés” no es un caso para AOT. El costo adicional sería mayor que el beneficio.

---

ATOM – Atomic Task Management

Categoría: Marcos de agentes, Estructuras de prompts Conceptos clave de IA: ATOM, Atomic Tasks, Task Graph, Workflow Nodes, Dependency Mapping, Agent Orchestration, Atomic Prompting

¿Qué es ATOM?

ATOM puede significar “Agent Task Oriented Modeling”, “Atomic Task Management” o “Atomic Prompting” según el contexto. La idea central es siempre la misma: las tareas grandes se dividen en unidades pequeñas y atómicas que se pueden ejecutar de forma independiente.

“Atómico” aquí significa: una tarea hace exactamente una cosa, está claramente delimitada, tiene entradas y salidas definidas, y es independientemente verificable.

¿Por qué es importante?

Imagina que quieres usar un LLM para generar automáticamente documentación técnica. Eso no es una tarea única, es un flujo de trabajo completo. Con ATOM lo desglosas así:

1. Analizar código fuente
   Entrada: Archivo Python
   Salida: Lista de funciones con firmas

2. Extraer docstrings
   Entrada: Lista de funciones
   Salida: Documentación existente por función

3. Identificar documentación faltante
   Entrada: Funciones + docstrings existentes
   Salida: Lista de funciones sin documentar

4. Generar documentación
   Entrada: Una función sin documentar
   Salida: Docstring listo

5. Insertar documentación
   Entrada: Función + docstring generado
   Salida: Archivo actualizado

Cada paso es atómico. Cada paso es verificable. Puedes depurar cada paso individualmente. La capacidad de depurar es increíblemente importante, por eso nunca debes saltarte un paso. Muchas IA no encuentran sus errores complejos porque han creado duplicadamente muchos métodos o cambian el nombre de variable a mitad del proceso. Te ahorra tiempo, dinero y frustración.

ATOM como Task-Graph

from dataclasses import dataclass
from typing import List

@dataclass
class AtomicTask:
    id: str
    description: str
    inputs: List[str]
    outputs: List[str]
    depends_on: List[str]  # Dependency Mapping

tasks = [
    AtomicTask(
        id="analyze_code",
        description="Analiza el código fuente",
        inputs=["source_file"],
        outputs=["function_list"],
        depends_on=[]
    ),
    AtomicTask(
        id="generate_docs",
        description="Genera documentación",
        inputs=["function_list"],
        outputs=["documentation"],
        depends_on=["analyze_code"]
    )
]

¿Cuándo es ATOM excesivo?

Si tu flujo de trabajo consta de dos o tres pasos y no tienes planes de escalar, el costo de gestionar el grafo de tareas no se justifica. ATOM escala con la complejidad de tu sistema.

---

The AI Agent Handbook

Introducción práctica a la programación y creación de agentes de IA con ejemplos concretos e instrucciones paso a paso.

---

MCP – Model Context Protocol

Categoría: LLM-Infrastruktur Keywords: MCP, Model Context Protocol, Context, Tools, Connectors, APIs, Agent Ecosystem

¿Qué es MCP?

Ya hemos cubierto MCP varias veces en este sitio:

• Sistemas multiagente con frameworks de agentes IA (este artículo)
• Más artículos sobre MCP próximamente

MCP, el Model Context Protocol, es un estándar abierto que define cómo un modelo de lenguaje puede acceder a sistemas externos. Anthropic publicó el protocolo a finales de 2024, y desde entonces se ha establecido como el estándar de facto para la integración de herramientas de IA.

Piensa en MCP como el USB-C de los agentes de IA. En lugar de construir una integración diferente para cada aplicación, cada API, cada tipo de base de datos, existe un conector único. Un servidor MCP proporciona recursos, y cualquier modelo compatible con MCP puede utilizarlos.

Descripción general de la arquitectura MCP

┌─────────────────┐      MCP-Protokoll     ┌──────────────────────┐
│   LLM / Client  │ ─────────────────────▶ │     MCP-Server       │
│  (z.B. Claude)  │                         │  (z.B. Datenbank,    │
│                 │ ◀───────────────────── │   Dateisystem, API)  │
└─────────────────┘    Ressourcen, Tools   └──────────────────────┘

Un servidor MCP proporciona tres cosas:

• Resources: Datos que el modelo puede leer (contenido de archivos, entradas de base de datos, etc.)
• Tools: Funciones que el modelo puede invocar (escribir archivos, llamadas a API, etc.)
• Prompts: Plantillas de prompts predefinidas

Servidor MCP simple en Python

from mcp.server import Server
from mcp.server.models import InitializationOptions
import mcp.types as types

app = Server("mein-dev-server")

@app.list_tools()
async def list_tools() -> list[types.Tool]:
    return [
        types.Tool(
            name="get_file_content",
            description="Liest den Inhalt einer Datei",
            inputSchema={
                "type": "object",
                "properties": {
                    "path": {
                        "type": "string",
                        "description": "Pfad zur Datei"
                    }
                },
                "required": ["path"]
            }
        )
    ]

@app.call_tool()
async def call_tool(name: str, arguments: dict) -> list[types.TextContent]:
    if name == "get_file_content":
        path = arguments["path"]
        with open(path, "r") as f:
            content = f.read()
        return [types.TextContent(type="text", text=content)]

¿Por qué MCP es tan relevante en 2026 y será aún más en 2027?

Porque el mercado se está decidiendo por MCP como estándar. Claude soporta MCP nativamente. Muchos IDEs, herramientas y plataformas construyen servidores MCP. Si hoy estás construyendo sistemas de IA que necesitan acceso a datos externos, MCP es el camino que debes conocer.

Caso de uso práctico: MCP para herramientas internas

En una empresa podrías construir un servidor MCP que proporcione acceso a:

• Base de conocimiento interna (Confluence, Notion)
• Sistema de tickets (Jira, Linear)
• Repositorio de código (GitHub, GitLab)
• APIs internas

El modelo puede entonces leer tickets de forma autónoma, revisar código, consultar documentación y ejecutar acciones sin que necesites escribir código de integración personalizado para cada conexión.

¿Cuándo no necesitas MCP?

Si tu LLM no requiere datos externos y solo hace generación de texto, no necesitas MCP. MCP es infraestructura para sistemas de agentes, no para aplicaciones de chat simples.

Dado que MCP puede sonar complicado, aquí te muestro nuevamente su estructura básica y ejemplos típicos.

MCP y cómo se construye en la práctica

Los tres roles en MCP:

• Host: el programa que utiliza el LLM, por ejemplo Claude Desktop, Cursor, o tu propia aplicación
• Client: integrado en el Host, establece la conexión MCP
• Server: tu código personalizado que proporciona herramientas y datos

Ejemplo concreto: gestión de un bot IRC

Quieres que Claude pueda controlar tu bot IRC, es decir, unirse a canales, enviar mensajes, leer logs.

Host (Claude Desktop)
    └── MCP Client
            └── se conecta con --> Tu MCP Server (Python)
                                            ├── Tool: send_message(channel, text)
                                            ├── Tool: join_channel(channel)
                                            └── Resource: get_logs(lines=50)

El servidor MCP es simplemente un proceso Python normal que se ejecuta localmente, nada especial.

Claude se comunica con él a través de stdio o HTTP.

¿Qué software necesitas?

pip install mcp

Eso es todo. Sin frameworks, sin infraestructura complicada.

Servidor MCP mínimo para el bot IRC:

from mcp.server import Server
from mcp.server.stdio import stdio_server
import mcp.types as types

app = Server("irc-bot-server")

@app.list_tools()
async def list_tools() -> list[types.Tool]:
    return [
        types.Tool(
            name="send_message",
            description="Sendet eine Nachricht in einen IRC-Channel",
            inputSchema={
                "type": "object",
                "properties": {
                    "channel": {"type": "string"},
                    "text": {"type": "string"}
                },
                "required": ["channel", "text"]
            }
        )
    ]

@app.call_tool()
async def call_tool(name: str, arguments: dict):
    if name == "send_message":
        channel = arguments["channel"]
        text = arguments["text"]
        # Hier rufst Du Deinen echten IRC-Bot auf
        irc_bot.send(channel, text)
        return [types.TextContent(type="text", text="Nachricht gesendet")]

async def main():
    async with stdio_server() as (read, write):
        await app.run(read, write, app.create_initialization_options())

import asyncio
asyncio.run(main())

¿Cómo registras el servidor en Claude Desktop?

En el archivo de configuración de Claude Desktop “claude_desktop_config.json”:

  "mcpServers": {
    "irc-bot": {
      "command": "python",
      "args": ["/pfad/zu/deinem/irc_mania_mcp_server.py"]
    }
  }
}

Claude Desktop inicia el proceso Python automáticamente al abrirse. A partir de entonces, Claude puede invocar la herramienta send_message siempre que tenga sentido.

Distribución de tareas en resumen:

Quién	Qué hace
Claude (Host)	Decide cuándo invocar cada herramienta
MCP Client	Traduce las llamadas de herramientas al protocolo MCP
Tu servidor MCP	Ejecuta la lógica real, se comunica con el bot IRC
Bot IRC	Realiza la comunicación de red actual

---

Todos los conceptos trabajando juntos

Como en la vida real, necesitarás conocer todos estos conceptos porque los usarás todos. Cuando los system prompts se vuelven demasiado costosos, conocerás el concepto para solicitudes más simples. ¡Eres el diseñador de la IA!

En sistemas reales combinas todos estos conceptos. Aquí hay un ejemplo: un asistente de desarrollador que realiza revisiones automáticas de pull requests.

1. [AOT]  El agente crea un plan de revisión:
          - Revisar sintaxis
          - Revisar lógica
          - ¿Hay tests?
          - Verificación de seguridad

2. [ATOM] Cada paso del plan es una tarea atómica con entrada/salida definida.

3. [ReAct] Para cada tarea:
           - Reflexiona sobre qué se necesita
           - Usa herramienta MCP para cargar código desde GitHub
           - Verifica el resultado
           - Escribe comentario a través de GitHub API

4. [CoT]  Dentro de cada tarea, el modelo piensa paso a paso,
          en lugar de hacer un juicio directo.

5. [ToT]  Para verificaciones de seguridad se evalúan múltiples vectores de ataque en paralelo.

6. [MCP]  El servidor GitHub MCP proporciona acceso a diffs, commits, issues.

Una vez más, un resumen de las arquitecturas y conceptos de IA

Concepto	Idea central	Cuándo tiene sentido
CoT	Pensar paso a paso	Tareas de razonamiento complejo
ToT	Explorar múltiples caminos	Problemas abiertos con varias soluciones
ReAct	Pensar y actuar	Agentes con acceso a herramientas
AOT	Planificar primero, luego ejecutar	Workflows estructurados en múltiples etapas
ATOM	Atomizar tareas	Pipelines complejas, sistemas escalables
MCP	Estándar para acceso a herramientas	Agentes de IA que interactúan con sistemas externos

No necesitas usar los seis conceptos en cada proyecto. Pero cuando empieces a construir sistemas de agentes reales, te darás cuenta de que intuitivamente usas exactamente estos patrones. Es útil conocer los nombres.

Al final, es beneficioso entender arquitectura de software y ser capaz de aplicarla. La IA no siempre te lo señalará.

Si ya sabes programar bien, echa un vistazo a algunos Design Patterns, o el Gang of Four.

Comprueba tu conocimiento sobre CoT, ToT, ReAct, AOT, ATOM, MCP

A continuación encontrarás preguntas y respuestas típicas sobre arquitectura de software y conceptos de IA. Te ayudarán a prepararte para posibles tareas o exámenes.

Están estructuradas en formato FAQ, cortas y concisas. La mayoría de nuestros artículos incluyen secciones de aprendizaje breves.

FAQ Arquitecturas de IA y Conceptos de IA

¿Qué es Chain of Thought (CoT) y cómo mejora la calidad de las respuestas de IA?

Chain of Thought es una técnica de prompting en la que el modelo se instruye para documentar su proceso de solución paso a paso antes de dar la respuesta final. Esto mejora la calidad porque hace explícito el proceso de pensamiento, permite verificar pasos intermedios y resulta en respuestas más lógicas y menos propensas a errores.

¿Cuándo no debe usarse CoT?

CoT no debe usarse en búsquedas simples o respuestas cortas, ya que consume tokens y tiempo adicionales sin aporte significativo. Ejemplos: preguntas de hecho simples como “¿Cuál es la capital de Francia?” o traducciones breves.

¿Cuál es la diferencia entre CoT y Tree of Thoughts (ToT)?

CoT sigue un único camino de pensamiento lineal, mientras que ToT explora múltiples caminos de solución en paralelo, los evalúa y elige el mejor. ToT es especialmente útil para problemas con varias soluciones posibles, mientras que CoT es suficiente para tareas de razonamiento lineal.

¿Cómo funciona Tree of Thoughts (ToT) en la práctica?

ToT crea un árbol de decisiones con múltiples ramas (caminos de solución), busca activamente en estas, evalúa cada camino por calidad y probabilidad de éxito, y descarta ramas pobres mientras continúa con las prometedoras. Esto ocurre manualmente mediante estructuración de prompts o programáticamente en sistemas de agentes.

¿Qué es ReAct y cómo se diferencia del simple Function Calling?

ReAct combina Reasoning (razonamiento) con Action (acción) en un ciclo iterativo: el modelo piensa, llama una herramienta, verifica el resultado y continúa pensando. El Function Calling simple solo es la invocación de la herramienta, mientras que ReAct incluye todo el proceso de pensamiento y repite según sea necesario.

¿Qué componentes tiene un agente ReAct?

Un agente ReAct consta de Reasoning (pensamiento estructurado sobre el problema), Action (invocaciones de herramientas como APIs o bases de datos), Retrieval (consulta de datos), Function Calling (la implementación técnica de las invocaciones de herramientas) e Iterative Reasoning (pensamiento repetido después de cada acción).

¿Qué es AOT (Ahead of Time) Prompting?

AOT significa que el modelo crea primero un plan de ejecución completo, lo verifica y solo luego comienza la ejecución. El flujo es: Pregunta → Crear plan → Verificar plan → Ejecutar → Respuesta.

¿Por qué es AOT mejor que la ejecución directa en tareas complejas?

En ejecución directa, el modelo toma decisiones durante el proceso sin tener la visión completa, lo que puede causar alucinaciones. Con AOT, el modelo tiene todo el contexto al crear el plan y luego sigue disciplinadamente el plan, resultando en respuestas más estructuradas y completas.

¿Qué es ATOM (Atomic Task Management)?

ATOM significa la descomposición de tareas grandes en unidades pequeñas y atómicas que son ejecutables individualmente. Cada tarea atómica hace exactamente una cosa, tiene inputs y outputs definidos, y es independientemente testeable.

¿Cuándo es ATOM excesivo?

ATOM es excesivo cuando el workflow consta solo de dos o tres pasos y no necesita escalabilidad. El overhead del task-graph management no está justificado. ATOM escala con la complejidad del sistema.

¿Qué es MCP (Model Context Protocol)?

MCP es un estándar abierto de Anthropic que define cómo los modelos de lenguaje pueden acceder a sistemas externos. Actúa como un “conector” unificado para agentes de IA, permitiendo acceso a bases de datos, sistemas de archivos, APIs y otros recursos.

¿Qué tres componentes proporciona un servidor MCP?

Un servidor MCP proporciona Resources (datos que el modelo puede leer), Tools (funciones que el modelo puede invocar) y Prompts (plantillas de prompt predefinidas).

¿Cómo trabajan juntos MCP Host, Client y Server?

El Host (p.ej. Claude Desktop) usa el LLM, el Client está integrado en el Host y establece la conexión MCP, y el Server es tu código que proporciona herramientas y datos. La comunicación ocurre por stdio o HTTP.

¿Qué es un Task Graph en el contexto de ATOM?

Un Task Graph es la representación gráfica o estructural de todas las tareas y sus conexiones. Cada nodo es una tarea atómica, y los bordes definen las dependencias entre tareas.

¿Qué significa Dependency Mapping?

Dependency Mapping define qué tarea debe esperar a qué otras tareas, es decir, qué dependencias existen. Es crucial para el orden correcto de ejecución en un task-graph.

¿Qué es Agent Orchestration?

Agent Orchestration significa quién o qué controla el orden de ejecución y asegura que todo se ejecute en el orden correcto. Puede ser un orquestador central, un sistema descentralizado, o el modelo mismo.

¿Cómo se diferencia Agentic AI de los chatbots tradicionales?

Agentic AI es un sistema de IA que ejecuta tareas de forma autónoma sin que una persona lance manualmente cada paso. Los chatbots tradicionales solo reaccionan a entradas, mientras que Agentic AI actúa proactivamente, usa herramientas y recorre workflows complejos.

¿Qué es Multi-Step Reasoning?

Multi-Step Reasoning es la capacidad del modelo de pensar coherentemente a través de múltiples pasos intermedios, manteniendo el hilo conductor. Es especialmente importante en AOT y tareas complejas.

¿Qué es Task Decomposition?

Task Decomposition significa desglosar una tarea grande en subtareas más pequeñas y manejables. Es un concepto central de AOT y ATOM.

¿Qué es Workflow Design?

Workflow Design es el plan estructurado del orden en que se ejecutan las subtareas. Es parte de AOT y ATOM.

¿Cómo se implementa CoT en un prompt de API?

Un ejemplo de systemprompt con CoT: “Eres un asistente de desarrollo. Cuando recibas una tarea: 1. Analiza el problema primero. 2. Lista los pasos intermedios. 3. Luego da la solución. No omitas pasos.”

¿Cuáles son casos de uso típicos para ToT?

Los casos típicos para ToT son diseño de algoritmos, decisiones de arquitectura, tareas creativas y problemas con múltiples enfoques posibles.

¿Cómo se puede forzar ToT manualmente en un prompt?

Puedes forzar ToT pidiendo al modelo que explore múltiples enfoques, evalúe cada uno y seleccione el mejor. Ejemplo: “Explora tres enfoques diferentes, describe ventajas y desventajas, y decide cuál es el mejor.”

¿Cuál es la desventaja de ToT?

La desventaja de ToT es el mayor consumo de tokens y tiempo de procesamiento, ya que múltiples caminos de solución deben explorarse en paralelo. Para tareas simples, este overhead no está justificado.

¿Cómo se diferencia ReAct del simple Chain of Thought?

CoT es puramente basado en razonamiento (solo pensar), mientras que ReAct combina razonamiento con acción (pensar + actuar). ReAct puede invocar herramientas externas y reaccionar a resultados, CoT no puede.

¿Qué es Iterative Reasoning?

Iterative Reasoning es el proceso donde el modelo verifica el resultado después de cada acción y continúa pensando. Es un concepto central de ReAct.

¿Cómo se estructura AOT como una plantilla de prompt?

Una plantilla AOT podría verse así: “Paso 1 - Planificación: Crea un plan de ejecución completo. Paso 2 - Revisión del plan: Verifica el plan por completitud y lógica. Paso 3 - Ejecución: Ejecuta el plan paso a paso.”

¿Qué es un Execution Plan?

Un Execution Plan es un desglose detallado de todos los pasos requeridos para resolver una tarea. Se crea en AOT antes de que comience la ejecución real.

¿Cómo se implementa ATOM en Python?

ATOM puede implementarse con una dataclass que contenga id, description, inputs, outputs y depends_on. Múltiples AtomicTasks pueden entonces combinarse en un task-graph.

¿Qué son Workflow Nodes?

Workflow Nodes son los nodos individuales en un task-graph, es decir, cada tarea atómica. Tienen inputs y outputs definidos y pueden depender unos de otros.

¿Cómo se crea un servidor MCP en Python?

Un servidor MCP puede crearse con la librería mcp. Defines herramientas con inputSchema e implementas la función call_tool que ejecuta la lógica real.

¿Cómo se registra un servidor MCP en Claude Desktop?

Registras el servidor en el archivo “claude_desktop_config.json” bajo “mcpServers” con el command (p.ej. “python”) y los args (ruta al script del servidor).

¿Cuáles son las ventajas de MCP sobre integraciones individuales?

MCP ofrece un estándar unificado que funciona con todos los modelos compatibles. En lugar de construir una integración separada para cada app, API y tipo de base de datos, un servidor MCP es suficiente.

¿Cómo se combinan CoT, ToT, ReAct, AOT, ATOM y MCP en la práctica?

En sistemas reales, todos los conceptos se combinan: AOT planifica el workflow, ATOM lo desglosa en tareas atómicas, ReAct ejecuta las tareas con acceso a herramientas vía MCP, CoT piensa paso a paso dentro de cada tarea, y ToT evalúa múltiples caminos en paralelo en decisiones críticas.

¿Cuál es la diferencia entre Branching y Search en ToT?

Branching es abrir múltiples caminos de solución paralelos, Search es buscar activamente entre esos ramos por la mejor solución.

¿Qué es Evaluation en ToT?

Evaluation es evaluar cada camino por calidad y probabilidad de éxito, para decidir qué ramas continuar y cuáles descartar.

¿Qué es un Decision Tree en el contexto de ToT?

Un Decision Tree es la estructura interna que el modelo construye para organizar los diferentes caminos de solución y sus evaluaciones. Los ramos pobres se descartan, los prometedores se continúan.

¿Cómo se puede usar CoT para debug de código?

Puedes pedir al modelo que analice el código paso a paso, identifique posibles fuentes de errores y desarrolle soluciones sistemáticamente, en lugar de sugerir un fix directo.

¿Cuál es la diferencia entre Deliberation y Reasoning?

Reasoning es la deducción estructurada basada en información existente, Deliberation es sopesar activamente opciones y justificar decisiones. Ambos son parte de CoT.

¿Cómo se puede usar AOT para pipelines de code review?

Puedes pedir al modelo que cree primero un plan de review completo (Sintaxis, Lógica, Seguridad, Performance, Legibilidad), lo verifique, y luego lo ejecute punto a punto.

¿Cuál es la diferencia entre Atomic Prompting y Atomic Task Management?

Atomic Prompting se refiere a desglosar prompts en unidades pequeñas y enfocadas, mientras que Atomic Task Management se refiere a desglosar tareas en unidades atómicas. Ambos siguen el mismo principio de granularidad.

¿Cómo se puede usar ATOM para generación de documentación?

Puedes desglosar el workflow en pasos atómicos: 1. Analizar código fuente, 2. Extraer docstrings, 3. Identificar documentación faltante, 4. Generar documentación, 5. Insertar documentación.

¿Cuáles son las desventajas de AOT en tareas simples?

En tareas simples, el overhead de creación y revisión del plan es mayor que el beneficio. “Traduce este texto al inglés” no es un caso para AOT.

¿Cómo se puede usar MCP para herramientas internas de empresa?

Puedes construir un servidor MCP que proporcione acceso a bases de conocimiento internas, sistemas de tickets, repositorios de código y APIs internas. El modelo puede entonces leer tickets de forma independiente, revisar código y ejecutar acciones.

¿Cuál es la diferencia entre MCP y Function Calling?

Function Calling es una técnica específica para invocar herramientas, mientras que MCP es un estándar completo que define cómo los modelos interactúan con sistemas externos. MCP puede usar Function Calling, pero no se limita a ello.

¿Cómo se puede medir la calidad de resultados de ToT?

La calidad puede medirse comparando con soluciones ground-truth, mediante evaluación humana, o mediante métricas automáticas como consistencia entre diferentes ramos.

¿Cuál es la diferencia entre orquestación secuencial y jerárquica de agentes?

Orquestación secuencial es una pipeline donde un agente pasa la tarea al siguiente. Orquestación jerárquica tiene un agente gerente que delega tareas a agentes especializados y controla.

¿Cómo se puede usar ReAct para consultas de base de datos?

Un agente ReAct puede pensar qué datos necesita, invocar una herramienta para consultar la base de datos, verificar el resultado, y realizar consultas adicionales según sea necesario hasta obtener la información deseada.

¿Cuál es la diferencia entre Retrieval y Tool Use en ReAct?

Retrieval es recuperar datos de una fuente (p.ej. base de datos, base de datos vectorial), Tool Use es invocar una función que ejecuta una acción (p.ej. escribir archivo, llamada a API). Ambos son parte de ReAct.

¿Cómo se puede usar AOT para cálculos multietapa?

Puedes pedir al modelo que desglose el cálculo en pasos lógicos, planifique cada paso, verifique el plan, y luego ejecute paso a paso para evitar errores.

¿Cuál es la diferencia entre ATOM y Microservicios?

ATOM se refiere a desglosis de tareas en un contexto de IA, mientras que Microservicios es un patrón de arquitectura para software. Ambos siguen el principio de granularidad e independencia, pero ATOM es específico para workflows de IA.

¿Cómo se puede usar MCP para acceso al sistema de archivos?

Un servidor MCP puede proporcionar herramientas como “get_file_content”, “write_file” y “list_directory”. El modelo puede entonces leer, escribir y buscar archivos de forma independiente.

¿Cuáles son las mejores prácticas para prompts CoT?

Las mejores prácticas son: solicitud explícita de pensamiento paso a paso, definición de la estructura de los pasos intermedios, solicitud de justificación de cada decisión, y evitar tareas demasiado complejas en un único prompt.

¿Cómo se puede usar ToT para tareas creativas?

Puedes pedir al modelo que genere múltiples enfoques creativos (p.ej. diferentes ideas de historias, conceptos de diseño), evalúe cada uno, y seleccione o combine los mejores.

¿Cuál es la diferencia entre AOT y JIT (Just-in-Time) Prompting?

AOT planifica con anticipación antes de que comience la ejecución. JIT planifica y ejecuta simultáneamente, sin un paso de planificación separado. AOT es más estructurado y menos propenso a errores, pero más lento en tareas simples.

¿Cómo se puede usar ATOM para pipelines de CI/CD?

Puedes desglosar la pipeline en pasos atómicos: Build, Test, Lint, Security-Scan, Deploy. Cada paso tiene inputs y outputs definidos y puede ejecutarse y probarse independientemente.

¿Cuál es la diferencia entre MCP y APIs REST?

MCP es un estándar específico para integración con modelos de IA, mientras que APIs REST es un estándar web general. MCP puede implementarse sobre REST, pero está optimizado para necesidades de agentes de IA.

¿Cómo se puede optimizar el rendimiento de workflows ATOM?

El rendimiento puede optimizarse mediante paralelización de tareas independientes, caching de resultados, minimización del tamaño de tareas, y estrategias eficientes de dependency management.

¿Cuál es la diferencia entre CoT y Few-Shot Prompting?

CoT solicita al modelo mostrar su proceso de pensamiento. Few-Shot Prompting proporciona al modelo ejemplos de pares entrada-salida deseados. Ambos pueden combinarse para mejorar la calidad.

¿Cómo se puede usar ReAct para web scraping?

Un agente ReAct puede pensar qué información necesita, invocar una herramienta para cargar una página web, parsear el contenido, extraer datos relevantes, y visitar páginas adicionales según sea necesario.

¿Cuáles son los desafíos en la implementación de MCP?

Los desafíos incluyen: seguridad (sandboxing), manejo de errores, versionado de APIs, rendimiento con grandes volúmenes de datos, y compatibilidad entre diferentes modelos y hosts.

¿Cómo se puede usar AOT para lógica de negocio compleja?

Puedes pedir al modelo que desgloses la lógica de negocio en pasos lógicos, identifique dependencias, cree un plan de ejecución, y luego ejecute paso a paso para asegurar consistencia.

¿Cuál es la diferencia entre ATOM y MapReduce?

ATOM es un concepto para workflows de IA con tareas atómicas y dependencias. MapReduce es un modelo de programación para procesamiento paralelo de grandes volúmenes de datos. Ambos desglosan tareas, pero ATOM está optimizado para workflows específicos de IA.

¿Cómo se puede usar MCP para datos en tiempo real?

Un servidor MCP puede proporcionar webhooks o conexiones de streaming para entregar datos en tiempo real al modelo. El modelo puede entonces reaccionar a eventos en tiempo real y ejecutar acciones correspondientes.

¿Cuáles son las diferencias entre CoT, ToT y ReAct en términos de consumo de tokens?

CoT consume moderadamente más tokens a través de la documentación del proceso de pensamiento. ToT consume significativamente más tokens por la exploración paralela de múltiples caminos. ReAct consume variablemente más tokens dependiendo de la cantidad de invocaciones de herramientas e iteraciones.

¿Cómo se puede evaluar la calidad de planes AOT?

La calidad puede evaluarse mediante revisión manual, mediante verificaciones automáticas (completitud, lógica, consistencia), o mediante comparación con soluciones de referencia.

¿Cuál es la diferencia entre ATOM y State Machines?

ATOM se enfoca en desglosis de tareas y sus dependencias. State Machines se enfocan en estados y transiciones de estado. Ambos pueden combinarse para modelar workflows complejos.

¿Cómo se puede usar MCP para entornos multi-cloud?

Un servidor MCP puede proporcionar herramientas abstractas que detrás de escenas interactúan con diferentes proveedores de cloud (AWS, Azure, GCP). El modelo puede entonces trabajar sin dependencia de proveedor.

¿Cuáles son las mejores prácticas para agentes ReAct?

Las mejores prácticas son: definiciones claras de herramientas, manejo robusto de errores, límites de iteraciones, observabilidad detallada, y verificación humana en acciones críticas.

¿Cómo se puede usar ToT para análisis de seguridad?

Puedes pedir al modelo que evalúe múltiples vectores de ataque en paralelo, los califique, y priorice los más críticos. Esto permite un análisis de seguridad más exhaustivo que CoT lineal.

¿Cuál es la diferencia entre AOT y Planning en IA clásica?

IA clásica de Planning usa representaciones simbólicas y algoritmos de búsqueda. AOT usa LLMs para generar planes en lenguaje natural. Ambos apuntan al mismo objetivo, pero usan métodos diferentes.

¿Cómo se puede usar ATOM para Data Pipelines?

Puedes desglosar la pipeline en pasos atómicos: Extracción de datos, Transformación, Validación, Carga. Cada paso tiene inputs y outputs definidos y puede ejecutarse y monitorearse independientemente.

¿Cuáles son las perspectivas futuras para MCP?

Se espera que MCP se convierta en el estándar de facto para integración de herramientas de IA, con soporte amplio de modelos, IDEs y plataformas. Las extensiones podrían incluir modelos de seguridad más comprehensivos, mejor observabilidad y catálogos de herramientas estandarizados.