{"slug": "agentes-101-02-el-ciclo-del-agente-como-state-machine-y-hierarchical-state", "title": "Agentes 101 - 02: El ciclo del agente como State Machine (y Hierarchical State Machines)", "summary": "A developer explains that an LLM agent's cycle can be modeled as a finite state machine (FSM) or hierarchical state machine (HSM), with states like thinking, acting, observing, done, and error. The post argues that understanding these state machine concepts leads to clearer and more scalable agent designs, and that tools like LangGraph implement this approach cleanly.", "body_md": "En el artículo anterior definimos un agente de forma práctica:\n\nUn agente LLM es un modelo dentro de un\n\nciclodonde puede razonar, actuar, observar el resultado y decidir qué hacer después.\n\nEsa definición es correcta. Pero todavía es demasiado abstracta.\n\nHoy mucha gente está construyendo agentes con **vibe coding**. Le pide al modelo que le arme un agente, copia el código y sigue. Los modelos actuales son realmente buenos escribiendo código, y eso hace que el proceso se sienta mágico.\n\nEl problema es que muchas veces se termina implementando algo sin entender los conceptos base.\n\nY cuando no se entienden los conceptos, el modelo puede proponer soluciones más complejas de lo necesario. Por ejemplo, sugerirte una **Hierarchical State Machine** cuando una **Finite State Machine** simple habría sido más que suficiente (y capaz ni siquiera te das cuenta de que es una FSM o HSM)..\n\nPor eso este artículo.\n\nNo para complicar las cosas, sino para tener claridad sobre qué estamos construyendo realmente.\n\nLa pregunta central es:\n\n**¿Cómo modelamos el ciclo de un agente de forma explícita, controlable y escalable?**\n\nLa respuesta es: tratarlo como una **máquina de estados**.\n\nImaginemos el flujo más simple de un agente:\n\nEse flujo se puede modelar perfectamente como una **Finite State Machine (FSM)**:\n\n| Estado | Descripción |\n|---|---|\n`'thinking'` |\nEl modelo está razonando |\n`'acting'` |\nEstá ejecutando una herramienta |\n`'observing'` |\nEstá procesando el resultado |\n`'done'` |\nTerminó la tarea |\n`'error'` |\nAlgo falló |\n\nLas transiciones dependen del resultado de cada paso.\n\nEso es exactamente lo que hace un agente.\n\nAquí un ejemplo conceptual (pseudo-código):\n\n```\nstate = {\n    \"task\": \"Implementar CORS en API Gateway con CDK\",\n    \"code\": \"\",\n    \"last_observation\": None,\n    \"status\": \"thinking\"\n}\n\nwhile state[\"status\"] not in [\"done\", \"error\"]:\n    if state[\"status\"] == \"thinking\":\n        decision = llm.think(state)\n        if decision.needs_tool:\n            state[\"status\"] = \"acting\"\n            state[\"next_tool\"] = decision.tool\n        else:\n            state[\"status\"] = \"done\"\n            state[\"final_answer\"] = decision.answer\n\n    elif state[\"status\"] == \"acting\":\n        result = run_tool(state[\"next_tool\"], state)\n        state[\"last_observation\"] = result\n        state[\"status\"] = \"observing\"\n\n    elif state[\"status\"] == \"observing\":\n        # El modelo decide qué hacer con la observación\n        next_action = llm.observe(state)\n        state[\"status\"] = next_action  # puede ser \"thinking\", \"done\", \"error\"...\n```\n\nEste patrón es el corazón de casi todos los frameworks de agentes.\n\nLa diferencia está en qué tan explícito se hace el control del estado.\n\nLas herramientas no son un \"extra\".\n\nSon acciones que producen una observación y, por lo tanto, cambian el estado de la máquina.\n\nCuando el agente llama a `search_docs`\n\no `run_tests`\n\n, lo que realmente está haciendo es:\n\n`thinking`\n\n`acting`\n\nSi pensamos las tools de esta forma, el diseño se vuelve mucho más claro:\n\nUna FSM plana funciona bien para agentes simples.\n\nPero cuando el agente crece, empiezan a aparecer problemas:\n\nAquí es donde aparecen las **Hierarchical State Machines (HSM)**.\n\nLa idea es simple: **un estado puede contener otra máquina de estados completa.**\n\nEjemplo:\n\n```\nresolver_tarea (estado de alto nivel)\n├── investigar\n│   ├── buscar_documentación\n│   ├── analizar_código_existente\n│   └── sintetizar_hallazgos\n├── implementar\n│   ├── escribir_código\n│   └── correr_tests\n│   └── corregir_errores\n└── validar\n    ├── revisar_calidad\n    └── generar_respuesta_final\n```\n\nCada sub-máquina tiene su propio estado interno, pero el padre solo ve el resultado agregado.\n\nEsto es exactamente cómo trabaja un desarrollador humano experimentado: no piensa en cada detalle al mismo tiempo. Entra en \"modo investigación\", luego en \"modo implementación\", etc.\n\nLangGraph es, en la práctica, una de las implementaciones más limpias de este enfoque.\n\n``` python\nfrom typing import TypedDict\nfrom langgraph.graph import StateGraph, START, END\n\nclass AgentState(TypedDict):\n    task: str\n    messages: list\n    code: str\n    status: str\n\nbuilder = StateGraph(AgentState)\n```\n\nLangGraph permite meter un grafo completo como nodo de otro grafo.\n\nEso es literalmente una Hierarchical State Machine.\n\nHay dos patrones principales:\n\nEl subgraph y el parent comparten claves del estado.\n\n```\n# El subgraph se agrega directamente como nodo\nbuilder.add_node(\"investigar\", investigar_subgraph)\n```\n\nCada subgraph tiene su propio schema y se hace una transformación explícita.\n\n``` python\ndef call_investigar(state: AgentState):\n    subgraph_input = {\"query\": state[\"task\"]}\n    result = investigar_subgraph.invoke(subgraph_input)\n    return {\"code\": result[\"findings\"]}\n```\n\nAdemás, LangGraph gestiona checkpoint namespaces por subgraph, lo que permite:\n\nEsto es extremadamente poderoso cuando pasamos de demos a sistemas reales.\n\n| Situación | Recomendación |\n|---|---|\nPrototipo/demo rápida |\nLoop simple suele alcanzar |\nAgente con pocas tools |\nFSM plana |\nAgente con modos claros |\nHSM (subgraphs) |\nMulti-agente / equipos |\nHSM + supervisor |\nProducción con observabilidad |\nState machine explícita |\n\nNo hay que formalizar todo desde el día uno.\n\nPero cuando el flujo empieza a volverse difícil de seguir, convertir el ciclo en una máquina de estados (y eventualmente jerárquica) suele ser el siguiente paso natural.\n\nY aquí vuelve el punto del principio: si no tenés claros estos conceptos, es fácil que el modelo te proponga una HSM cuando en realidad necesitabas una FSM simple. O al revés.\n\nEl ciclo **Think Act Observe** no es solo una metáfora.\n\nEs una máquina de estados.\n\nLas **Hierarchical State Machines** nos permiten escalar esa idea sin que el sistema se convierta en un laberinto de `if`\n\ns y prompts.\n\nY frameworks como LangGraph nos dan las primitivas exactas para implementarlo de forma limpia: `StateGraph`\n\n+ `Subgraphs`\n\n.\n\nResumen:\n\nUn agente no es solo un modelo con tools.\n\nEs un modelo operando dentro de una máquina de estados (que puede ser jerárquica).\n\nEntender esto cambia bastante la forma en que diseñamos, debuggeamos y operamos agentes.", "url": "https://wpnews.pro/news/agentes-101-02-el-ciclo-del-agente-como-state-machine-y-hierarchical-state", "canonical_source": "https://dev.to/xvierd/agentes-101-02-el-ciclo-del-agente-como-state-machine-y-hierarchical-state-machines-5986", "published_at": "2026-07-26 15:09:16+00:00", "updated_at": "2026-07-26 15:29:20.958988+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-agents", "developer-tools"], "entities": ["LangGraph"], "alternates": {"html": "https://wpnews.pro/news/agentes-101-02-el-ciclo-del-agente-como-state-machine-y-hierarchical-state", "markdown": "https://wpnews.pro/news/agentes-101-02-el-ciclo-del-agente-como-state-machine-y-hierarchical-state.md", "text": "https://wpnews.pro/news/agentes-101-02-el-ciclo-del-agente-como-state-machine-y-hierarchical-state.txt", "jsonld": "https://wpnews.pro/news/agentes-101-02-el-ciclo-del-agente-como-state-machine-y-hierarchical-state.jsonld"}}