Cómo construí un departamento de IT con 47 agentes de IA (y lo que aprendí)

Hace cuatro meses, me hice una pregunta que debería haberme hecho años antes: ¿podría dejar de depender de equipos de desarrollo externos para construir software?

No era una queja. Era un diagnóstico. Tengo criterio sobre qué quiero construir. Tengo el contexto de negocio que ningún ingeniero externo va a tener. Y aun así, cada proyecto nuevo pasaba por el mismo ciclo: briefing, propuesta, presupuesto, iteraciones largas, entrega incompleta, mantenimiento caro. Meses y meses de espera.

Cuatro meses después, ese ciclo ya no existe para mí. Lo que existe en su lugar se llama Factory.

Si estás decidiendo por qué departamento empezar, tienes la guía de IA por departamento.

El problema que tenía antes de Factory

El problema no era la calidad de los equipos con los que trabajé. Era estructural.

Cuando contratas desarrollo externo, el ingeniero más brillante del mundo sigue teniendo el mismo problema: no sabe lo que sabes tú sobre tu negocio. Tú sabes qué proceso duele más. Sabes qué atajos toma tu equipo que ningún sistema va a reflejar. Sabes por qué ese campo que parece redundante en realidad es crítico para auditoría. Ese conocimiento tácito no se transmite en un briefing de dos horas ni en un documento de requisitos de 30 páginas.

El resultado habitual: tres meses de desarrollo, entrega, y entonces tú ves el sistema funcionando por primera vez y empiezas a darte cuenta de lo que falta. Que es mucho. Y volver atrás tiene coste.

Llevo tres años usando IA en las empresas en las que he trabajado. Los primeros dos años, la IA me ayudaba a pensar más rápido: redactar, analizar, sintetizar. Bueno, pero no transformador como ahora vemos que realmente puede serlo. Lo transformador llegó cuando empecé a usar Claude Code y Codex de forma intensiva, hace cuatro meses.

La diferencia no es de interfaz. Es de capacidad: Claude Code no responde preguntas — actúa sobre tu sistema, lee tus archivos reales, ejecuta tareas, persiste contexto entre sesiones y puede coordinarse con otras herramientas. Es la diferencia entre tener un consultor que opina y tener un equipo que hace.

Qué es Factory

Factory es mi departamento de IT completo, construido con Claude Code. No es un prototipo de laboratorio. Es lo que uso en producción para construir software real. Hoy mismo.

Cuando describo «un departamento de IT con 47 agentes», lo que quiero decir es esto:

FACTORY — Arquitectura de 5 capas
══════════════════════════════════════════════════════════════

CAPA 1 — HERRAMIENTAS (MCPs)
  GitLab CI/CD · Jira Cloud · Staging · Production
  Anthropic Claude (principal) + OpenAI (fallback)

CAPA 2 — SKILLS (8 capacidades reutilizables)
  bootstrapping · planning-bridge · tdd-feature-delivery
  test-plan-builder · release-readiness · story-batching
  prd-from-discovery · spec-from-prd

