Organizational Commons · Framework v2.0

La información como bien común de la organización

El Organizational Commons es un proceso de descentralización, transparencia y autonomización del acceso a la información organizacional. Opera sobre la estructura existente — no requiere rediseñarla.

7 Principios de diseño
3 Intervenciones
4 Capas técnicas
4 Tipos de acceso
Definición central
Commons — bien común — describe un recurso accesible para todos los que pertenecen a la comunidad, con reglas de uso acordadas que protegen su integridad sin concentrar su control en manos de una minoría.
Qué hace el OC

Un sistema que elimina intermediarios de información

No es una herramienta de IA. Es infraestructura de autonomía organizacional. La diferencia está en el diseño, no en la tecnología.

Equipo comercial Espera el lunes
"¿Cómo evolucionó el equipo respecto a la semana anterior? ¿Cuál es la tendencia entre sucursales?" — Respuesta en segundos, en lenguaje natural, sin analista.
Líder de área Espera el cierre
Pregunta cuánto lleva gastado, a qué ritmo consume, cuándo agotará una línea. Simula escenarios en la misma conversación sin pedir aprobación.
Dirección Recibe presentaciones
Accede a cualquier nivel de detalle cuando lo necesita. Detecta anomalías antes de que se conviertan en problemas.

Por qué "Commons"

El nombre no es accidental. Un commons es un recurso accesible para todos los que pertenecen a la comunidad, con reglas de uso acordadas que protegen su integridad sin concentrar su control en manos de una minoría.

En el modelo actual, la información es propiedad de quien tiene el cargo. En el OC, la información pertenece a quien la necesita para actuar.

Qué no es el OC

No es un proyecto de transformación digital. No es un dashboard con más features. No es un asistente de IA que automatiza tareas individuales.

Es un rediseño del modelo de poder informacional de la organización — con consecuencias sistémicas sobre la autonomía, la velocidad de decisión y la capacidad de adaptación.

Navegar el framework

Secciones del OC Framework

Sección 01

Los 7 principios operativos del OC Framework

Son los principios que gobiernan cómo se diseña e implementa el commons. Complementan los siete principios conceptuales del OC desarrollados en el paper, traduciéndolos en criterios de decisión para cada implementación. Violarlos no es un error técnico — es un error de modelo.

01
La información pertenece a quien la necesita para actuar

No a quien tiene el cargo que históricamente la recibía. El criterio es funcional, no jerárquico.

02
Acceso por naturaleza de la información, no por jerarquía

La naturaleza de la información determina quién la necesita. El modelo tiene 4 categorías — ninguna depende del cargo del consultante.

03
El commons se diseña desde las preguntas de la periferia

No desde los reportes que la dirección ya recibe. Los equipos con contacto directo con el mercado son los que más necesitan información en tiempo real.

04
El feedback loop es visible para todos

La calidad del commons se mide en campo. Cada consulta sin respuesta adecuada es un punto ciego visible — no una anomalía privada que resuelve TI.

05
Los presupuestos como contexto de acción, no como techo de control

El presupuesto base se construye sobre el período comparable anterior más dos opciones de ajuste. Elimina el ciclo de negociación anual como instrumento de control jerárquico.

06
La implementación es incremental y produce resultados antes de estar completa

Empezar por las preguntas de mayor valor para los equipos periféricos genera confianza para continuar antes de que el sistema esté completo.

07
Auditoría anti-jerárquica permanente — el Principio 7

Cada decisión de diseño se evalúa contra la pregunta: ¿estamos diseñando para la autonomía de los equipos o para el control de la dirección? La tendencia a reproducir la jerarquía dentro del commons es el riesgo de diseño central del OC — ocurre cuando la dirección decide unilateralmente qué entra, cuando se crean "niveles de acceso" que replican el organigrama, o cuando la información requiere intermediación experta para ser interpretada. El OC Architect tiene la responsabilidad explícita de detectar y nombrar ese riesgo en cada implementación.

Riesgo de diseño central — auditar permanentemente

Cuando la dirección decide unilateralmente qué entra al commons, cuando se crean "niveles de acceso" que replican el organigrama, o cuando la información se presenta de forma que requiere intermediación experta para ser interpretada — el commons deja de ser un bien común y se convierte en un nuevo mecanismo de control con interfaz más amigable. Ese resultado es exactamente lo que el OC Framework existe para prevenir.

Fundamento conceptual

Raíz en el BetaCodex

El OC Framework se construye explícitamente sobre la ontología del BetaCodex: la distinción centro/periferia, la transparencia como infraestructura de autonomía, y el rechazo del ciclo presupuestario anual como instrumento de control.

La Ley 5 de BetaCodex — "Transparencia como inteligencia de flujo, no obstrucción de poder" — es el fundamento filosófico de la arquitectura concéntrica del OC.

La tensión más relevante: BetaCodex §5 propone transparencia casi radical. El OC tiene un modelo de acceso por naturaleza con cuatro niveles. La convergencia está en el destino — transparencia universal. La diferencia está en el camino: el OC contempla ciclos de apertura como dispositivo transicional mientras la organización madura su capacidad de operar con información abierta.

La diferencia entre Cargo → Acceso y Naturaleza → Acceso es la distinción que define al OC. La dirección del movimiento es siempre hacia mayor apertura — la diferenciación que se observa en cualquier momento es un estado de transición, no una arquitectura permanente.

Sección 02

Acceso por naturaleza de la información

La pregunta correcta no es "¿a quién le damos acceso?" La pregunta correcta es "¿qué tipo de información requiere qué tipo de cuidado?"

Modelo actual
Cargo → Acceso
vs
OC Framework
Naturaleza → Acceso
El modelo de acceso

4 categorías, 0 cargos

Este modelo no describe categorías fijas sino estados de transición. La dirección del movimiento es siempre hacia Universal organizacional.

Acceso universal
Operativa agregada

Resultados de equipos, métricas de área, tendencias de ventas, comparativas entre sucursales. El mismo contexto de análisis para todos habilita decisiones autónomas y comparación entre pares.

Ventas del mes · Tendencia por sucursal · Indicadores operativos de área

Equipo y pares
Operativa de equipo

Métricas internas, estado de proyectos, capacidad operativa. Visible para los miembros del equipo y sus interlocutores directos — no por jerarquía sino por relevancia de acción.

Estado de proyectos en curso · Capacidad disponible · Métricas internas del equipo

Por relevancia directa
Nominal individual

Salarios específicos, evaluaciones de desempeño, datos de clientes identificables. En el proceso de apertura, los salarios se hacen visibles primero agrupados por equipo.

Evaluaciones individuales · Datos de clientes identificables · Salarios por equipo (apertura progresiva)

Acuerdo explícito
Estratégica sensible

Información con valor económico asociado a su resguardo: propiedad intelectual, patentes, secretos comerciales, negociaciones donde la exposición prematura destruye valor. Criterio económico y legal — no jerárquico. Independientemente del cargo del consultante.

IP y patentes · Negociaciones en curso · Datos financieros pre-públicos

La distinción que define el modelo

En el modelo actual, el cargo determina el acceso. En el OC, la naturaleza de la información lo determina. Esta distinción es fundamental porque cambia la variable de control — y eso cambia todo lo que sigue: quién decide, quién actúa, y con qué velocidad.

