Un equipo de diez.
Que cabe en una computadora.

01 . Quién puede parar a quién

La velocidad se controla con frenos,
no con buenas intenciones.

Un sistema de IA produce rápido y también se equivoca con mucha seguridad. Por eso el orden de mando corre en sentido contrario al del apuro: Legal y Seguridad detienen al Product Manager, nunca al revés.

02 . El equipo

Cada uno hace una cosa,
y la hace siempre igual.

Las reglas de cada agente están escritas. Aquí van las que más cambian el resultado.

• Cooper Veto L3
  Product Manager · Orquestador

  Define la estrategia y reparte el trabajo entre los demás. Nunca programa: si escribiera código, sería juez y parte de su propia entrega.

  Regla dura: no puede interpretar ni resumir un dictamen de Kernel o Arthur. Lo transmite tal cual o no lo transmite.

• Arthur Veto L1
  Legal & Compliance

  Privacidad, ley fintech y NOM-151. Revisa que ningún dato personal acabe donde no debe.

  Regla dura: audita los filtros de datos antes de que nada entre a la base vectorial.

• Kernel Veto L1
  DevOps & Security

  Custodia el repositorio y los despliegues. Rechaza cualquier comando que salga del área de trabajo.

  Regla dura: único autorizado a publicar, y sólo después de que yo lo apruebe.

• Sia Veto L2
  SaaS Economics

  Costos, precios y márgenes. Frena lo que técnicamente funciona pero no se sostiene con números.

  Regla dura: toda función nueva llega con su costo de operación estimado.

• George Ejecuta
  Senior Developer

  Escribe el código. Prefiere la solución simple que resuelve el problema real por encima de la elegante que no lo resuelve.

  Regla dura: nada se propone para publicar sin que compile y pase las pruebas de sintaxis.

• Chino Ejecuta
  UX / UI

  El sistema de diseño y el detalle fino: espaciado, tipografía, cómo se siente al tocarlo.

  Regla dura: cero placeholders. Ni cajas grises ni textos de relleno en nada que yo vaya a ver.

• Orlando Ejecuta
  QA Senior

  Prueba antes de que algo se llame terminado, en pantallas reales de escritorio, tableta y celular.

  Regla dura: si un efecto hace saltar el contenido al cargar, se veta.

• Ada Ejecuta
  Data & IA

  Arquitecta de la memoria: qué se guarda, cómo se busca y cómo el sistema recuerda decisiones viejas.

  Regla dura: el texto se limpia antes de convertirse en vector, nunca después.

• Vera Ejecuta
  UX Writer

  Los textos de producto. Traduce jerga técnica al idioma de quien va a usar la herramienta.

  Regla dura: ninguna pantalla dice «error inesperado» y se queda tan tranquila.

• Pia Ejecuta
  Marketing Digital

  Cómo se cuenta el producto hacia afuera: mensajes, campañas y qué se mide de ellas.

  Regla dura: no valida su propio trabajo. Eso le toca a Orlando.

03 . Arquitectura

El que construye
no es el que revisa.

Dos modelos distintos y una memoria compartida, corriendo en mi Mac. La separación no es un capricho técnico: un modelo que revisa su propio trabajo tiende a aprobarlo.

04 . Frenos que no dependen del modelo

Una regla escrita
no frena a nadie.

Pedirle a un modelo que se contenga funciona hasta que la conversación crece. Lo aprendí con reglas que se rompían teniéndolas enfrente. Por eso los frenos que importan ya no viven en las instrucciones: viven en código que corre fuera del modelo, antes o después de cada acción.

• Antes de cada acción El Product Manager no puede programar.

  Si Cooper intenta editar un archivo o ejecutar algo que cambie el proyecto, un hook lo bloquea antes de que la herramienta corra. Delegar dejó de ser una recomendación.

• Antes de responderme Nadie firma por otro.

  Si una respuesta habla en nombre de un agente que no trabajó en ese turno, se rechaza antes de llegar a mí y el sistema tiene que corregirla.

• Antes de publicar Cada proyecto revisa a dónde va.

  El despliegue compara el destino real contra el que le corresponde a esa carpeta. Si no coinciden, se cancela, y un producto no termina publicado encima de otro.

• En las auditorías Verificar, no creer.

  Las auditorías a los agentes incluyen datos trampa, como un archivo que no existe. Un agente que dice haberlo leído queda expuesto en el acto.

Para que no quede duda: son agentes de software, no personas. Los nombres existen porque un sistema con roles definidos se dirige mejor que una caja que responde a todo. Lo que sí es literal es la jerarquía: dos de ellos pueden detener una entrega aunque yo tenga prisa, y ninguna publicación ocurre sin que yo la apruebe.