CAPA 3 — AGENTES ESPECIALISTAS (47)
  ┌─ Producto ─────────────────────────────────────────────┐
  │  product-owner-proxy · ux-designer · ux-critic         │
  │  service-designer · user-advocate · product-critic     │
  │  discovery-lead · jtbd-analyst · user-advocate         │
  └────────────────────────────────────────────────────────┘
  ┌─ Arquitectura ─────────────────────────────────────────┐
  │  solution-architect · platform-architect               │
  │  architecture-critic · data-architect                  │
  └────────────────────────────────────────────────────────┘
  ┌─ Desarrollo ───────────────────────────────────────────┐
  │  backend-engineer · web-frontend-engineer              │
  │  ios-engineer · android-engineer · desktop-engineer    │
  │  integration-engineer · tdd-implementer · tech-lead    │
  │  performance-engineer · accessibility-reviewer         │
  └────────────────────────────────────────────────────────┘
  ┌─ Calidad y Seguridad ──────────────────────────────────┐
  │  qa-lead · qa-critic · qa-mobile-specialist            │
  │  test-engineer · test-plan-writer                      │
  │  security-architect · security-reviewer                │
  └────────────────────────────────────────────────────────┘
  ┌─ Documentación y Planificación ────────────────────────┐
  │  spec-writer · prd-writer · story-architect            │
  │  story-prioritizer · documentation-engineer            │
  │  code-reviewer · final-critic                          │
  └────────────────────────────────────────────────────────┘
  ┌─ Operaciones ──────────────────────────────────────────┐
  │  devops-sre · release-manager                          │
  │  release-readiness-auditor · retrospective-lead        │
  └────────────────────────────────────────────────────────┘
  ┌─ Estrategia ───────────────────────────────────────────┐
  │  initiative-controller · portfolio-manager             │
  │  build-buy-advisor · ai-governance-lead                │
  │  privacy-compliance-lead                               │
  └────────────────────────────────────────────────────────┘

CAPA 4 — ORQUESTADOR
  factory-orchestrator
  [Coordina. No implementa. Lee outputs. Decide quién y cuándo.]

CAPA 5 — COMANDOS (15 — el ciclo de vida completo)
  discover → prd → stories → spec → implement → review
  → qa-check → release-staging → verify-staging
  → release-production → retrospective
  + new-application · new-project · plan-application
  + sync-traceability

Comunicación entre agentes: artefactos en disco, no mensajes directos.
Gates obligatorios: QA, seguridad y critic sign-off antes de producción.
══════════════════════════════════════════════════════════════

El flujo completo es simple de describir: yo expreso una necesidad de negocio en lenguaje natural. Factory produce software en producción, con QA formal, seguridad revisada, trazabilidad completa hacia los requisitos originales y rollback listo si algo va mal.

Ningún paso de ese flujo requiere que yo sepa programar. Lo que requiere es que yo sepa describir con precisión qué quiero y por qué.

Lo que Factory ha producido en producción

Estos no son proyectos de demostración. Son sistemas que uso hoy:

• Portal CRM de formación: CRM, pagos con Stripe, portal privado de alumnos. Una semana de desarrollo.
• Cerebro: sistema de gestión de compromisos y briefings diarios. Dos semanas. En producción desde hace meses.
• Dashboard de control de obra: seguimiento en tiempo real para proyectos de construcción. Una semana.
• Equipo agéntico de marketing: redacción, análisis de métricas, planificación de campañas. Dos semanas desde cero.
• Análisis automatizado de feedback de clientes: caso de un cliente en hostelería, tres días.
• Aplicación para entrenamientos. Lista en 3 días.

Antes, cualquiera de estos proyectos habría sido un contrato de tres a seis meses con un proveedor externo. Con Factory, son días para primer producto usable y pocas semanas para tener el producción algo «serio». Y yo controlo cada decisión de negocio que toman los agentes, porque yo diseñé los criterios.

Lo que aprendí construyendo Factory

Cuatro meses de trabajo intensivo producen aprendizajes que no se leen en un artículo. Pero hay cinco que cambiarían cómo cualquier directivo piensa sobre la IA si los entendiera desde el principio.

1. Los agentes generalistas son inútiles en producción

El primer instinto cuando construyes un sistema multi-agente es hacer agentes grandes que puedan hacer muchas cosas. Error. Un agente que puede hacer todo no tiene criterio sobre nada. Sus respuestas son blandas, sus análisis superficiales y su tasa de error alta.

La arquitectura que funciona es la opuesta: agentes con dominio muy acotado, con frameworks explícitos de razonamiento, que hacen una sola cosa extremadamente bien. El qa-critic de Factory no implementa nada — solo revisa calidad. El security-reviewer solo piensa en vectores de ataque. El ux-critic solo evalúa experiencia de usuario. Esa restricción no es una limitación — es lo que los hace útiles.

2. Los agentes no se hablan entre ellos — se comunican a través de artefactos

