Case Study10 min de lectura

De copiloto genérico a 28 paquetes de IA especializados por división

Cómo FACTA usó Package Builder para llevar una plataforma multi-tenant de un asistente genérico a 28 paquetes auditados y especializados — spec-driven, namespaces por tool, gate de aprobación y portable a 14 herramientas de coding.

DATOS DEL PROYECTO

CLIENTE

Plataforma profesional-services multi-tenant

SECTOR

Tooling de IA vertical · SaaS multi-tenant

SERVICIOS FACTA

Fractional CAIO · Arquitectura SDD · Autoría de specs · Ingeniería

DURACIÓN

5 meses (audit → spec → aprobación → producción)

EQUIPO

1 CAIO fraccional · 1 arquitecto SDD · 3 ingenieros · 1 reviewer

ESTADO

En producción · 28 divisiones + 4 módulos transversales live

Resumen ejecutivo

Un asistente genérico se convierte en 28 paquetes de IA gobernados y especializados.

El cliente operaba una plataforma multi-tenant donde cada cliente recibía el mismo asistente de coding genérico. Tenants de ventas, finanzas, salud y legal compartían una sola superficie — sin agentes especializados, sin comandos por división, sin doctrina auditable. La adopción se estancaba justo donde el trabajo se volvía específico de dominio: el asistente escribía boilerplate pero no podía correr un sales-pipeline review, armar un QBR o cerrar los libros del mes.

FACTA desplegó Package Builder — su producto de spec-driven development (SDD) — para industrializar la especialización. Cada división se auditó, se propuso, se spec-ar, se aprobó y recién ahí se implementó. En cinco meses el cliente pasó de un copiloto genérico a 28 paquetes por división y 4 módulos transversales, todos namespaced bajo un único plugin pb:, portables a 14 herramientas de coding soportadas, con los CI guards en verde en cada merge.

RESULTADOS

Divisiones en producción

28

Más 4 módulos transversales

Agentes especializados

297

Todos lint-clean, tagueados por división

Herramientas soportadas

14

claudecode canónico + 13 deltas

CI guards en verde

11

check-divisions, lint-agents, scan-secrets, etc.

El cliente

Una plataforma multi-tenant donde un asistente servía a todos los verticales.

El cliente corre una plataforma SaaS multi-tenant para firmas de servicios profesionales — consultoras de ventas, equipos de finanzas, prácticas de salud, estudios legales, agencias de marketing y grupos de operaciones, todos sobre el mismo producto. Su superficie de IA era un único asistente de coding genérico compartido por todos los tenants. La tesis era sólida en etapa seed: tirar un copiloto, aprender qué piden los tenants, y después especializar. Para Serie A el aprendizaje había convergido: el 70% del uso era trabajo vertical que el asistente genérico no podía hacer bien, y los tenants exportaban los prompts para correrlos en otro lado. La plataforma necesitaba tirar paquetes especializados por división sin convertirse en 28 productos distintos.

El desafío

Especializar 28 veces sin fragmentarse en 28 productos.

El mandato parecía un problema de contenido y era un problema de gobernanza. Escribir 28 sets de agentes es fácil; mantenerlos consistentes, sin overlap, portables entre tools, limpios de secretos y seguros para merge en un equipo creciente es donde vive el trabajo real. El cliente había probado un enfoque bottom-up — dejar que cada owner de división escribiera sus propios agentes y comandos — y consiguió colisiones de overlap, drift entre tools, inconsistencias de frontmatter y una superficie sin testear que nadie podía avalar.

RESTRICCIONES

Sin colisiones de overlap

Dos divisiones que escribieran el mismo artifact (un BMC strategist, un retrospective facilitator) tenían que detectarse y resolverse antes de la implementación — no en producción.

Portabilidad entre tools

Los paquetes tenían que renderizar en claudecode, cursor, codex, kilocode, gemini-cli, qwen-code, github-copilot, opencode, windsurf, aider, antigravity, kimi-code, openclaw, hermes, osaurus y mistral-vibe — sin mantener 14 codebases separados.

Gate de aprobación antes que el código

Ninguna tarea de implementación de una división podía correr hasta que su spec estuviera revisado y aprobado. Los reguladores del cliente exigían una traza auditable de spec-then-build.

Sin secretos por construcción