Dinámica del modelo

La dirección del movimiento

El modelo de acceso por naturaleza de la información no es estático. La apertura es progresiva en ciclos de apertura — cada ola de implementación mueve más información hacia categorías de acceso más amplio.

Los salarios, por ejemplo, pasan de invisible a agrupado por equipo antes de llegar a individual. El movimiento siempre va en una dirección: más información accesible para más personas.

La apertura progresiva desnaturaliza la jerarquía. Cuando los equipos tienen acceso a la misma información que la dirección, el rol de la dirección cambia: de filtro de información a generador de contexto y criterio.

Ese cambio de rol es el que el OC produce — y el que el Principio 7 protege durante todo el proceso de diseño.

Sección 03

Las 3 intervenciones donde Adaptant es irreemplazable

La diferencia entre un commons que produce autonomía y uno que reproduce jerarquía con interfaz amigable está en estas tres intervenciones.

01

El diseño del commons

La intervención más crítica del proyecto — y la que más riesgo tiene de hacerse mal.

Qué es

El co-diseño del commons es el proceso participativo de decidir qué información entra, con qué criterios de acceso, qué preguntas debe poder responder, y cómo está estructurado para que no reproduzca jerarquías en nueva forma.

Esas decisiones requieren el OC Framework y experiencia en su aplicación. Sin esta intervención, el commons es un repositorio de datos con interfaz conversacional. Con ella, es infraestructura de autonomía organizacional.

El riesgo que Adaptant previene

El error más frecuente en implementaciones de IA conversacional sobre datos propios: la dirección decide qué entra al commons, crea niveles de acceso que replican el organigrama, y presenta información de forma que requiere intermediación experta para ser interpretada.

El Principio 7 del OC Framework y el proceso de co-diseño participativo son exactamente lo que previene ese resultado.

Entregables de la intervención
01
Mapa de preguntas por rol
El banco de preguntas que el commons debe poder responder, organizado por equipo y rol. Diseñado con los equipos periféricos — no con la dirección.
02
Modelo de acceso del commons
La clasificación de cada fuente de datos según el modelo de acceso por naturaleza de la información. Documentado, auditado y firmado por dirección y equipos.
03
Arquitectura del datamart semántico
La especificación de qué fuentes se integran, cómo se transforman para ser comprensibles en lenguaje natural, y qué metadatos de contexto organizacional se añaden.
04
Plan de implementación por fases
La secuencia de activación del commons, ordenada por valor para los equipos periféricos. Cada fase produce resultados antes de que el sistema esté completo.
Fase transitoria — del skill embebido al Datamart
No toda implementación arranca con la arquitectura completa
Algunos clientes — por madurez, por presupuesto, por decisión estratégica de validar antes de invertir — comienzan con una versión simplificada del commons que opera sobre un skill embebido en lugar de un Datamart vivo. Esa versión simplificada no es una falla del diseño: es una etapa transitoria documentada del proceso de adopción. Resuelve el primer obstáculo de cualquier implementación — la decisión de inversión — permitiendo que el cliente vea el commons funcionando con sus propios datos antes de comprometer la arquitectura completa.
Dimensión Fase transitoria · Skill embebido Arquitectura completa · Open
Fuente de datos Snapshot embebido como texto en el system prompt Datamart vivo, sincronizado vía Airbyte
Actualización del dato Manual — el custodio regenera el skill Continua — agentes C2 detectan cambios y sincronizan
Capa activa No disponible — el stack no la soporta Operativa — protocolo de agentización activo
Feedback loop Operativo (pulgar arriba/abajo) Operativo + cruzado con datos del Datamart
Tiempo de implementación 4–6 semanas 3–6 meses
Costo Bajo — Claude Pro o API, sin infraestructura Medio-alto — infraestructura + integraciones
Cuándo es la decisión correcta

· El cliente no ha decidido si avanza con la inversión completa y necesita evidencia con sus propios datos.

· El presupuesto del ciclo actual no alcanza para la arquitectura completa pero sí para una demostración funcional.

· La organización está validando el OC contra alternativas y necesita comparar implementaciones reales.

· El equipo interno todavía no tiene madurez técnica para operar Open y necesita una etapa de aprendizaje.

Cuándo avanzar a la arquitectura completa

Los tres umbrales que indican que la migración tiene fundamento operativo:

· Adopción ≥50% del equipo objetivo usa el commons al menos 1×/semana durante 4 semanas consecutivas.

· Patrones candidatos a agentización al menos 3 patrones cumplen los criterios de elegibilidad (ver Sección 08).

· Frecuencia de actualización requerida los datos necesitan actualizarse con cadencia ≤7 días para mantener su valor.

Error de diseño a evitar
Algunas implementaciones de la fase transitoria omiten formar el Equipo de Centro hasta que llega la arquitectura completa. Eso es un error. Aunque la arquitectura sea simplificada, el commons necesita curador, sensor y custodio operando desde el primer día. Sin esos tres roles, el commons no se mantiene vivo y no se acumula la evidencia que justifica la migración. La fase transitoria sin Equipo de Centro es una demo, no un commons. Ver Sección 07 — Equipo de Centro para el detalle de los roles y el ritmo de gobernanza.
02

Liberación activa de tiempo

El trabajo técnico de construir el commons es el trabajo visible. El trabajo metodológico de eliminar las reuniones de reporting que el commons hace innecesarias es el que determina si hay impacto real.

Qué es

Adaptant interviene activamente desde el día uno — no espera a que el commons esté completo para empezar a liberar tiempo. Esa intervención paralela e intencional es la que produce resultados visibles en semanas y genera la credibilidad interna para continuar.

La liberación activa de tiempo es la diferencia entre adopción cosmética e impacto real. Sin ella, los equipos tienen acceso al commons y siguen yendo a las mismas reuniones.

Las tres olas de eliminación

Ola A: Estructuras de reporte reemplazables inmediatamente por el commons en las primeras semanas. Reportes semanales, reuniones de estado.

Ola B: Estructuras que requieren que el commons alcance cierto nivel de cobertura. Reuniones de cierre mensual, reportes de gestión.

Ola C: Estructuras que requieren cambios de acuerdo entre equipos. Comités de seguimiento, reuniones de alineación cross-funcional.

Los 5 entregables
01
Mapa de tiempo perdido
Inventario completo de reuniones y estructuras de reporte con su costo real: horas totales, participantes, frecuencia, costo estimado en dinero. Clasificadas por categoría A/B/C.
02
Banco de preguntas de reemplazo
Las preguntas que el commons debe poder responder para hacer posible la eliminación de cada estructura. Vínculo metodológico directo con la Intervención 1.
03
Plan de eliminación por fases
La secuencia documentada de tres olas: qué se elimina, cuándo, con qué reemplazo, quién es responsable, y los criterios para evaluar si el reemplazo funciona.
04
Dashboard de liberación de tiempo
Medición semana a semana del porcentaje de tiempo dedicado a creación de valor vs. reporting. Visible para todos en el commons. Objetivo: 70–80% en creación de valor a los 6 meses.
05
Reporte de primeros impactos
Documentación de los primeros casos concretos: reuniones eliminadas, tiempo liberado, decisiones tomadas sin escalamiento. Base para la comunicación interna de resultados.

