AI ENGINEERING / AGENTES Y ORQUESTACIÓN
Agentes y orquestación
Construir agentes que se implementan, no que demuestran: anatomía, patrones de orquestación (del single-loop a los grafos de LangGraph), tools y actions, y la disciplina de producción — componiendo Agentforce, LangGraph, Claude y MCP.
Fundamento · 2
Nota de producción
Gotchas de agentes: cómo se muere una demo en producción
La demo de un agente de IA es un truco de magia: inputs guionados, un camino amable, una audiencia que quiere creer. Un agente en producción es un problema de ingeniería — confiable con inputs que nadie escribió, acotado en costo, gobernado en cada acción, con un humano que responde cuando se equivoca. Diez gotchas que matan agentes después de la demo, cada uno con la pregunta que tenés que contestar primero y el costo de equivocarte.
Marco de decisión
Style Guide de agentes: la vara que un agente pasa antes de salir
Las reglas con opinión que Cleon aplica a cada agente — la primera decisión (agente, workflow o prompt solo), la checklist de producción que un agente pasa antes de salir, y cómo componemos Agentforce, LangGraph, Claude y MCP según el trabajo en vez de elegir un bando. El documento de disciplina que convierte los gotchas en una vara y los principios en práctica.
Referencia · 5
Referencia
¿Qué es un agente? La anatomía de un sistema que decide
Qué es realmente un agente, parte por parte: un modelo, instrucciones, tools, memoria y un control loop que corre percibir → razonar → actuar → observar. En qué se diferencia un agente de un workflow, una chain y un solo prompt — no como rivales, sino como formas distintas para trabajos distintos — y el test honesto para saber cuándo necesitás un agente: solo cuando el camino no se puede enumerar de antemano. Establece el vocabulario que usa el resto de esta subcategoría.
Referencia
Patrones de orquestación: de un solo loop a un grafo
Los patrones de orquestación de agentes que de verdad aguantan en producción — el loop ReAct de un solo agente, supervisor/worker, colaboración multi-agente, máquinas de estado basadas en grafos, y routing/handoff — cada uno con dónde encaja y su trade-off de costo, latencia y confiabilidad. Más la advertencia honesta de que cada agente que sumás es superficie de falla que ahora te pertenece, y dónde se ubica el Atlas Reasoning Engine de Agentforce como el instrumento de razonamiento gestionado.
Referencia
Tools y actions: darle a un agente la capacidad de actuar
Cómo actúa un agente: tool (function) calling, donde el nombre de la tool, la descripción y el schema tipado son la interfaz sobre la que razona el modelo. Diseñar tools seguras — least privilege, validación de argumentos, idempotencia, y un gate de aprobación más kill switch en las acciones con consecuencias. Agentforce Actions (Flow, Apex, Prompt Template) dentro del modelo de seguridad de la plataforma, y MCP como el protocolo abierto para conectar modelos con tools entre sistemas. Compuestos, no rankeados.
Referencia
Agentes de Agentforce: el camino nativo de la plataforma
El camino nativo de Salesforce como un instrumento del kit — el correcto cuando el trabajo vive en el modelo de seguridad y necesita acciones gobernadas y auditables sobre datos del cliente (principio 7). Cómo se arma un agente de Agentforce: Topics que acotan los trabajos, Instructions que guían el comportamiento, el Atlas Reasoning Engine gestionado que planifica sobre ellos, Actions que actúan, grounding vía Data 360, y el Einstein Trust Layer haciendo la gobernanza. Qué tenés vos y qué tiene la plataforma — y dónde el trabajo le pasa la posta a un agente externo.
Referencia
Agentes externos: LangGraph, Claude y el loop que controlás vos
El camino fuera de la plataforma como un instrumento componible — LangGraph para la orquestación, la Claude API como núcleo de razonamiento, MCP para interoperar tools — y lo que lo define: cuando salís afuera, sos dueño del control loop, del estado, del grounding, del modelo de seguridad, de la gobernanza y de la auditoría que Agentforce te da gratis. La decisión correcta cuando el trabajo está fuera de la plataforma, cruza modelos o necesita una capacidad que Salesforce no alcanza — y complementaria al camino de la plataforma, no rival de él.