Skip to content

Roadmap y Visión — Cornerstone

Este documento describe la evolución de Cornerstone dentro del plan de modernización de DeAcero. Para el estado actual ver general_architecture.md.

El contexto: F3 "Agents operate"

El roadmap de la Plataforma de Datos y Analítica de DeAcero está estructurado en 4 fases. Cornerstone es la infraestructura que habilita la fase final:

gantt
    title Roadmap Plataforma D&A — DeAcero 2026
    dateFormat YYYY-MM
    section Plataforma de Datos
    F0 "Stop the bleeding"    :done, 2026-01, 3M
    F1 "Replace the engines"  :active, 2026-03, 3M
    F2 "Make it fast"         :2026-07, 3M
    F3 "Agents operate"       :2026-10, 3M
    section Cornerstone
    ARE + primeros agentes    :done, 2026-01, 3M
    MCP Replication Monitor   :active, 2026-03, 3M
    Agentes governance+calidad :2026-07, 3M
    11 MCP agents producción  :crit, 2026-10, 3M

F3 "Agents operate" (Oct-Dic 2026) — el objetivo declarado: 11 agentes MCP en producción, menos de 40 horas/mes de firefighting, 50+ usuarios en autoservicio. Cornerstone es la plataforma desde la que se construyen y operan esos agentes.

Los 11 agentes MCP target (F3)

Célula Agente Propósito Fase
Data Engineering Replication Monitor Monitoreo y auto-healing de streams F1
Data Engineering dbt Operator Trigger, consulta, backfill de dbt F2
Data Engineering Pipeline Doctor Diagnóstico automatizado de fallos F3
Data Engineering Cost Optimizer Análisis semanal de costos BigQuery F3
Data Governance Metadata Sync Sincronización dbt → Dataplex F2
Data Governance Schema Guardian Proteger de schema changes no autorizados F2
Data Governance Quality Auditor Quality checks proactivos F2
Data Governance Lineage Tracker Linaje end-to-end actualizado F2
Reporting Dashboard Generator Crear/clonar dashboards Looker F3
Reporting Metric Catalog Consultar métricas y definiciones F3
Reporting Export Agent Exportación self-service con quality checks F3

Cada uno de estos agentes será un proyecto scaffoldeado con Cornerstone, con sus propios ADRs, skills especializados, y telemetría conectada al Observability Service central.

El gap central: distribución de conocimiento

El problema que Cornerstone resuelve hoy de forma parcial:

HOY — distribución estática
────────────────────────────────────────────────────────
deagentic/cornerstone
└── {{project_slug}}/
    ├── .agents/skills/   ← COPIA en cada proyecto generado
    └── tools/            ← COPIA en cada proyecto generado

Problema: cuando un skill se actualiza en el template,
los proyectos existentes no se enteran → drift garantizado.

SOLUCIÓN ACTUAL — sync automático
────────────────────────────────────────────────────────
tools/sync_agents.sh (UserPromptSubmit hook, 24h throttle)
→ gh repo clone deagentic/cornerstone --depth=1
→ rsync .agents/skills/
→ misma interfaz, actualización automática

FUTURO — KDB Central
────────────────────────────────────────────────────────
Knowledge Database
├── skills con versioning semántico
├── tools auto-creadas via service account GitHub
├── reglas de negocio extraídas de Confluence + ADRs
└── aprendizajes acumulados por sesión

sync_agents.sh → cornerstone sync --from-kdb (mismo contrato, backend KDB)

Componentes planificados

1. CLI cornerstone completo (corto plazo)

El CLI es la capa de orquestación del ecosistema. Hoy existe cornerstone report. Los subcomandos planificados:

cornerstone sync     # sync skills/tools desde deagentic/cornerstone (o KDB)
cornerstone status   # diagnóstico: ADR gate, telemetry, MCPs, última sync, gh auth
cornerstone deploy   # levanta services/observability/ en 192.99.38.188
cornerstone graph    # genera diagrama Mermaid dinámico del proyecto actual
cornerstone report   # reportes del Observability Service (ya existe)

cornerstone graph — en lugar de diagramas de arquitectura hardcodeados (que se vuelven obsoletos), escanea .agents/skills/ y tools/ en tiempo real y genera el Mermaid:

cornerstone graph > docs/general_architecture.md
# El diagrama siempre refleja el estado real del proyecto

2. Observability Service — Deployment (corto plazo)

services/observability/ está completo. El deployment planificado usa el servidor existente:

Servidor:  192.99.38.188
Stack:     Docker Compose (ya instalado, nginx-proxy activo)
Servicios: postgres:16-alpine + FastAPI + uvicorn
URL:       http://192.99.38.188:8000

Activación org-wide:
  Configurar AGENTIC_TELEMETRY_URL como GitHub org secret
  → todos los proyectos empiezan a reportar automáticamente
  → sin cambios de código en los proyectos existentes

Una instancia central, identificación por project_slug.

El Observability Service responde directamente a la necesidad de Track C (SRE) del roadmap de plataforma: dashboards E2E, alertas, y métricas de health de los agentes IA — complementando Datadog para la capa de agentes.

3. Métricas de adopción — alineación con KPIs de plataforma

El Observability Service provee métricas directamente alineadas con los KPIs de la Plataforma D&A:

KPI de Plataforma Evento Cornerstone Métrica
ROI de plataforma skill.invoked Costo USD por equipo/modelo/skill
Índice de Madurez (4.5 meta) knowledge.created ADRs + skills creados por proyecto
Adopción de agentes project.generated Proyectos nuevos por período
Quality gates ci.run ADR gate pass rate por proyecto
Reducción firefighting ci.run CI pass rate trend

4. ADR Gate — Rollout al resto de equipos

El mandato ADR-first está en evaluación en el proyecto ARE. Plan de adopción:

Fase Alcance Criterio de entrada
Evaluación Proyecto ARE En curso — validando workflow sin bloqueos innecesarios
Adopción inicial Nuevos proyectos con Cornerstone Post-validación ARE
Rollout Todos los proyectos deagentic Cuando Cornerstone sea estándar de facto

El ADR gate es el mecanismo técnico que implementa el Manifiesto de Desarrollo de DeAcero (regla 11: "cada solución requiere diagrama de componentes") y los lineamientos técnicos (SMOD): código con trazabilidad completa de decisiones.

5. MCPs pendientes de configuración

El wiki de DeAcero lista 6 MCPs por configurar que, una vez activos, estarán disponibles en todos los proyectos Cornerstone:

MCP Impacto para Cornerstone
BigQuery Acceso a DWH de producción desde agentes — habilita dbt Operator y Cost Optimizer
dbt Linaje de transformaciones — habilita Schema Guardian y Quality Auditor
SQL Server Análisis directo de bases legacy — complementa SQUIT para los 250+ servidores
Airflow / Cloud Composer 2 Orquestación de pipelines desde agentes — habilita dbt Operator
Dataplex Catálogo universal — habilita Metadata Sync y Lineage Tracker
gcloud Operaciones GCP — habilita deploy, monitoring, y gestión de recursos

Cada MCP activo se refleja en el .env del proyecto y en cornerstone status.

6. Knowledge Database — KDB (largo plazo)

La KDB es el componente que eventualmente reemplaza la distribución estática del template:

graph TB
    subgraph kdb["KDB Central"]
        SEM["Búsqueda semántica\nsobre todo el conocimiento acumulado"]
        MCP_KDB["MCP propio\ncontexto en cualquier proyecto"]
        AUTO["Auto-creación de tools\nvia service account GitHub"]
    end

    subgraph sources["Fuentes de conocimiento"]
        ADR_SRC["ADRs de todos los proyectos"]
        CONF["Confluence — 117 espacios\nPDYA2 · MDE · ARQ · DYG..."]
        SK["Skills del ecosistema"]
        LEARN["Aprendizajes de sesión\nlearning-protocol"]
    end

    subgraph consumers["Proyectos Cornerstone"]
        ARE["Proyecto ARE"]
        MCP_AGT["11 agentes MCP"]
        OTROS["Proyectos futuros"]
    end

    sources --> kdb
    MCP_KDB --> consumers

La KDB unifica el conocimiento distribuido en 117 espacios de Confluence, 645 repos de Bitbucket, y los ADRs de todos los proyectos — haciéndolo consultable semánticamente desde cualquier sesión de agente.

Evolución del sync — mismo contrato, diferente backend:

HOY                                    FUTURO
─────────────────────────────          ─────────────────────────────
cornerstone sync                       cornerstone sync
  gh repo clone cornerstone    →         MCP query → KDB
  rsync .agents/skills/                  skills + reglas de negocio
                                         + aprendizajes acumulados

Alineación con el Plan de Modernización de DeAcero

Cornerstone es el vehículo técnico que conecta la misión deagentic ("comprimir tiempo y costo de modernización via Agentic Pipelines") con el plan estratégico de la Plataforma D&A (Índice de Madurez 4.5, $884M MXN en pipeline de proyectos):

graph LR
    subgraph vision["Visión estratégica DeAcero"]
        COE["CoE D&A\nMaturity 4.5 — 2026"]
        ROI["$884M MXN\nen pipeline"]
        F3["F3: Agents operate\n11 MCP agents"]
    end

    subgraph cornerstone["Cornerstone habilita"]
        ARCH["Archaeology Pipeline\nEntender 250+ SQL Servers\n13M líneas de código"]
        INFRA["Infraestructura agentic\nADR-first · Skills · Telemetría"]
        OPS["Operación autónoma\n11 agentes MCP scaffoldeados"]
    end

    ARCH --> COE
    INFRA --> F3
    OPS --> ROI

Los principios que guían esta evolución:

  1. Opt-in, zero-impact — ningún componente nuevo rompe proyectos existentes. La ausencia de AGENTIC_TELEMETRY_URL siempre es un no-op silencioso.
  2. Mismo contrato, evolución de backend — sync_agents.sh hoy usa gh clone; mañana el MCP de la KDB. La interfaz del script no cambia.
  3. Un proyecto, un project_slug — el Observability Service es una instancia central. La identidad del proyecto es el slug.
  4. General antes que específico — cualquier skill o tool creado para un proyecto debe generalizarse y subirse a deagentic/cornerstone. Lo específico del dominio vive en el proyecto; lo reutilizable en el template.
  5. Mermaid dinámico — ningún diagrama de arquitectura es estático. cornerstone graph genera el diagrama desde el estado real del proyecto.