Las estructuras de reporte no se eliminan por convicción filosófica. Se eliminan porque el commons hace posible lo que antes era imposible sin ellas: que los equipos periféricos tengan información completa, en tiempo real, para decidir y actuar.

03

Certificación y acompañamiento del OC Architect

El OC Architect es el rol más crítico de cada proyecto. Ese perfil no existe en el mercado — se forma.

Por qué existe esta intervención

Adaptant forma y certifica a los OC Architects, que son los portadores de la IP en cada implementación. En el modelo partner, el OC Architect puede ser un empleado del partner certificado por Adaptant, o un consultor de Adaptant asignado al proyecto.

Sin un OC Architect certificado, el commons es un proyecto de TI con ambiciones de transformación. Con él, es el inicio de una organización que aprende a decidir con autonomía real.

El posicionamiento clave

La certificación no se compra — ocurre. Es una consecuencia de haber completado un proyecto real con mentoría activa de Adaptant.

No es un punto de llegada. Es una relación continua con Adaptant y con la red de OC Architects. El conocimiento fluye en ambas direcciones: los OC Architects en campo alimentan la evolución del framework.

Lo que produce la intervención
01
OC Architect certificado
Un profesional con los 4 dominios del perfil validados en práctica supervisada. Portador de la IP del OC Framework en futuras implementaciones.
02
Portfolio de criterio
Documentación de las decisiones de diseño tomadas durante el primer proyecto. Base de la evaluación de certificación y contribución a la evolución del framework.
03
Plan de implementaciones futuras
Proyectos que el OC Architect puede ejecutar con autonomía creciente y costos de acompañamiento decrecientes desde el partner o la organización cliente.
04
Acceso a la red y actualizaciones
Membresía activa en la red de OC Architects certificados, con acceso a las actualizaciones del OC Framework y a los casos documentados de otras implementaciones.
El componente que cierra la intervención
La transferencia al Equipo de Centro del cliente
El OC Architect no opera el commons indefinidamente. Forma al primer Equipo de Centro del cliente y transfiere la operación de forma progresiva durante seis meses. Al final de ese período, el cliente sostiene el commons con autonomía. Un OC Architect bien implementado deja al cliente con un equipo interno funcionando sin él — esa es la condición objetiva de éxito de la intervención, independientemente de la calidad técnica del sistema.
M1 El OC Architect opera todos los roles Mes 1
El commons recién desplegado se mantiene exclusivamente desde Adaptant. El Equipo de Centro del cliente observa y aprende.
M2 El Equipo de Centro asume el rol de sensor Mes 2
Las conversaciones con la periferia pasan al sensor interno. El OC Architect sigue conduciendo curador y custodio.
M3 El Equipo de Centro asume el rol de curador Mes 3
La decisión sobre qué entra y qué sale del commons pasa al curador interno, con revisión del OC Architect.
M4 El custodio interno asume la operación técnica Mes 4
Despliegues, integraciones y mantenimiento pasan al custodio. El OC Architect acompaña a distancia.
M5–6 Acompañamiento a distancia Meses 5–6
El OC Architect ya no opera el commons. Disponible para consultas puntuales y revisión estratégica trimestral. Al final del sexto mes, la transferencia está completa.
El indicador objetivo de éxito
Si después de seis meses el cliente todavía depende del OC Architect para mantener el commons operativo, la implementación falló — independientemente de la calidad técnica del sistema. La autosuficiencia del Equipo de Centro es el indicador objetivo de que la transferencia ocurrió. Para el detalle de los tres roles internos y el ritmo de gobernanza, ver Sección 07 — Equipo de Centro.
Sección 04

El OC Architect

Combina cuatro dominios que habitualmente no coexisten en un mismo perfil. Esa combinación es la que hace al rol escaso, valioso, e imposible de reemplazar con recursos genéricos de mercado.

Posicionamiento central
"No se compra. Ocurre."
La certificación es una consecuencia de la implementación, no un producto. El OC Architect no es un título — es el resultado de haber completado un proyecto real con mentoría activa. La IP del framework se transmite en la práctica, no en el aula.
Los 4 dominios

El perfil — cuatro dominios en una sola persona

Dominio 01
Arquitectura de datos y comprensión técnica del OC

Comprensión funcional de las cuatro capas de la arquitectura del OC. No es un ingeniero de datos — es alguien que puede conversar con ingenieros de datos, detectar decisiones técnicas con consecuencias metodológicas, y garantizar que la arquitectura sirva al diseño.

Arquitectura de datos RAG / LLM Acceso por naturaleza Datamart semántico
Dominio 02
Dominio del OC Framework

Conocimiento profundo de los principios del OC: el modelo de acceso por naturaleza de la información, el diseño desde la periferia, el feedback loop como diagnóstico, la secuencia de implementación y el Principio 7. Es quien detecta cuando una decisión reproduce el modelo que el OC debe transformar.

OC Framework v2.0 Diseño anti-jerárquico Feedback loop Principio 7
Dominio 03
Facilitación de co-diseño participativo

Capacidad para conducir las sesiones de mapeo de preguntas con equipos periféricos, las sesiones de diseño del modelo de acceso con la dirección, y las sesiones de diagnóstico de estructuras de reporte en organizaciones con resistencias activas y agendas en tensión.

Co-diseño participativo Gestión de resistencias Facilitación
Dominio 04
Acompañamiento del cambio de rol del middle management

El middle management es el actor más crítico en toda implementación de OC — y el que más frecuentemente bloquea el proceso en forma silenciosa. El OC Architect lee esa resistencia, la nombra sin confrontación, e involucra a los roles amenazados en el co-diseño de forma que su conocimiento se vuelva valioso para el commons.

Dinámicas de poder Gestión del cambio Middle management
El programa de formación

4 módulos en secuencia

Los dos primeros son los entrenamientos públicos de Adaptant. Los dos últimos son exclusivos del OC Framework y se desarrollan en el contexto del primer proyecto real.

M1 Organizaciones Adaptativas 2 días · presencial
Entrenamiento intensivo basado en los conceptos de organizaciones Beta y el BetaCodex de Niels Pflaeging. Las 12 Leyes del BetaCodex, estructuras celulares y equipos autónomos, metas relativas y descentralización en la práctica. Base conceptual sin la cual las decisiones de diseño del commons carecen de marco de referencia.
M2 Cambiar el Sistema 2 días · presencial
Entrenamiento en modelos y estrategias de transformación organizacional. Complementa el módulo anterior con el método: cómo se interviene un sistema organizacional real con herramientas concretas. Cómo leer una organización desde el marco ALFA/BETA y diseñar movimientos de transformación sistémica.
M3 OC Framework 3 días · con OC Architect mentor
Formación específica en el Organizational Commons Framework. Exclusiva de Adaptant — no disponible fuera del programa de certificación. El candidato trabaja sobre casos documentados de implementaciones previas, toma decisiones de diseño sobre escenarios reales, y desarrolla criterio para detectar el error más frecuente: reproducir la jerarquía en el commons en nueva forma.
M4 Práctica supervisada Meses 2–5 · en campo
El candidato co-facilita su primer proyecto de implementación completo bajo supervisión directa de un OC Architect mentor de Adaptant. La evaluación de certificación no es un examen teórico — es una evaluación basada en práctica observada y en la calidad de las decisiones de diseño documentadas durante el primer proyecto.

