Nueve prácticas operativas para que su equipo de agentes no se convierta en la escoba del aprendiz de hechicero.
En 1797 Goethe publicó una balada corta llamada Der Zauberlehrling, el aprendiz de hechicero. El maestro se ausenta. El aprendiz no quiere cargar cubetas de agua, así que le enseña a una escoba a hacerlo por él. La escoba obedece. La escoba obedece demasiado bien. El taller termina inundado. En 2026, la industria de agentes de IA vive esa misma escena todos los días, en distintas oficinas y con distintas marcas de escoba.
Este texto no es una crítica de los modelos. Los modelos de hoy son perfectamente capaces. Es una descripción honesta de las nueve prácticas que hemos adoptado en Centrum Transgenia para operar un equipo de doce agentes internos, sin apagarlo cada semana, sin inundar el taller.
Un aviso antes de empezar. En este texto no verá cifras redondeadas de facturación, ni porcentajes de ROI, ni nombres de clientes. La razón está en la práctica número ocho: cero fabricación. Solo mecanismos verificables.
El problema. Escobas que obedecen demasiado bien
Los equipos de agentes fallan al pasar de la demo a la operación por razones que se repiten en cada industria. No fallan por debilidad del modelo. Fallan por exceso de capacidad sin gobierno.
Un catálogo breve, sobrio, sin adornos:
- La autonomía sin trazabilidad. Un agente ejecuta una acción; nadie puede reconstruir por qué.
- La alucinación confiada. El modelo produce un dato inexistente con la misma cadencia con la que produce uno correcto.
- La memoria muda. Cada sesión empieza de cero. La lección del martes se pierde el jueves.
- La gobernanza frágil. Las reglas viven en el prompt; la próxima regeneración las borra.
- El costo opaco. Nadie sabe cuál agente consumió cuánto. La factura llega a fin de mes.
- La identidad prestada. Dos agentes hablan como uno; la telemetría no distingue.
- La herramienta heredada por accidente. Un agente adquiere permisos que no le tocan.
- La escritura sin frontera. No hay diferencia estructural entre proponer y ejecutar.
Cualquier decisor con una demo funcionando en la mano puede saltarse este catálogo. Cualquier decisor con dos meses de operación real lo lee con paciencia, porque reconoce las escenas.
La tesis. Una tarjeta que cabe en el bolsillo
Después de doce meses de operación, la tesis se resume en cuatro verbos con sujetos obligatorios:
La IA propone. El humano aprueba. El sistema registra. La empresa aprende.
No es una recomendación. Es una jerarquía. Cada verbo tiene un sujeto propio y no se intercambian.
Un agente puede producir un borrador de correo, una póliza contable, un pitch de prensa, un artículo entero. No puede enviar el correo, contabilizar la póliza, mandar el pitch, ni publicar el artículo sin una frase de aprobación humana con formato exacto. El sistema, entretanto, guarda el borrador, el prompt, la fuente, el modelo, el timestamp y la firma. La empresa cierra el ciclo consultando ese registro cuando aparece la siguiente decisión análoga.
La palabra en la que se resume todo es draft-first. Todo agente entrega primero un borrador. Ningún agente publica sin permiso. Cuesta fricción; paga en operación auditable.
Nueve prácticas que no son comunes en la industria
Las presento con la misma estructura para todas: qué es, por qué no es común, cómo replicarla en su equipo. Ninguna depende de nuestro stack; todas se pueden montar sobre proyectos abiertos.
1. Gobierno en la frontera de escritura, no en la capacidad
Qué es. No limitamos lo que el agente puede leer. Limitamos lo que puede escribir. Un agente puede consultar el ERP, el correo, los CFDIs, los dashboards, incluso conversar con otros agentes. Ningún agente puede modificar un registro operativo, enviar un correo, cancelar una factura o publicar un artículo sin cruzar un candado triple: flag de entorno, confirmación en runtime, frase de aprobación humana con formato fijo.
Por qué no es común. La demo se ve mejor cuanto más autonomía muestra. Un candado de escritura reduce el número de tareas que un agente cierra sin intervención, y eso se lee como debilidad en un pitch de plataforma. En operación es la diferencia entre confiarle el CRM o no.
Cómo replicarla. Divida sus tools en dos listas explícitas, read_tools y write_tools. Publique la segunda solo con WRITES_ENABLED=true. Registre cada intento fallido; sirven para descubrir modos de falla nuevos.
2. Tiers de confianza multi-vendor
Qué es. Ninguna decisión operativa depende de un solo proveedor de modelo. Distribuimos el trabajo entre varios según el nivel de confianza que la tarea exige. La mnemónica interna es cariñosa: Mistral propone, OpenAI produce, Claude dispone. Un modelo económico redacta, uno intermedio refina, uno de mayor razonamiento revisa.
Por qué no es común. El lock-in es cómodo. Un solo SDK, un solo panel de facturación, un solo contrato. La cuenta llega cuando cambia el precio, cambia la política de uso o cae la región.
Cómo replicarla. Defina tres tiers en su router (draft, refine, dispose) y asigne cada tarea según reversibilidad y costo. Documente las allowlists por tier en un archivo versionado. Reevalúe cada trimestre.
3. Observabilidad por diseño
Qué es. No hay ejecución que no deje traza. Prometheus para métricas, Grafana para paneles, Langfuse para trazas y sesiones, OpenTelemetry como capa de emisión unificada. Encima, un panel propio que hace legible la delegación entre agentes: quién llamó a quién, con qué skill, qué droid activó, qué memoria consultó, cuándo cerró la sesión.
Si no se ve, no se confía.
Por qué no es común. El instrumentado inicial se percibe como costo antes de que dé valor. La deuda técnica de observabilidad crece silenciosa hasta que un incidente la vuelve visible; para entonces es estructural.
Cómo replicarla. Emita service.name, gen_ai.agent.name, gen_ai.model, gen_ai.tokens.input, gen_ai.tokens.output, gen_ai.tool.name en cada inferencia. Construya el panel de delegación desde el primer día.
4. Auditoría como contrato, revisión adversarial entre agentes
Qué es. Cada intervención cierra con una carpeta con fecha ISO y un fix_log.md: fuentes, decisión, estado antes y después, firma humana. Encima, un segundo agente, de rol distinto, ejecuta una revisión adversarial y publica su security_review.md junto al fix_log.
Sin audit, no entregado.
Por qué no es común. En un modelo de producción centrado en velocidad, la revisión entre agentes se percibe como cuello de botella. En un modelo centrado en confianza es la única manera de detectar patrones de error sistemáticos.
Cómo replicarla. Convención de carpetas audit/<YYYY-MM-DD>/<slug>/. Fix_log obligatorio. Segundo agente revisor con rol distinto al primero.
5. Guardrails durables que sobreviven al auto-heal
Qué es. Las reglas críticas viven fuera del bloque regenerable. Cargamos el core desde archivos versionados (BRAIN.md, CLAUDE.md local por agente) que un heal periódico re-aplica sobre los doce agentes.
Por qué no es común. Los equipos que operan con GUIs de configuración confunden el estado visible con el estado durable. La primera regeneración borra las reglas y descubren, tarde, que necesitan una fuente de verdad fuera del contenedor del vendor.
Cómo replicarla. Identifique reglas que no pueden perderse jamás, muévalas a archivos versionados fuera del vendor, escriba un script de reconciliación diaria.
6. Fase read-first y "naturaleza" declarada por ejercicio
Qué es. Toda capacidad nace en solo-lectura. La inteligencia comercial nació leyendo CRM. La inteligencia de PR nació leyendo canales autorizados. La escritura se habilita después, cuando el lector demostró estabilidad. Además, cada tarea declara su "naturaleza" antes de tocar nada: audit-only, protected-state-safe, remediation-with-VoBo, content-drafting-no-publish.
Por qué no es común. La presión comercial empuja a mostrar valor lo antes posible. La fase de solo-lectura no produce entregables visibles. Los equipos que se la saltan descubren, tarde, que dieron permisos de escritura antes de conocer los modos de falla.
Cómo replicarla. Default READ_ONLY=true para toda capacidad nueva. Dos semanas mínimas de operación lectora antes de habilitar cualquier write. Taxonomía cerrada de naturalezas de ejercicio.
7. Identidad aislada por agente
Qué es. Cada agente con su projectPath propio, su CLAUDE.md local, su service.name distinto, su slug único en memoria. El core operativo se comparte por hardlinks o junctions, no por copia. Resuelve tres problemas de un golpe: colisión de persona, atribución de telemetría, contaminación de memoria.
Por qué no es común. Las plataformas SaaS optimizan para "un solo panel" y tratan al equipo como una lista dentro de un contenedor. La telemetría y la memoria terminan atribuidas a un identificador colectivo.
Cómo replicarla. Carpeta raíz por agente. CLAUDE.md local que declare nombre, rol, gates y voz. OTEL_SERVICE_NAME con patrón equipo-<slug>. Core operativo compartido por hardlink.
8. Anti-fabricación de primera clase con jerarquía de fuentes
Qué es. Si el agente no puede verificar un dato, lo declara desconocido. Nada de aproximaciones, nada de cifras redondeadas que suenan creíbles. Además, cada dominio tiene su jerarquía de fuentes de verdad, cerrada y escrita:
- En SEO, Google es autoridad primaria (Search Console, URL Inspection). Otras herramientas son apoyo.
- En contable, el orden es SAT (l10n_mx_edi_cfdi_sat_state), bóveda CFDI, estado de cuenta bancario, registro Odoo.
Por qué no es común. Los modelos generativos, por diseño, prefieren completar un texto plausible antes que dejar un hueco visible. Sostener la política exige repetirla en cada system prompt y aceptar entregables incompletos como preferibles a entregables inventados.
Cómo replicarla. Escriba la política literal en el system prompt: "si no se verifica, se declara desconocido". Publique la jerarquía de fuentes por dominio. Trate una cifra inventada como incidente grave.
9. Pool de capacidades compartido, herencia por diseño
Qué es. Cada capacidad se desarrolla una vez, en dos formatos: una skill (documenta y opera) y un droid (ejecuta con contexto propio). Ambos viven en un pool único que todo agente puede invocar. Tres droids compositivos (session-guard, vobo-gate, audit-logger) se activan como preflight y post-flight de toda ejecución sensible.
Escribe una vez, todos los agentes heredan.
Por qué no es común. La mayoría de las plataformas obliga a duplicar la capacidad en cada agente. Cada duplicación es una divergencia futura.
Cómo replicarla. Un directorio único de capacidades. Hardlinks o junctions a cada agente. Guardrails compositivos activados por convención en toda ejecución que toque un sistema externo.
Playbook, ocho pasos para el equipo que empieza mañana
- Declare los oficios. Prohíba el "propósito general".
- Divida las tools por rol y por lectura/escritura.
- Instrumente con OpenTelemetry desde el día uno.
- Escriba la política anti-fabricación con jerarquía de fuentes.
- Establezca el gate de aprobación con frase exacta.
- Cree la convención de auditoría con carpeta por fecha y revisión adversarial.
- Mueva los guardrails fuera del blob de config del vendor.
- Introduzca un router multi-vendor con tiers.
Cada paso se puede montar sobre proyectos abiertos: Prometheus, Grafana OSS, Langfuse, OpenTelemetry, Qdrant, MCP. No hace falta firmar un contrato de plataforma cerrada para empezar.
Del aprendiz al maestro
En la balada de Goethe el aprendiz solo se salva cuando el maestro regresa. El maestro no llega gritando; llega con una frase corta que rompe el hechizo. Después ordena. Después registra. Después enseña, para que la escoba no vuelva a inundar el taller.
En Centrum Transgenia decidimos que ese maestro no es un mago. Es un protocolo. La frase corta es un gate de aprobación. El orden es un fix_log. El registro es una carpeta con fecha. La enseñanza es un BRAIN.md.
Nadie llega de emergencia. Nada se inunda. La escoba trabaja. El aprendiz aprende. El taller sigue abierto al día siguiente.
Si su empresa está considerando montar un equipo de agentes, o ya lo tiene y descubre que la escoba se le desbordó, escríbanos. La conversación empieza en [email protected]. Nosotros traemos el protocolo. Ustedes traen el taller.
El whitepaper completo (anexos, glosario, jerarquía de fuentes por dominio y licencia CC BY-SA) está disponible a solicitud escribiendo a [email protected].