Cada adapter y script tenía que pasar scan-secrets.sh y rutear por ssrf_guard.py — ningún adapter de plataforma live podía aterrizar sin un gate de 3 rondas del security-reviewer.

El enfoque de FACTA

Triple rol: arquitectura SDD, autoría de specs, entrega de ingeniería.

FACTA operó como un único socio técnico en los tres planos que el engagement requería — dirección, arquitectura y ejecución — en lugar de tres vendors distintos:

01

Dirección — Fractional CAIO

  • ·Roadmap vertical across 28 divisiones
  • ·Orden de prioridades: divisiones red activadas antes del depth-completion de las yellow
  • ·Estrategia de doctrina tenant-scoped (destilación de knowldage_database)
  • ·Narrativa de inversores alrededor de IA especializada

02

Arquitectura — Diseño SDD

  • ·Gate audit → spec → aprobación → implementación
  • ·Namespace pb: via plugin manifest de Claude Code
  • ·claudecode canónico + modelo de render-delta por tool (§9 de cada spec)
  • ·11 CI guards como backbone de no-regresión

03

Entrega — Liderazgo del equipo de ingeniería

  • ·Lideramos 3 ingenieros implementando spec §7 tarea por tarea
  • ·Construimos OVERLAP-CHECK.md para resolver 8 colisiones cross-module pre-implementación
  • ·Destilamos 43 obras de knowldage_database en context packs trazables
  • ·Llevamos la revisión de aprobación con el reviewer de compliance del cliente

La solución técnica

Package Builder: 28 divisiones, 4 módulos transversales, un namespace pb:.

Package Builder organiza la especialización en 32 módulos — 28 divisiones por industria más 4 módulos transversales — cada uno con un audit, un claudecode/spec.md y un bloque de render-delta por tool. Cada spec sigue las mismas 10 secciones, cada comando está namespaced bajo /pb:, y cada tarea de implementación nombra los CI guards que deben quedar en verde. La implementación está prohibida hasta que el spec se aprueba.

MÓDULOS

01

DIVISIONS (28)

Paquetes por industria — sales, finance, healthcare, legal, marketing, operations, governance, procurement, ESG, customer-success y 18 más.

02

COMMAND-NAMESPACING

El plugin manifest pb: — cada división consume el prefijo de dos puntos por referencia en lugar de re-derivarlo.

03

AGENT-ROSTER-GAPS

Audit de roster cross-división — flaggea agentes que ninguna división owns y propone su hogar.

04

README-ATTRIBUTION

Contrato de provenance — los agentes adaptados llevan línea Adapted-from, las destilaciones KD llevan línea Distilled-from.

05

CHROME-TEMPLATE

Superficie de templates con leak-guard — verify-template.sh + leak-guard.sh gatean cada edit de templates/.

06

OVERLAP-CHECK

La tabla de resolución vinculante — 8 colisiones cross-module resueltas antes de que cualquier tarea de implementación corra.

STACK

Tool canónica
Claude Code — claudecode es la source-of-truth de la superficie de tools
Deltas por tool
cursor .mdc · codex flat agents/ · kilocode SKILL.md · copilot .github/copilot/ · windsurf .windsurf/rules · aider CONVENTIONS-*.md · openclaw personas · mistral-vibe .mistral/commands
Namespace
pb: slash-command namespace via .claude-plugin/plugin.json (name: pb)
Doctrina
Corpus knowldage_database destilado en context/_domains/<division>/ packs con líneas de provenance
Adapters
Stripe · QuickBooks · Salesforce ruteados por ssrf_guard.py + resolve_first_adapter_secret + gate del security-reviewer
CI guards
check-divisions · lint-agents · check-commands · check-runbooks · check-crons · check-context-paths · check-tools · seed-marketplace --check · scan-secrets · leak-guard · verify-template

Open core · Spec-gated · 11 CI guards en verde en cada merge

REPOSITORIO

github.com/facta/package-builder

Resultados

Cinco meses. 32 módulos. Cero colisiones de overlap en producción.

Package Builder salió a producción con las 28 divisiones y los 4 módulos transversales live. La tabla OVERLAP-CHECK atrapó 8 colisiones cross-module antes de que corriera cualquier línea de código — el BMC strategist, el retrospective facilitator, el ESG estimator, el comando de incident-response y otros cuatro — cada una resuelta con un owner vinculante y un perdedor re-scoped. El modelo de delta por tool mantuvo 14 herramientas de coding sobre una única source of truth. Y el gate de aprobación produjo una traza auditable de spec-then-build que satisfizo al reviewer de compliance del cliente sin frenar al equipo de ingeniería.

MÉTRICAS

Divisiones en producción
28
Más 4 módulos transversales
Agentes especializados mandados
297
Todos con frontmatter completo, lint-clean
Colisiones resueltas pre-implementación
8
Todas atrapadas en OVERLAP-CHECK antes de implementar
Herramientas de coding soportadas
14
claudecode canónico + 13 deltas
Obras KD destiladas en doctrina
43
Sales 10 · finance 43 · across all divisions
CI guards en verde por merge
11/11
Backbone de no-regresión sostenido 5 meses

“Package Builder no sólo nos escribió 28 paquetes — nos dio una forma de mantenerlos consistentes. La tabla de overlap sola nos ahorró un trimestre de discusiones sobre quién owns el BMC strategist. El gate de aprobación es lo que le permitió a nuestro reviewer de compliance firmar.”

VP Engineering

Plataforma cliente

Lecciones replicables

Qué hace que la especialización sea shippable y no un sprawl.

La especialización es un problema de gobernanza, no de contenido.

Escribir 28 sets de agentes es fácil. Mantenerlos sin overlap, portables entre tools y seguros para merge en un equipo es el trabajo real — y necesita un OVERLAP-CHECK y un gate de aprobación, no más writers.

Una tool canónica con deltas le gana a N codebases paralelos.

claudecode es la source of truth; cada otra tool es un render delta de §9. Un spec, 14 superficies de tool — sin el costo de mantenimiento de 14×.

Un gate de aprobación es un asset de compliance, no un cuello de botella.

Spec-then-build le pareció overhead al equipo de ingeniería y oro al reviewer de compliance. Es lo que le permitió a ambos firmar el mismo shipment.

Namespacing por referencia le gana a re-derivar por división.

Cada división consume el prefijo pb: desde command-namespacing en lugar de re-authorarlo. Un mecanismo, 28 consumidores, cero drift.

Sobre FACTA

Liderazgo de IA fraccional con ejecución técnica real.

FACTA es una consultora especializada en Chief AI Officer y CTO fraccionales para empresas que necesitan liderar la transición a IA sin contratar un equipo executive full-time. A diferencia de los consultores generalistas que entregan PowerPoint, FACTA entrega sistemas en producción — incluyendo productos spec-driven como Package Builder, donde el spec es la unidad de aprobación y la implementación es el artifact.

Combinamos diez años de experiencia en arquitectura de IA con expertise operativo en multi-agente, spec-driven development, Graph RAG, A2A, y stack moderno (Rust, TypeScript, infraestructura cloud y on-prem). Trabajamos con startups post-seed hasta scale-ups Series B en regiones de habla hispana e inglesa.

SERVICIOS

01 · Fractional CAIO

Dirección de IA a nivel C-suite. Roadmap vertical, prioridades por división, relación con inversores, posicionamiento de mercado.

02 · Arquitectura SDD

Gate audit → spec → aprobación → implementación. Boundaries de módulos, resolución de overlap, backbone de CI guards.

03 · Autoría de specs e ingeniería

Specs de 10 secciones con render deltas por tool, implementados tarea por tarea con todos los CI guards en verde.

04 · Strategic Advisory

Acompañamiento a fundadores en fundraising, GTM, partnerships estratégicos y compliance regulatorio.

¿Un próximo caso?

Si están construyendo una plataforma multi-tenant que necesita especializarse por vertical sin fragmentarse en N productos, hablemos.

Agendá una llamada de 30 minutos

hola@facta.dev

NEWSLETTER

Insights de estrategia e ingeniería de IA para líderes técnicos — cada martes.

Únete a 2.500+ ingenieros y líderes que reciben insights prácticos de implementación de IA.

Suscribirse

Tu Privacidad Importa

Usamos cookies para mejorar tu experiencia, analizar el tráfico y mostrar anuncios personalizados.

Al hacer clic en "Aceptar Todo", consientes el uso de todas las cookies. Política de Cookies