El OC Architect certificado no es el resultado de la tercera intervención — es la condición que hace posibles todas las demás. Sin ese portador de la IP en cada implementación, el commons es un proyecto de TI con ambiciones de transformación. Con él, es el inicio de una organización que aprende a decidir con autonomía real.

La contraparte estructural — el Equipo de Centro
El OC Architect es el rol externo que facilita la implementación inicial. La contraparte estructural es el equipo interno del cliente que sostiene el commons cuando el OC Architect se retira: curador, sensor, custodio. La transferencia es progresiva durante seis meses — al final, el OC Architect ya no opera el commons. Para el detalle de los tres roles internos, su ritmo de gobernanza y los anti-patrones a evitar, ver Sección 07 — Equipo de Centro.
Sección 06

Arquitectura técnica de referencia

Stack completo para implementar el OC en la línea Open — sin lock-in de fabricante, interoperable con Anthropic, OpenAI, Google Gemini, Microsoft Azure y modelos locales.

Nota de contexto
Este stack aplica exclusivamente a la línea OC Open (Open Standard y Open Enterprise). La línea OC Native usa el ecosistema Anthropic directamente — Claude.ai para Native Start, API de Anthropic para Standard y Enterprise — y no requiere esta arquitectura de abstracción.
6 principios de diseño — no negociables

El anti lock-in como arquitectura

Cualquier decisión de implementación que viole estos principios rompe la promesa de la línea OC Open y la convierte en una solución dependiente de un vendor.

P1 · Estándares abiertos entre capas
Cada capa se comunica con la siguiente mediante HTTP/REST, SQL, JSON, WebSockets. Ninguna capa conoce los detalles internos de implementación de la capa siguiente.
P2 · LLM intercambiable por configuración
El OC Open nunca llama directamente a la API de Anthropic, OpenAI o Google — siempre lo hace a través de LiteLLM. Cambiar de modelo es cambiar una variable de entorno.
P3 · Datos del cliente en su infraestructura
El Datamart vive en la infraestructura del cliente. Si requiere modelos locales, se despliega Ollama sin modificar ninguna otra capa. Los datos no salen sin consentimiento explícito.
P4 · Stack 100% open source (excepto LLMs)
Todo el stack de orquestación, almacenamiento, embeddings y agentes es open source. La única excepción son los LLMs de terceros — que son intercambiables por diseño.
P5 · Interfaces thin sin lógica de negocio
C5 es una capa thin sin lógica de negocio. Cambiar de Slack a Teams no requiere modificar nada en C4 o C3. Agregar una nueva interfaz es solo agregar un nuevo thin client.
P6 · Self-hostable sin dependencia de Adaptant
El stack es self-hostable en cualquier cloud (AWS, GCP, Azure) o servidores propios del cliente. No hay dependencia de infraestructura de Adaptant para operar en producción.
Vista general del stack completo

Capas C1 → C5

Capa Componente Función Licencia Interoperabilidad
C1 · Sistemas fuente Cualquier ERP / CRM / RRHH Fuente de verdad — no se modifica Propiedad cliente Airbyte + webhooks
C2 · Extracción ETL Airbyte + n8n / Airflow ETL → sincronización orientada a eventos. 300+ conectores: SAP, Salesforce, HubSpot, Oracle, MySQL, REST APIs. Apache 2.0 / MIT BD, REST API, SFTP, SQL
C3 · OC Datamart PostgreSQL 16 + pgvector Almacenamiento vectorial + relacional + modelo de acceso por naturaleza de la información. La IP de Adaptant está en el diseño del esquema y las taxonomías. PostgreSQL Lic. / MIT SQL o REST
C4a · Conversacional LiteLLM + LangChain Abstracción LLMs — un endpoint, cualquier modelo. Pipeline RAG: embedding → pgvector → contexto → LLM → respuesta. MIT Anthropic, OpenAI, Gemini, Azure, Llama
C4b · Agentic LangGraph + Temporal Agentes con estado, memoria entre sesiones, briefings proactivos, orquestación multi-paso. Jobs 24/7 de detección de anomalías estadísticas (z-score). Alertas en lenguaje natural generadas por LLM. MIT / Apache 2.0 Sobre LiteLLM — agnóstico de modelo
C4c · Juicio humano Sin stack — por diseño No requiere componente técnico. Es el espacio reservado al juicio humano por diseño y por principio. Las decisiones significativas, la validación y la asunción de responsabilidad viven acá. Cualquier intento de agentizar C4c rompe el principio fundamental del OC. — —
C5 · Interfaces Slack Bolt · Bot Framework · FastAPI+React · Twilio Thin clients — solo presentación, sin lógica de negocio. Intercambiables sin modificar C4 o C3. MIT / BSD Slack, Teams, WhatsApp, Web, móvil
Observabilidad Langfuse (self-hosted) Trazabilidad de conversaciones, latencia, costos por consulta, feedback loop, mapa de puntos ciegos del Datamart. MIT Agnóstico — vía LiteLLM
C3 — El núcleo del OC

El OC Datamart — PostgreSQL + pgvector

C3 es el corazón del OC. La IP de Adaptant está en el diseño del esquema, las taxonomías, el modelo de acceso por naturaleza y la lógica de embeddings. PostgreSQL + pgvector combina SQL clásico con búsqueda vectorial semántica en la misma base de datos.

La función de búsqueda vectorial filtra por privacy_level antes de buscar — nunca después. Eso hace que el modelo de acceso por naturaleza sea un primitivo de la arquitectura, no una capa de aplicación.

El esquema principal de oc_records incluye campos privacy_level, team_id y un vector de 1536 dimensiones con índice ivfflat para búsqueda coseno.

Categorías de acceso en el esquema: universal · team · individual · sensitive — mapeadas directamente a los 4 tipos del modelo de acceso por naturaleza de la información.

Interoperabilidad de LLMs

Matriz de decisión de modelo

La elección de modelo no es técnica — es de política de privacidad, presupuesto y casos de uso. LiteLLM garantiza que cualquier cambio no requiere modificar el código del OC.

Criterio Anthropic Claude OpenAI GPT-4o Google Gemini Meta Llama (local) MS Azure OAI
Calidad razonamiento ★★★★★ ★★★★★ ★★★★ ★★★ ★★★★★
Privacidad de datos API Anthropic API OpenAI API Google 100% local — sin salida de datos Azure — tenant cliente
Costo / M tokens $3–15 $5–15 $1–7 $0 (infra propia) $5–15 + Azure
Context window 200K tokens 128K tokens 1M tokens 8K–128K 128K tokens
Self-hosted No No No Sí — Ollama + GPU No (Azure managed)
Caso de uso OC Default producción Alternativa producción Alta volumetría Política datos estricta Enterprise Microsoft
Guía de prototipo

Las primeras 4 semanas

