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.
Esta es la página donde Cleon deja de describir qué es un agente y dice qué hacemos antes de que uno salga. Las páginas de referencia presentan las partes — qué es un agente, los patrones de orquestación, las tools y acciones. Los gotchas presentan dónde muerde cada parte. Este Style Guide es la disciplina que decide si conviene construir un agente, y la vara que tiene que pasar antes de tocar un cliente o un registro.
Las reglas son cortas a propósito. Cuando una regla necesita explicación, la explicación vive en la página que enlaza. Esta es la forma operativa de los principios de AI Engineering — cada regla de abajo es uno de esos principios con las mangas arremangadas, y citamos el número para que puedas rastrear la regla hasta su razón.
La primera decisión: agente, workflow o prompt solo
Antes que todo lo demás, contestá esto: ¿el trabajo de verdad necesita un agente? La mayoría de las cosas que se encuadran como "un agente" son un workflow con la palabra puesta encima. El test honesto es una pregunta — ¿podés enumerar el camino de antemano? Si podés dibujar el flowchart, no necesitás un agente; necesitás un workflow (mirá qué es un agente). Subí esta escalera solo hasta donde el problema te obliga, y ni un escalón más (principio 12 — arrancá del problema).
Las cuatro formas, ordenadas por quién decide el próximo paso:
- Prompt solo — no decide nadie el flujo; una llamada, una respuesta. Buscala cuando el modelo ya sabe cómo: resumir, clasificar, reescribir, extraer.
- Cadena — decidís vos; una secuencia fija de prompts. Buscala cuando la tarea tiene etapas claras que siempre corren en el mismo orden.
- Workflow — decidís vos; ramas y lógica, todas tuyas. Buscala cuando podés dibujar el flowchart, aunque sea grande y desprolijo.
- Agente — decide el modelo; el loop le pregunta qué hacer. Buscala solo cuando el camino de verdad no se puede escribir de antemano.
Cada forma hacia abajo le entrega una decisión más al modelo, comprando capacidad en problemas abiertos a costa de previsibilidad, plata y testeabilidad. Buscá un agente solo en la última — cuando el próximo paso depende de lo que devuelven los pasos anteriores de maneras que ningún chart fijo podría cubrir. Toda rama que podés nombrar es una rama que deberías hard-codear en vez de esperar que el modelo la acierte en cada corrida.
La checklist de producción: la vara que un agente pasa
Un agente que sale a producción está groundeado, evaluado, acotado, gobernado y con dueño — o es una demo que todavía no falló (principio 1). Antes de que este agente toque un cliente o un registro, confirmá cada casilla. Cada una cierra un gotcha que mató un proyecto real.
- [ ] Groundeado. Responde desde hechos recuperados, no desde el entrenamiento, y "no sé" es un camino permitido cuando el retrieval vuelve vacío. (Principio 2 · gotcha 8.)
- [ ] Evaluado. Un set de eval con casos reales y resultados conocidos corre en cada cambio antes de salir — armado con las primeras diez fallas reales, puntuando resultado y trayectoria, no un string exacto. (Principio 3 · gotcha 2.)
- [ ] Acotado. Un tope duro de pasos, un presupuesto de tokens y un timeout aplicados en código, no pedidos en el prompt. (Principio 6 · gotcha 3.)
- [ ] Tools de menor privilegio. Cada tool tiene el alcance más angosto que hace la tarea, se valida contra un schema estricto antes de ejecutar, y es idempotente donde la acción lo permite. (Principio 5 · gotchas 4–5.)
- [ ] Con gate. Toda acción irreversible — enviar, cobrar, borrar — tiene un gate de aprobación humana antes de dispararse, y un operador puede frenar un agente en corrida ahora. (Principio 5 · gotcha 6.)
- [ ] Fallback. Un fallback determinístico se dispara cuando el agente falla o devuelve algo inválido; una falla del modelo nunca se renderiza como un vacío, un string de error o una alucinación frente a alguien. (Principio 8 · gotcha 9.)
- [ ] Contexto curado. Cada paso recibe lo que necesita, no todo lo que tenés — la ventana se resume, descarta o recupera bajo demanda, no crece sin límite. (Principio 10 · gotcha 7.)
- [ ] Trazado. Cada corrida loguea sus inputs, el contexto recuperado, las tool calls y sus resultados, y la salida final, para que puedas replayearla cuando sale mal. (Principio 11.)
- [ ] Con dueño. Un humano nombrado responde por cada resultado de consecuencia — lo puede explicar, defender, y tiene los controles para actuar. (Principio 9 · gotcha 10.)
Si alguna casilla queda sin marcar, el agente no está listo — y "el agente decidió" no va a ser una respuesta aceptable cuando se equivoque. Mirá debuggear agentes para ver cómo la traza convierte una corrida fallida en un arreglo.
Componer el toolkit
El toolkit es un conjunto de instrumentos complementarios, no bandos rivales entre los que elegís. Un sistema real los compone; la habilidad es ajustar cada uno al trabajo, no jurarle lealtad a uno (principio 7).
- Agentforce cuando el trabajo vive en el modelo de seguridad de Salesforce y necesita acciones gobernadas y auditables sobre datos de clientes. La acción corre como un usuario bajo sus permisos, las sharing rules y la seguridad a nivel de campo siguen aplicando, y la plataforma registra qué corrió — mirá Agentes de Agentforce.
- LangGraph y la Claude API cuando el trabajo es off-platform, necesita un control loop a medida, o abarca modelos que Salesforce no alcanza — un graph para control determinístico sobre un paso no-determinístico, un loop de Claude para el núcleo de razonamiento. Mirá Agentes externos.
- MCP cuando querés una tool, y los datos detrás de ella, expuestos una vez y reusados por cualquier host que hable el protocolo — el tejido conectivo entre sistemas, no un tercer bando.
Una forma común es Agentforce siendo dueño de las acciones en plataforma mientras un graph externo es dueño de un paso que ella no puede, pasándose el control entre sí. La única decisión que esta página no es dueña es la decisión de superficie Agentforce vs. IA externa dentro de Marketing Cloud — eso es otro framework, y vive completo en el Style Guide de IA de Marketing Cloud.
Patrones a preferir
- La forma más chica que sirve para el trabajo — prompt solo antes que cadena, workflow antes que agente, loop único antes que un graph de agentes. El sistema más fuerte que podría funcionar suele ser el más chico. (Principio 12 · gotcha 1.)
- Un set de tools fijo y angosto antes que uno abierto — cada tool acotada en su borde, en código, no pedida que se porte bien en el prompt. (Principio 5 · gotcha 5.)
- El grounding chequeado primero cuando una respuesta está mal pero suena fluida — sospechá del retrieval antes de culpar al modelo. (Principio 2 · gotcha 8.)
- Un gate humano sobre cualquier cosa de consecuencia que el agente produce o cualquier acción irreversible que pueda tomar. (Principio 9 · gotcha 6.)
- El chequeo de agent-readiness de Data 360 pasando antes de que un agente lea datos de clientes — un modelo limpio es donde arranca un agente seguro.
- Un fallback determinístico bajo cada generación, para que el piso sea aburrido-y-correcto, nunca una respuesta equivocada y excitante. (Principio 8 · gotcha 9.)
Patrones a rechazar
- Un agente que debería ser un workflow — si podés dibujar el flowchart, el agente cuesta más, corre más lento y resiste el set de eval que necesitás. (Gotcha 1 · principio 12.)
- Una tool que puede borrar, enviar o cobrar sin gate — el menor privilegio no es opcional una vez que el agente tiene manos. (Gotcha 5 · gotcha 6 · principio 5.)
- Salir sin set de eval — "quedó bien en tres intentos" es una sensación, no un test, y la regresión sale en silencio. (Gotcha 2 · principio 3.)
- Un loop sin límite — sin tope de pasos ni presupuesto de tokens, una sola corrida trabada puede costar más que mil buenas. (Gotcha 3 · principio 6.)
- Un agente groundeado sobre un modelo fragmentado — equivocado con seguridad es peor que "no sé" porque alguien actúa sobre ello. (Gotcha 8 · principio 2.)
- "Lo hizo la IA" como respuesta a quién responde — un incidente sin dueño es cómo un error arreglable se vuelve uno organizacional. (Gotcha 10 · principio 9.)
Cierre
Ninguna de estas reglas es difícil de aplicar de entrada; todas son caras de descubrir en vivo. El hilo conductor es el que recorre cada página de esta subcategoría: la demo hace que el camino fácil parezca el camino entero, y producción es todo lo que el camino fácil dejó afuera. La vara de arriba es cómo nos aseguramos de que el agente que sacamos sea el sistema, no el truco.
Si ves que falta una regla — o que una de estas reglas se viola en nuestro trabajo público — escribí a hello@wearecleon.com. La agregamos, o lo arreglamos y lo decimos.
Related
- Gotchas de agentes — las fallas que este Style Guide está diseñado para prevenir
- Qué es un agente — la definición y el test agente-o-workflow detrás de la primera decisión
- Patrones de orquestación — las formas que toma un control loop, y qué cuesta cada una
- Tools y acciones — menor privilegio, schemas, idempotencia y gates
- Agentes de Agentforce — el agente dentro del modelo de seguridad de Salesforce
- Agentes externos — el lado de LangGraph y la Claude API, off-platform
- Debuggear agentes — trazar una corrida cuando sale mal
- Principios de AI Engineering — las meta-reglas que estos específicos operacionalizan
- Chequeo de agent-readiness de Data 360 — el lado del grounding de un agente seguro
Reference: