Planning
Planning es la práctica mediante la cual un agente representa y revisa un curso de acción previsto para alcanzar un objetivo bajo restricciones. Puede descomponer trabajo, ordenar dependencias, proponer resultados intermedios y decidir dónde obtener evidencia antes de continuar. La definición de trabajo del Atlas se refiere a organización de acciones futuras; no exige una arquitectura particular ni presupone que toda tarea necesite un plan explícito.
Un plan resulta útil cuando permite coordinar decisiones o recuperar continuidad. Para una consulta sencilla, producirlo puede costar más que resolverla directamente. Para un cambio con dependencias, puede revelar que falta una decisión o que un paso modifica recursos antes de reunir evidencia suficiente. Su calidad depende de esas relaciones y de su vigencia, no de longitud, formato o cantidad de casillas.
Planning y razonamiento
Planificar organiza lo que se pretende hacer. El razonamiento puede contribuir a esa selección, pero no se identifica con el plan ni necesita exponerse como razonamiento privado del modelo. Un listado de tareas, un grafo de ejecución o una secuencia de hitos pueden comunicar intención y restricciones sin registrar private chain-of-thought.
El lector necesita comprender decisiones operativas relevantes: qué resultado se busca, qué depende de qué y cuándo se reconsiderará una acción. No necesita una transcripción interna de cómo el modelo produjo cada alternativa. A la inversa, una explicación extensa de posibilidades no constituye un plan útil si no permite identificar el próximo trabajo y las condiciones que lo habilitan.
Esta frontera también limita lo que puede inferirse observando un agente. Tener un artefacto escrito demuestra que se externalizó cierta intención; no prueba que el sistema lo siguió ni que todas sus decisiones estuvieron representadas allí. La evidencia de ejecución pertenece a acciones, resultados y registros observables.
Plan Artifacts
Planning es proceso o capacidad; un plan artifact es una representación externalizada de trabajo previsto. Puede ser texto breve, checklist, estructura de datos, estados y transiciones o grafo de dependencias. El formato depende del consumidor y la tarea. No existe una estructura universal que convierta un documento en planificación correcta.
Un artefacto puede ayudar al usuario a revisar alcance, al runtime a conservar progreso o a otro participante a continuar. Esas funciones pueden requerir distinto detalle. Una checklist comprensible para una persona no es automáticamente un programa ejecutable; un grafo consumido por un orquestador puede omitir razones que importan a un revisor humano. Interesa conocer qué representa y qué queda fuera.
El plan puede persistir en archivos o estado de ejecución, pero su almacenamiento no le concede autoridad adicional. Una frase que propone publicar después de implementar no autoriza esa publicación. Tampoco debería convertirse en nueva fuente de requisitos que compite con el encargo vigente. Las restricciones de la tarea continúan delimitando las acciones propuestas.
Plan Artifacts and Task State
Task state describe la condición actual del trabajo: pendiente, activo, bloqueado, completado o fallido, con el significado que use la implementación. El plan describe el curso previsto. Un paso puede estar activo aunque el plan no haya cambiado; el plan puede revisarse antes de que se ejecute otra acción. Ambos se relacionan sin ser sinónimos.
Marcar un paso como completo debe referirse a un resultado identificable. “Investigar el error” puede terminar con una causa candidata y una incertidumbre relevante, mientras “aplicar la corrección” puede quedar pendiente. Si una misma marca representa edición, ejecución de tests y aceptación, el estado deja de informar qué ocurrió realmente.
La representación de estado no tiene que exponerse íntegramente al modelo. Agent Harness puede mantener solicitudes pendientes y resultados que después incorpora al contexto. La etiqueta visible en una lista no demuestra que exista un proceso activo, ni reemplaza el estado efectivo de las herramientas. Esa diferencia importa al retomar trabajo interrumpido.
Un bloqueo puede afectar solo una parte del plan. Si otra actividad autorizada no depende de la decisión pendiente, el agente puede avanzar allí y conservar visible la dependencia. Marcar toda la tarea como detenida perdería esa posibilidad; ignorar el bloqueo tampoco lo resuelve.
Objetivo, especificación y plan
El objetivo expresa el resultado buscado. Una especificación conserva expectativas de comportamiento o restricciones. El plan propone acciones para acercarse a ese resultado. “Modificar validación, ejecutar tests y revisar consumidores” no decide qué entradas deben aceptarse; esa expectativa necesita una referencia apropiada.
Specification-Assisted Development desarrolla esta frontera para cambios de software. Planning tiene un alcance general de agentes y no convierte toda tarea en una metodología Spec → Plan → Implement. Puede utilizar un contrato existente, partir de un pedido suficientemente claro o incluir una investigación para determinar qué decisión falta antes de modificar algo.
Cuando el agente encuentra una incompatibilidad entre objetivo y restricciones, reorganizar pasos no la resuelve. Puede presentar alternativas y explicar sus consecuencias. No debería redefinir el resultado para que coincida con lo que le resulta más fácil ejecutar. Las decisiones sobre expectativas conservan su autoridad aunque estén resumidas en un plan.
Descomposición y dependencias
Descomponer ayuda a distinguir resultados parciales con significado. Un paso demasiado amplio oculta riesgos; una lista que nombra cada edición trivial puede producir seguimiento sin comprensión. La granularidad útil permite decidir qué información hace falta, qué puede ejecutarse independientemente y qué condición habilita el paso siguiente.
Las dependencias pueden ser de información, recursos o autoridad. Conocer el contrato antes de cambiar consumidores es una dependencia informativa. Disponer de un entorno de prueba es una condición de recursos. Contar con autorización para una acción externa es una frontera distinta. Tratarlas como casillas intercambiables puede llevar a ejecutar una acción porque sus prerrequisitos técnicos están listos aunque falte la condición que realmente la limita.
El plan también puede reconocer actividades independientes sin ejecutarlas en paralelo. Puede ser más simple realizarlas secuencialmente o mantener un único agente. La existencia de varias ramas posibles no exige Parallel Agent Execution ni un sistema de coordinación adicional.
Planificación ante información incompleta
Un agente suele planificar con conocimiento parcial. Puede declarar supuestos y elegir un próximo experimento que reduzca incertidumbre antes de comprometer una solución. Un paso de exploración puede ser más valioso que detallar una implementación basada en un contrato todavía desconocido. La precisión del formato no compensa una premisa inválida.
Conviene diferenciar pasos decididos de alternativas condicionadas. “Si el formato admite ausencia, conservar el valor; si no, revisar la transición” comunica una bifurcación pendiente. Presentar ambas ramas como trabajo obligatorio aumenta scope y puede ocultar que falta una decisión. Tampoco interesa enumerar todas las eventualidades imaginables para parecer exhaustivo.
Agent Memory puede aportar antecedentes y Tool Calling obtener observaciones nuevas. La información recuperada debe contrastarse cuando su frescura o autoridad importan. Que el agente recuerde una solución anterior no demuestra que siga siendo pertinente para la revisión actual.
Replanning y feedback
Replanning revisa el curso previsto a partir de nueva evidencia o condiciones. Puede cambiar orden, granularidad, herramienta o alternativa. No implica necesariamente que el plan anterior fuera defectuoso: quizá una exploración legítima descubrió una dependencia que todavía no podía conocerse. La revisión debe explicar qué hecho cambió la decisión relevante.
Una comprobación que falla puede requerir investigar antes de continuar. Mantener todos los pasos originales por fidelidad al artefacto puede ejecutar trabajo ya innecesario. Cambiar el objetivo sin hacerlo visible es otro problema. Un replanning responsable conserva la relación entre intención, restricciones y resultados obtenidos.
El feedback puede ser de herramientas, personas o resultados externos. No todo comentario requiere rehacer el plan entero. Interesa actualizar la parte afectada y preservar lo que continúa siendo válido. Esto permite continuidad sin tratar cada observación como un reinicio ni cada plan aprobado como una secuencia inmutable.
Planning y Planner–Executor
Agentic Workflow Patterns incluye Planner–Executor como patrón que separa responsabilidades de planificar y realizar. Planning es la actividad general que ese patrón puede utilizar. Un mismo agente puede proponer, ejecutar y revisar su curso de acción sin tener dos componentes independientes.
Separar planner y executor puede facilitar especialización o control, pero introduce interfaces y coordinación. No demuestra que el plan sea correcto ni que el executor tenga contexto suficiente. También pueden participar reglas o personas. La elección depende del problema, no de una supuesta necesidad de convertir cualquier plan en una arquitectura de dos agentes.
Orchestrator–Workers tampoco es otro nombre de Planning. Enfatiza distribuir y reunir trabajo, que puede apoyarse en un plan. Un curso de acción puede existir sin delegación, y una delegación acotada puede ocurrir sin un plan extenso. Conservar esas fronteras evita promover un mecanismo útil a requisito universal.
Puntos de comprobación y terminación
Un plan puede incluir momentos para obtener evidencia, revisar alcance o decidir si continuar. Esos puntos orientan trabajo futuro; no son la evidencia misma. Un ítem que dice “validación completa” puede estar pendiente, ejecutarse sobre otra revisión o resultar insuficiente para la expectativa concreta.
Generated Code Verification utiliza resultados pertinentes para juzgar un cambio de software. Completar todos los pasos del plan no sustituye ese juicio. El agente puede haber seguido un plan que omitía una restricción o ejecutado correctamente herramientas que no respondían la pregunta importante.
Los stop conditions pueden incluir objetivo satisfecho, falta de autoridad, información decisiva ausente o límites de ejecución. Agents conserva el loop y la decisión de continuar o detenerse. Terminar una lista no debería ocultar que la ejecución se detuvo por otro motivo, ni prolongar el trabajo cuando el resultado acordado ya está suficientemente respaldado.
Ejemplo: investigar antes de modificar
Un agente recibe el encargo de corregir una importación que rechaza pedidos válidos. Puede proponer reproducir el caso, localizar la regla y revisar consumidores antes de editar. Si descubre que la importación usa fecha efectiva y otro canal usa fecha actual, el próximo paso cambia: hace falta determinar la semántica acordada, no eliminar inmediatamente la diferencia.
El artefacto puede registrar esa pregunta y mantener pendiente la corrección. Cuando el contrato se aclara, el agente ajusta los pasos y elige comprobaciones para ambos recorridos. El estado de la investigación avanzó aunque todavía no haya una edición. Un resumen que marque simplemente “validación arreglada” perdería esa diferencia.
Si la tarea es mucho más pequeña, como corregir una referencia conocida, quizá no haga falta un plan escrito. La misma disciplina de respetar alcance y comprobar el resultado puede aplicarse sin producir otro documento. Planning es útil cuando organiza decisiones reales, no cuando agrega una ceremonia a cualquier acción.
Continuidad y límites
Un plan puede ayudar en un handoff, pero el receptor necesita además estado actual y evidencia. Agent Handoffs transfiere responsabilidad o control; copiar una lista no garantiza esa transferencia. Agent Checkpoints and Recovery conserva estado restorable, que tampoco se reduce a la intención escrita en el plan.
Los Development Context and Execution Records pueden relacionar pasos previstos con acciones y resultados reales. Deben conservar fallos e incertidumbre cuando afecten la continuación. La utilidad del registro no depende de exponer razonamiento privado ni de narrar cada decisión menor del agente.
Planning aporta una representación revisable para actuar con propósito. No garantiza comprensión, autorización o corrección, ni exige memoria persistente, subagentes o un framework de ejecución. Su criterio de éxito es ayudar a elegir y revisar acciones pertinentes bajo las restricciones reales de la tarea.