El stack completo corre en Docker Compose para desarrollo local. El prototipo produce un demo end-to-end funcional al final de la semana 4.

Semana 1
Infraestructura y datos
Docker Compose con PostgreSQL + pgvector + Airbyte corriendo local. Un conector configurado. Primeros datos reales del cliente en el Datamart.
→ Datamart con datos reales operativo
Semana 2
Motor conversacional
LiteLLM corriendo como servidor local. Función oc_query() completa: embedding → búsqueda en pgvector → contexto → LLM → respuesta en lenguaje natural.
→ Primera consulta respondida por el sistema
Semana 3
Interfaz Slack + feedback
Slack Bot conectado al motor. Langfuse corriendo y registrando conversaciones. Mecanismo de feedback funcionando — cada respuesta evaluable por el usuario.
→ Equipo piloto usando el sistema en Slack
Semana 4
Agente proactivo + demo
Agente de briefing proactivo con LangGraph corriendo cada mañana. Detección de anomalías con Temporal. Demo end-to-end para stakeholders.
→ Demo completo para decisión de Go / No-Go
Seguridad y privacidad

Consideraciones de implementación

Toda comunicación entre capas vía HTTPS/TLS. API keys de LLMs en variables de entorno o secrets manager — nunca en código. El Datamart en PostgreSQL con cifrado at-rest y backups cifrados.

Logs de conversaciones en Langfuse con cifrado at-rest. Auditoría completa: cada conversación es trazable hasta los fragmentos del Datamart que la informaron.

Cada query al Datamart incluye user_id y team_id. La búsqueda vectorial filtra por privacy_level antes de ejecutar — es un control en C3, no en la aplicación.

Para clientes con políticas de datos estrictas (finanzas, salud, gobierno): Ollama + nomic-embed-text, 100% on-premise sin salida de datos al exterior.

"El OC Open no requiere que el cliente compre ningún software nuevo. Requiere que conecte lo que ya tiene, lo organice con un modelo de acceso por naturaleza de la información, y lo haga accesible en lenguaje natural a las personas que necesitan actuar con esa información." — Adaptant, 2026

Doble clic sobre la capa C4
Esta sección describe con qué se construye el OC Open — los componentes técnicos por capa. Para el detalle del comportamiento agentic (qué hace cada capa en modo activo, cómo se especifica un agente, el ciclo de vida operativo), ver Sección 08 — OC Agentizado.
Sección 05

Portfolio de Producto

Dos líneas de producto independientes. La misma metodología y el mismo marco conceptual. Lo que las diferencia es el ecosistema tecnológico y el grado de independencia de vendor.

Línea Native
OC Native

Para organizaciones que priorizan velocidad de implementación, simplicidad operativa y respaldo de un vendor consolidado. Anthropic gestiona la infraestructura de inteligencia. Ideal cuando la política de datos permite que las consultas viajen a la API de Anthropic.

Native Start Native Standard Native Enterprise
Línea Open
OC Open

Para organizaciones que requieren independencia de vendor en la capa de inteligencia, datos 100% on-premise, o integración con múltiples modelos (Claude, GPT-4o, Gemini, Llama local). El LLM es intercambiable por configuración — sin modificar código.

Open Standard Open Enterprise
Los 5 tiers

Perfil, alcance e inversión

Native
Native Start
Hasta 15 personas

Pequeñas empresas y comercios con datos en hojas de cálculo que quieren un asistente conversacional para todo el equipo, sin infraestructura propia y con costo de entrada mínimo.

Incluye

Excel estructurado · Skill configurado · Sesión de activación · Soporte onboarding 30 días

Requiere

Claude Pro $20/mes por usuario. Sin infraestructura adicional.

$2.000
USD · Proyecto Adaptant
1–2 semanas de despliegue
Native
Native Standard
15 a 150 personas

Empresas medianas con equipos operativos diferenciados que quieren unificar el acceso a su información en una interfaz conversacional propia, con URL propia y gestión de usuarios.

Incluye

PostgreSQL datamart · Skills por área · Backend Node.js / API Anthropic · URL propia · Panel de usuarios · 90 días de acompañamiento

Stack mensual cliente

$55–270/mes (API + hosting + auth)

$30.000
USD · Proyecto Adaptant
4–8 semanas de despliegue
Native
Native Enterprise
150+ personas

Grandes organizaciones que requieren operación dentro de su propia infraestructura, bajo control total del equipo técnico interno, con integración a directorios corporativos y sistemas existentes.

Incluye

Arquitectura completa Anthropic · Integraciones ERP/CRM/AD · Commons por área · Panel admin · Formación equipo técnico · SLA

Stack mensual cliente

$560–2.620/mes (API Enterprise + infra)

Desde $60.000
USD · Proyecto Adaptant
8–16 semanas de despliegue
Open
Open Standard
15 a 150 personas

Empresas medianas que requieren independencia de vendor en la capa de inteligencia, capacidad de cambiar de modelo sin reescribir código, o cuya política de datos exige trazabilidad self-hosted.

Stack técnico

PostgreSQL + pgvector · LiteLLM · LangChain RAG · Keycloak OSS · Langfuse self-hosted · Docker Compose

Stack mensual cliente

$70–305/mes (LLM API + hosting)

$40.000
USD · Proyecto Adaptant
6–10 semanas de despliegue
Open
Open Enterprise
150+ personas — stack completo C1→C5

Grandes organizaciones que requieren independencia total de vendor, datos on-premise, arquitectura por capas, agentes proactivos, monitoreo continuo e integración con cualquier canal corporativo.

Stack completo

C2: Airbyte 300+ conectores + n8n/Airflow · C3: PostgreSQL + pgvector · C4a: LiteLLM + LangChain · C4b: LangGraph + Temporal (agentes con estado, briefings proactivos, detección de anomalías) · C4c: sin stack — juicio humano por diseño · C5: Slack + Teams + WhatsApp + Web · Langfuse completo

Opciones adicionales

Ollama + LLM local para datos 100% on-premise · Kubernetes para alta disponibilidad · SSO corporativo (OAuth2/SAML/AD) · Stack mensual cliente: $580–2.500/mes (o $0+ on-premise)

Desde $90.000
USD · Proyecto Adaptant
12–20 semanas de despliegue
Comparativo completo

Las 5 versiones lado a lado

Native Start Native Standard Native Enterprise Open Standard Open Enterprise
Tamaño Hasta 15 15–150 150+ 15–150 150+
Plataforma Claude.ai URL propia Infraestr. cliente URL propia Infraestr. cliente
Capa de IA Claude.ai API Anthropic API Anthropic LiteLLM (any) LiteLLM (any)
Búsqueda semántica — SQL básico SQL básico pgvector RAG pgvector RAG
ETL / conectores Manual (Excel) Manual / básico Conectores custom Airbyte básico Airbyte 300+
Agentes proactivos — — Opcional — LangGraph + Temporal
Interfaces Claude.ai Web React Web + custom Web React Slack · Teams · Web · WhatsApp
Observabilidad — Logs básicos Langfuse básico Langfuse self-hosted Langfuse completo
Lock-in vendor IA Claude.ai Anthropic API Anthropic API Sin lock-in Sin lock-in
Datos on-premise No No Opcional No Sí (Ollama)
Tiempo despliegue 1–2 sem. 4–8 sem. 8–16 sem. 6–10 sem. 12–20 sem.
Precio Adaptant $2.000 $30.000 Desde $60.000 $40.000 Desde $90.000
Criterio de decisión