Este fue el cambio de paradigma más importante en el diseño de Factory. El modelo intuitivo de un sistema multi-agente es que los agentes se pasan mensajes entre ellos, como un equipo humano en un chat. Ese modelo no escala y no es trazable.

En Factory, los agentes no se hablan directamente. Cada agente produce un artefacto — un documento, una especificación, un informe — y lo guarda en disco. El siguiente agente en el pipeline lee ese artefacto. El resultado es que tienes trazabilidad completa: cada decisión se puede rastrear hasta el artefacto que la originó, y cada artefacto referencia qué requisito lo generó.

Además esto hace que el consumo de tokens se pueda mantener en algo razonable cuando el proyecto escala.

3. Los critics son más valiosos que los builders

En producción, el agente más importante del sistema no es el que construye — es el que revisa. El final-critic de Factory tiene permisos de solo lectura por diseño: no puede modificar nada, solo señalar problemas. Esa restricción no accidental sino arquitectónica garantiza que la revisión es independiente de la implementación.

Antes de introducir critics formales en el pipeline, aproximadamente el 30-40% de los outputs de los agentes de desarrollo llegaban a la revisión con problemas que se habían acumulado silenciosamente. Con critics distribuidos a lo largo del pipeline, esos problemas se detectan cuando todavía son baratos de resolver.

4. El coste real no es lo que parece al principio

Cuando empecé, usaba el modelo más potente de Anthropic para todo. El coste escalaba rápido. La solución que aprendí por las malas: estratificación de modelos. No todos los agentes necesitan el mismo nivel de razonamiento. El orquestador, que toma decisiones de coordinación complejas, usa el modelo más potente. Los 45 especialistas, que ejecutan dentro de su dominio acotado, usan modelos intermedios. Los agentes estructurados que producen outputs predefinidos usan los más ligeros.

El ahorro en coste de tokens con esta estratificación fue del 70-80% respecto a la configuración inicial. Un sistema multi-agente bien diseñado no es más caro que uno mal diseñado — es más barato, porque cada invocación usa el nivel de razonamiento justo que necesita.

5. El verdadero cuello de botella eres tú

Después de cuatro meses, el límite de Factory no es técnico. El límite soy yo. Mi capacidad para describir con precisión un problema de negocio determina completamente la calidad del software que produce Factory.

Los agentes no inventan requisitos. Ejecutan los que les das. Si la descripción de lo que necesitas es vaga, el resultado es vago. Si es precisa y tiene criterios de éxito claros, el resultado es preciso. Eso significa que la competencia más valiosa que puede desarrollar un directivo en relación con la IA no es técnica — es la capacidad de articular problemas de negocio con exactitud suficiente para que un sistema pueda actuar sobre ellos.

Por qué esto importa para directivos que no son CTOs o CIOs

Aquí podría decir que Factory es un ejemplo extremo, que un directivo no necesita 47 agentes, que hay una versión más sencilla para cada empresa. Todo eso es verdad. Pero no es el punto.

El punto es que Factory demostró algo que yo necesitaba ver con mis propios ojos para creérmelo: que un directivo con criterio de negocio puede construir infraestructura de software en producción sin depender de nadie externo, en semanas, al coste de una licencia de software.

El principio que hace posible Factory no requiere 47 agentes para funcionar. Requiere entender cómo se diseña un sistema donde cada componente tiene responsabilidad acotada, criterios explícitos y comunicación trazable. Eso se puede aplicar a un departamento de marketing, a un proceso de revisión de contratos, a la gestión de incidencias de IT. Con tres agentes bien diseñados, no con cuarenta y siete.

Lo que necesitas para empezar no es experiencia técnica. Es el método. Y el método se aprende.

Para ver cómo aplica a tu empresa en concreto, este artículo explica la arquitectura completa de un sistema multi-agente desde cero, con ejemplos ejecutivos. Y este otro cubre las skills de Claude Code, que son la unidad de capacidad reutilizable que más tiempo ahorra.

Preguntas frecuentes