Anatomía de un ciclo agéntico

Un chatbot recibe un mensaje y devuelve una respuesta. Un agente hace algo muy distinto: ejecuta un ciclo. Razona sobre qué hacer, toma una acción (casi siempre la llamada a una herramienta), observa el resultado y decide si ya terminó o si necesita dar otra vuelta.

Ese ciclo lo es todo, y todo lo que Thaliq construye vive debajo de él. Así que, en lugar de describirlo, pulsa Reproducir y mira una ejecución:

El ciclo del agente

Un ejemplo guionizado, no un agente en vivo.

Estado de un pedidoReembolso con aprobación

1. Razona
2. Actúa
3. Observa
4. Responde

1. ¿Dónde está mi pedido #1234?
2. Pulsa Reproducir o Paso para ver trabajar al agente.

ReiniciarPasoReproducir

Paso 0 de 4

Razona, actúa, observa, repite

Cada vuelta del ciclo tiene la misma forma:

• Razona. El modelo decide qué debe pasar a continuación. A veces es “ya puedo responder”. Muchas veces es “necesito más información”.
• Actúa. El modelo llama a una herramienta: un endpoint HTTP tuyo o un servidor MCP. Aquí es donde el agente toca el mundo real.
• Observa. El resultado de la herramienta vuelve al contexto y el modelo razona de nuevo.

El ciclo sigue hasta que el modelo tiene lo necesario para responder. Dos llamadas a herramientas o diez, la forma nunca cambia, y por eso mismo puede ser infraestructura.

Las herramientas son lo que permite al agente hacer algo real

Un modelo, por sí solo, únicamente puede producir texto. Declara una herramienta como check_order o create_ticket, ya sea una herramienta HTTP que apunta a tu API o una herramienta de un servidor MCP que tú operas, y el agente podrá consultar datos y ejecutar acciones. En la primera ejecución de arriba, el agente no sabe dónde está el pedido #1234: llama a una herramienta para averiguarlo y responde a partir del resultado. Sin números de seguimiento inventados.

Cuándo el ciclo debe detenerse y preguntar a una persona

Mira la segunda ejecución, Reembolso con aprobación. El agente llega a un punto en el que podría actuar, pero un reembolso mueve dinero. Una herramienta declara su riesgo (read, write o money), y una Policy decide qué riesgos esperan a una persona. Así que la ejecución se pausa, no ocupa ningún worker mientras espera y continúa cuando alguien con el rol adecuado la aprueba desde la consola.

Eso no es una limitación: es el diseño. Autonomía donde es seguro, un punto de control humano donde no lo es. El ciclo es donde se aplica esa regla.

Por qué esto es infraestructura y no un prompt

Ejecutar un ciclo en un notebook es fácil. Ejecutar miles en producción, no. El ciclo necesita:

• Streaming, para que la gente vea la respuesta y las llamadas a herramientas a medida que ocurren.
• Ejecución durable. Un punto de control tras cada paso, de modo que una ejecución cuyo worker se reinicia o falla continúa en otro worker desde el último paso que completó.
• Tiempos límite, cancelación y reintentos seguros para herramientas que fallan o se cuelgan. Cada llamada a una herramienta tiene un tiempo límite, una ejecución se puede cancelar y un paso que se repite tras un reinicio lleva la misma clave de idempotencia, así que no repite sus efectos secundarios.
• Una Policy dentro del ciclo. Qué herramientas puede llamar un agente y qué llamadas esperan a una persona, aplicado en cada llamada.
• Datos de uso. Tokens de entrada, tokens de salida y lo que cuestan, por ejecución y por agente, en Lens.

Esa es la parte que nadie quiere reconstruir, y es lo que Thaliq es: el ciclo, las herramientas, la memoria y las políticas, como infraestructura. El runtime no depende de un solo proveedor de modelos: habla con Anthropic, Amazon Bedrock y OpenAI, y con modelos locales mediante Ollama o vLLM. El servicio alojado ejecuta hoy Claude Haiku 4.5 en Amazon Bedrock, y también puedes ejecutar Thaliq en tu propia infraestructura.

El ciclo es simple. Hacerlo confiable es el trabajo.