Native vs Open

La elección entre líneas no es técnica — es estratégica. Depende de la política de datos del cliente, su tolerancia al lock-in de vendor, y su capacidad técnica.

Situación del cliente OC Native OC Open
Política de datos estricta (datos no pueden salir) No recomendado ✓ Recomendado — Ollama on-premise
Velocidad de implementación prioritaria ✓ Más rápido Más tiempo — stack más complejo
Independencia de vendor de IA requerida Dependiente de Anthropic ✓ Agnóstico — LiteLLM
Presupuesto ajustado en infraestructura ✓ Mínima infra propia Requiere más infraestructura
Integración nativa con Slack / Teams / WhatsApp Solo en Enterprise custom ✓ C5 estándar en Open Enterprise
Búsqueda semántica (RAG) requerida No disponible en ningún tier ✓ pgvector en todas las versiones Open
Agentes proactivos y briefings automáticos Solo Enterprise con custom ✓ LangGraph estándar en Open Enterprise
Cliente en sector regulado (finanzas, salud, gobierno) Requiere análisis caso a caso ✓ On-premise con Ollama
Cliente ya usa Microsoft 365 / Teams Posible con desarrollo custom ✓ Bot Framework estándar en Open Enterprise
Sección 07

El Equipo de Centro del commons

Tres roles, un ritmo, ninguna jerarquía. La estructura interna que sostiene al commons cuando el OC Architect se retira.

El problema que este componente resuelve
Sin Equipo de Centro, el commons se degrada
El OC Architect facilita el diseño inicial del commons. El Equipo de Centro lo sostiene en el tiempo. No porque el diseño sea defectuoso — ningún sistema de información organizacional sobrevive sin un cuidado distribuido y rítmico que es responsabilidad del cliente. El error frecuente es suponer que IT lo va a absorber. No lo hace. El commons no es una herramienta técnica más; es una infraestructura organizacional cuya salud depende de funciones específicas que rara vez coinciden con el perfil de un equipo de IT clásico.
Los 3 roles

Curador · Sensor · Custodio

En organizaciones pequeñas los tres roles pueden recaer en la misma persona con dedicación parcial. En organizaciones medianas y grandes, lo razonable es que cada rol tenga al menos una persona dedicada con backup rotativo. Lo que no es razonable, en ninguna escala, es que alguno quede vacante — cada uno cumple una función que los otros dos no pueden suplir.

Rol 01
Curador del commons

Misión: mantener viva la calidad de la información que el commons procesa. Revisar el feedback acumulado, identificar patrones de uso, decidir qué información agregar, modificar o quitar del datamart y del skill. Identificar patrones candidatos a agentización y conducir el protocolo de especificación.

Perfil: visión de negocio con comodidad técnica básica. No necesita programar, pero entiende cómo se estructuran los datos. Tiene autoridad reconocida sobre el dominio del negocio.

~3 hs/semana Decisión sobre el dato Maestría del dominio
Rol 02
Sensor del equipo

Misión: capturar lo que el commons todavía no responde bien. Conversar regularmente con la periferia para detectar las preguntas que no llegan al sistema, los outputs que generan fricción, las respuestas que el equipo evita porque no confía en ellas.

Perfil: buena escucha y red interna activa. Idealmente, alguien de la periferia con seniority — un AE senior, un implementador con trayectoria, un referente técnico — que conserve su rol operativo y dedique tiempo parcial al commons.

~2 hs/semana Red interna Escucha cualitativa
Rol 03
Custodio técnico

Misión: mantener la infraestructura del commons operativa y evolutiva. Aplicar las actualizaciones priorizadas por el curador, gestionar los despliegues de agentes, asegurar la disponibilidad del sistema, e integrar nuevas fuentes cuando la organización avanza hacia la arquitectura completa.

Perfil: perfil técnico — interno de la organización o externo contratado a Adaptant o a un partner certificado OC Architect. Capacidad de editar código, manejar el repositorio, y operar la infraestructura.

~4 hs/semana Operación técnica Despliegue de agentes

El curador decide qué entra y qué sale del commons. El sensor captura lo que el commons todavía no ve. El custodio implementa los cambios. Los tres son independientes — y la interdependencia operativa es la garantía de que ninguno acumule poder unilateral sobre el commons.

El ritmo de gobernanza

Cadencia predecible, no rigidez

El commons no se mantiene en tiempo real. No lo necesita. Lo que sí necesita es un ritmo predecible — donde cada actividad de mantenimiento ocurre cuando corresponde y nadie acumula la ansiedad de "todo tiene que estar al día ya". El ritmo libera capacidad cognitiva del Equipo de Centro para hacer su trabajo bien.

Cadencia Actividad Quién Duración
Diario Captura en el flujo — la periferia actualiza sus sistemas como ya lo hace. El commons consume del flujo natural, sin pedir trabajo extra. Todos los usuarios Sin asignar
Semanal · lun Revisión de feedback — el curador lee los pulgares abajo, prioriza qué corregir, abre tickets de actualización del skill. Curador 1 hora
Semanal · jue Update del skill — el custodio aplica las actualizaciones priorizadas y despliega la nueva versión. Custodio 2 horas
Quincenal Sensor con equipo — conversaciones cortas con 4–5 personas de la periferia. ¿Qué te frustró esta semana? ¿Qué información buscás y no encontrás? Sensor 2 horas
Mensual Patrones publicados — el curador identifica patrones de lecciones aprendidas que aparecen en ≥3 casos y los integra al commons como conocimiento estructurado. Curador 3 horas
Trimestral Revisión estratégica — el Equipo de Centro y la dirección revisan: ¿qué sensores OC subieron? ¿qué dimensiones faltan? ¿qué hay que rediseñar? Centro + dirección 2 horas
Semestral Review de maestrías — la periferia autodeclara y valida cruzadamente sus dominios. Se actualiza el mapa de maestrías del commons. Equipo completo 1 hora
Los 4 anti-patrones

Cómo se degrada un commons bien diseñado

Estos son los cuatro modos más frecuentes en que organizaciones bien intencionadas degradan su commons hasta volverlo irrelevante. Nombrarlos explícitamente es la herramienta de prevención más efectiva — cuando aparecen, el Equipo de Centro los reconoce antes de que se instalen.

AP1
El formulario obligatorio

Cuando el commons exige al equipo llenar formularios aparte para alimentarlo, el commons muere. Captura fuera del flujo equivale a captura que no ocurre — o que ocurre de mala fe. La regla es absoluta: si el equipo tiene que abrir algo distinto a sus herramientas habituales para alimentar al commons, el diseño está mal.

AP2
El comité de validación

Cuando la validación de lo que entra al commons sube por jerarquía — "antes de publicar este patrón lo revisa el comité directivo" — la velocidad cae a cero. El commons deja de ser oportuno y se vuelve museo. La validación debe ser por maestría, no por rango.

AP3
La obsesión por completitud

Cuando el Equipo de Centro espera tener "todos los datos" antes de publicar, el commons no nace. Publicar al 70% y mejorar con feedback es siempre superior a publicar al 100% en seis meses. Esperar a no tener feedback negativo es esperar a que el commons sea irrelevante.

AP4
El custodio único

Cuando una sola persona puede mantener el commons, el commons no es resiliente. La organización queda atada a esa persona — y eso reproduce exactamente la dependencia jerárquica que el commons venía a transformar. Los tres roles deben tener al menos un backup rotativo identificado.

La transferencia desde el OC Architect

Una secuencia de seis meses

El OC Architect conduce la implementación inicial y forma al primer Equipo de Centro. La transferencia de responsabilidades es progresiva — no es un evento sino una secuencia.

M1
Mes 1 — El OC Architect opera todos los roles
El commons recién desplegado se mantiene exclusivamente desde Adaptant. El Equipo de Centro observa y aprende.
M2
Mes 2 — El Equipo de Centro asume el rol de sensor
Las conversaciones con la periferia pasan al sensor interno. El OC Architect sigue conduciendo curador y custodio.
M3
Mes 3 — El Equipo de Centro asume el rol de curador
La decisión sobre qué entra y qué sale del commons pasa al curador interno, con revisión del OC Architect.
M4
Mes 4 — El custodio interno asume la operación técnica
Despliegues, integraciones y mantenimiento pasan al custodio. El OC Architect acompaña a distancia.
M5–6
Meses 5–6 — Acompañamiento a distancia
El OC Architect ya no opera el commons. Disponible para consultas puntuales y revisión estratégica trimestral. Al final del sexto mes, la transferencia está completa.

Un OC Architect bien implementado deja al cliente con un Equipo de Centro funcionando sin él. Si después de seis meses el cliente todavía depende del OC Architect para mantener el commons operativo, la implementación falló — independientemente de la calidad técnica del sistema. La autosuficiencia del Equipo de Centro es el indicador objetivo de que la transferencia ocurrió.

Fundamentos en el BetaCodex

El Equipo de Centro como práctica del marco

El diseño del Equipo de Centro no es una elección operativa — es la materialización del BetaCodex aplicada al sostenimiento del commons. Cada decisión estructural descrita en esta sección se ancla en uno o más principios del marco.

Principio Aplicación en el Equipo de Centro
§5 Transparencia Captura abierta y validación distribuida — quien tiene maestría sobre el dato publica, sin filtro jerárquico previo.
§9 Ritmo Cada parte del commons marca su ritmo natural — diario en captura, semanal en revisión, mensual en patrones, trimestral en estrategia.
§10 Maestría El curador no es quien tiene más rango — es quien tiene autoridad reconocida sobre el dominio. El sensor no es designado, es alguien con red interna real.
§12 Coordinación de flujos Sensor, curador y custodio no se reportan entre sí — coordinan por flujo natural del trabajo. La interdependencia es operativa, no jerárquica.

El Equipo de Centro no es una herramienta separada de la cultura que el commons construye. Es la materialización operativa de esa cultura. Cada vez que el curador publica un patrón sin esperar autorización, está practicando autonomía. Cada vez que el sensor lleva al curador una observación cualitativa de la periferia, está practicando transparencia. Cada vez que el custodio implementa el cambio sin agregar capas de aprobación, está practicando coordinación de flujos.

Sección 08

El OC Agentizado

La capa activa convierte al commons de reactivo a activo — en un sistema que aprende de cómo se usa, de lo que la gente corrige y de lo que la organización va realizando. No para eliminar reuniones — para liberar el tiempo que hoy se invierte en hacer visible lo que debería estar visible por diseño.

Esta sección describe qué hace cada capa del OC en modo agentic y cómo se opera el protocolo de agentización. Para el stack técnico que implementa esta arquitectura — componentes, licencias, interoperabilidad — ver Sección 06 — Arquitectura Técnica.
El problema de confusión que esta sección resuelve
Un datamart conversacional ya existe. Lo llaman Copilot.
Microsoft tiene Copilot. Power BI tiene Copilot integrado. SAP tiene Joule. Cualquier BI vendor va a tener su versión en 18 meses. Si el OC se describe como "consultás tu información organizacional en lenguaje natural", es commodity en 2027. La diferencia entre el OC y un BI conversacional no es la interfaz. Es la combinación de tres cosas que los BI vendors no tienen juntas: el modelo de acceso por naturaleza de la información, la metodología de adopción integrada, y — lo que esta sección desarrolla — la capa activa que convierte al commons en un sistema que aprende.
Reactivo vs. activo — la diferencia no es de grado
Un datamart con interfaz conversacional es reactivo: responde cuando le preguntan. El OC agentizado es activo: detecta, sincroniza, alerta y prepara sin que nadie lo solicite. Esa diferencia no es de grado — es de propósito.
Las 5 capas del OC agentizado

Arquitectura por capas con modo reactivo y modo activo

La arquitectura de 5 capas del OC permanece. Lo que se agrega es una dimensión de modo activo en cada capa: qué hace cada capa cuando le preguntan (reactivo) y qué hace sin que nadie le pregunte (modo activo, agentes). La capa C4 se subdivide en tres: conversacional, agentic, y juicio humano.

Capa Rol base Modo reactivo Agentes — modo activo
C1
Sistemas fuente		 CRM, ERP, RRHH, facturación. Fuente de verdad — no se modifica. Datos disponibles por extracción programada. Los agentes C2 detectan cambios y activan sincronización inmediata.
C2
Extracción		 Conectar sistemas fuente con el Datamart. ETL batch: extrae, transforma, carga en ciclos programados. Sincronización orientada a eventos — prioriza por relevancia e impacto.
C3
OC Datamart		 Núcleo del commons. PostgreSQL + pgvector con modelo de acceso por naturaleza. Responde preguntas con contexto histórico. Monitorea patrones, detecta anomalías, identifica dependencias, genera alertas proactivas.
C4a
Conversacional		 IA que responde en lenguaje natural. Recupera, sintetiza y contextualiza información bajo demanda. Ninguno — C4a es puramente reactivo por diseño.
C4b
Agentic		 Orquestación de contexto y proactividad. Coordina múltiples fuentes, añade contexto no solicitado cuando es relevante. Prepara briefings anticipados, detecta patrones de consulta, sugiere próximas preguntas.
C4c
Juicio humano		 Espacio exclusivamente humano. Validar, decidir, asumir responsabilidad. Sin agentes — por diseño y por principio filosófico.
C5
Periferia		 Interfaz entre el commons y las personas. Canal de consulta — la persona pregunta, el commons responde. Canal proactivo — agentes envían briefings y alertas relevantes sin ser solicitados.

Si los agentes del OC empiezan a ejecutar acciones en los sistemas transaccionales, el OC deja de ser una infraestructura de autonomía y se convierte en una infraestructura de control más sofisticada. Ese es el error de diseño que la distinción C4a/C4b/C4c existe para prevenir.

Distinción crítica

OC agentic vs. McKinsey ERP-agentic

Las grandes consultoras describen una visión donde agentes autónomos ejecutan procesos end-to-end en los sistemas transaccionales. Esa visión es coherente — y radicalmente distinta a la del OC. La diferencia no es semántica: define dónde reside la autoridad de decisión.

Agentes McKinsey · ERP agentic Agentes OC · Commons agentizado
Median entre los sistemas y los procesos de negocio Median entre los datos y las personas — no entre personas y decisiones
Ejecutan transacciones y orquestan procesos end-to-end Sincronizan datos, detectan patrones y preparan contexto
Los humanos definen intención, validan resultados, intervienen en excepciones Los humanos toman todas las decisiones significativas
La autoridad de decisión migra a los agentes para los procesos estándar La autoridad de decisión permanece en la periferia humana — sin excepciones
Objetivo: eficiencia operativa — hacer más con menos intervención humana Objetivo: autonomía organizacional — hacer mejor con más información para las personas
Los agentes operan sobre los sistemas transaccionales — modifican registros Los agentes operan sobre el commons — nunca sobre los sistemas fuente
Protocolo operativo de agentización

Cómo un patrón se convierte en un agente

La arquitectura describe dónde operan los agentes. El protocolo describe el proceso por el cual un patrón conversacional se convierte en un agente desplegado. Sin protocolo, la decisión de qué agentizar queda al criterio individual del equipo de centro — y eso reproduce el sesgo del primer modelo que el OC viene a corregir.

Criterio de elegibilidad — cuándo un patrón es candidato

No todo patrón repetido amerita un agente. La agentización tiene un costo de mantenimiento, coordinación y calibración. La elegibilidad opera con un umbral cuantitativo claro.

Criterio Umbral Razón
Frecuencia mínima ≥3 veces por semana Por debajo, el costo de mantenimiento supera el beneficio del agente
Persistencia mínima 4 semanas consecutivas Filtra patrones coyunturales — agendas de proyecto, picos estacionales, eventos puntuales
Estabilidad de forma Inputs y output equivalentes en ≥80% de las consultas Si la pregunta varía en su estructura, no es un patrón — es un tema
Acuerdo de maestría Validación de al menos un referente periférico del dominio El criterio cuantitativo no reemplaza el juicio de quien usa esa información para actuar

Las 5 preguntas del agente — protocolo de especificación

Cuando un patrón es elegible, el equipo de centro responde cinco preguntas antes de la implementación. Si las cinco tienen respuesta clara, el patrón está listo. Si alguna queda ambigua, vuelve al commons conversacional por un ciclo adicional.

P1
¿Qué inputs necesita?

Las fuentes del Datamart que el agente consulta y los parámetros que recibe. Riesgo si queda ambigua: el agente produce respuestas incorrectas por dependencias no documentadas.

P2
¿Qué proceso sigue?

La secuencia de pasos entre los inputs y el output — filtros, agregaciones, reglas de negocio. Riesgo: el agente se vuelve una caja negra que nadie puede corregir.

P3
¿Qué output produce?

Formato exacto del entregable — estructura, longitud, nivel de detalle, idioma. Riesgo: el output requiere reformateo manual cada vez, perdiendo el beneficio de la automatización.

P4
¿Con qué frecuencia corre?

El trigger del agente: temporal (cadencia fija), evento (cambio en sistema fuente), o demanda (solicitud explícita). Riesgo: el agente corre cuando no corresponde o no corre cuando se lo espera.

P5
¿Cuándo necesita intervención humana?

Condiciones bajo las cuales el agente se detiene y escala a una persona — umbrales de excepción. Riesgo: la excepción se procesa como caso normal y el error se propaga sin que nadie lo detecte.

La especificación del agente no es un documento técnico. Es la conversación operativa que la organización necesita tener para definir qué partes de su trabajo pueden ser ejecutadas sin presencia humana — y cuáles no. Esa conversación, hecha cinco preguntas por cinco preguntas, es el verdadero entregable del protocolo.

Taxonomía de agentes

Trigger · Output · Canal

Un agente queda caracterizado por tres dimensiones operativas. Esta taxonomía permite que el equipo de centro hable de los agentes con precisión — sin confundir un agente temporal con uno orientado a eventos, ni un agente que publica en Slack con uno que escribe en un sistema fuente.

TRIGGER · qué activa al agente
Temporal: corre según una cadencia fija (cada lunes 8:00, cada cierre de mes).

Evento: corre cuando un sistema fuente reporta un cambio relevante (un deal entra al CRM, un ticket cambia de estado).

Demanda: corre cuando una persona lo invoca explícitamente desde C5.
OUTPUT · qué produce
Resumen: síntesis de información ya existente en el commons.

Alerta: señal sobre una anomalía o un patrón que merece atención.

Recomendación: sugerencia de acción con justificación basada en datos.

Documento estructurado: entregable formal (propuesta, análisis, informe).
CANAL · dónde aparece el output
Slack / Teams: mensaje al canal del equipo relevante.

Email: comunicación uno a uno o a grupo definido.

Comentario en sistema fuente: el output aparece en el contexto del registro al que se refiere.

Dashboard del commons: el output queda disponible en C5 para consulta posterior.
La ficha de identidad del agente
La combinación de trigger + output + canal es la ficha de identidad de un agente. Dos agentes con la misma combinación son funcionalmente equivalentes — su diferencia está solo en los inputs y el proceso. Esa estandarización facilita el inventario de agentes y la conversación con la dirección sobre qué automatiza el sistema y qué deja explícitamente al juicio humano.
Ciclo de vida del agente

De propuesta a retiro

Un agente no se despliega y permanece igual indefinidamente. Tiene un ciclo de vida que el equipo de centro debe sostener — y la última etapa, el retiro, es tan importante como el despliegue. Un agente que ya no sirve y que sigue corriendo es ruido, no señal.

E1 Propuesta Curador
Un patrón cumple los criterios de elegibilidad. El curador responde las cinco preguntas y produce la ficha del agente con trigger + output + canal.
E2 Validación Curador + referente periférico
La ficha se revisa con un referente periférico del dominio — la persona que va a usar el output del agente para actuar.
E3 Despliegue Custodio técnico
El agente se implementa, se prueba con datos reales, se calibra contra los outputs esperados, y entra en operación.
E4 Operación monitoreada Sensor · 4 semanas
Durante las primeras 4 semanas, el output del agente se acompaña con un feedback explícito de los receptores.
E5 Operación estable Custodio técnico
El agente corre con feedback pasivo. Las correcciones se acumulan y se aplican en revisiones programadas.
E6 Revisión periódica Curador + sensor · cada 6 meses
El equipo de centro evalúa si el agente sigue siendo útil — si su output sigue siendo accionado, si el patrón sigue siendo estable.
E7 Retiro Curador + custodio
Cuando el patrón deja de ser estable o el output deja de ser usado, el agente se retira. Su lógica se documenta — no se borra — por si el patrón reaparece.

El protocolo descrito en esta sección no es un proceso administrativo que el equipo de centro sigue para cumplir. Es la disciplina operativa que distingue un commons agentizado bien diseñado de una colección de scripts que alguien armó porque le pareció buena idea. La diferencia entre las dos cosas es la diferencia entre infraestructura y dependencia.

OC Framework v2.0 | Adaptant