Una reestructuración de Profile para la era de la IA.

A — El sustrato de conocimiento

Estructurar toda la información de Profile para que sea legible por máquina. No es “ordenar carpetas”: es diseñar una arquitectura donde cada dato tiene un sitio, un formato y una convención. Sin esto, ningún agente funciona.

Concretamente: Drive reorganizado en formatos nativos de Google, naming conventions, plantillas, una Master Matrix por deal (la ficha estructurada de cada operación) y un Pipeline OS global (un único tablero vivo con el estado de todas las operaciones a la vez).

B — Autonomía con confianza

Decidir qué va solo y qué necesita validación humana. Principio: automatiza el trabajo, nunca la decisión irreversible.

Cada workflow se clasifica por su coste de error y el sistema avanza por una curva de confianza: todo manual (Bloque 1) → lo de bajo riesgo automático (Bloque 2) → estado estable con puertas humanas permanentes donde vuestro criterio es el producto (Bloque 3).

Regla de oro: event-driven sí, silencioso nunca. Cada acción automática se anuncia.

Sandra es la clave de adopción, no Jordi. Sandra hace las operaciones diarias — actualiza el Pipeline, procesa reuniones, gestiona documentación. Si Sandra no adopta el sistema, el Pipeline OS se corrompe y todos los agentes fallan. Su onboarding se diseña por separado.

C — El conocimiento del equipo

Workstream propio. Tres décadas de experiencia que hoy viven en cabezas, no en la empresa: el criterio de matching y la red de Salvador, el razonamiento operativo de Jordi, los procesos del día a día de Sandra.

Principio central: nadie documenta, todos reaccionan. “Escribe lo que sabes” no funciona con ningún perfil. En su lugar: el sistema propone, el equipo corrige. El gap entre propuesta y corrección captura el conocimiento tácito — sin fricción.

• Salvador — solo habla, nunca escribe ni toca una herramienta: transcripción always-on, debrief post-deal, loop de corrección. 2 sesiones de semilla en el Bloque 1.
• Jordi — sus decisiones se capturan vía transcripción y vía las correcciones a los documentos que genera el sistema.
• Sandra — su CLAUDE.md personal recoge los workflows reales que aplica cada día.

El output no es prosa en un Doc: produce 3 activos vivos — el Buyer Graph, el Playbook y la Biblioteca de Patrones — directamente usables por los agentes.

El encuadre correcto: no es “automatizar el equipo”. Es convertir la inteligencia colectiva de Profile en un activo permanente que crece con cada deal y sobrevive a cualquier cambio. Para Salvador, es gestión de sucesión y legado; para Jordi y Sandra, trabajar más rápido sin perder el contexto acumulado.

D — Jordi como power-user (Claude Code track)

Workstream propio. Es lo que hace a Onda un Fractional AI Lead y no un vendor: no instalamos un sistema, elevamos la capacidad del equipo. Jordi ya conoce Claude Code del workshop; lo convertimos en su interfaz de trabajo principal, por fases:

El reframe: enseñar Claude Code a Jordi no hace a Onda prescindible. Usar la herramienta ≠ arquitecturar el sistema. Un Jordi más capaz hace el encargo más valioso, no menos.

6.1 El stack

Por qué Claude Code como interfaz de Jordi (y no Cowork): - Claude Code lleva meses en producción (GA); Cowork tiene 6 semanas de vida. - Capacidades de agente completas + ecosistema MCP completo (Drive, Sheets, Gmail, Chat de forma nativa). - Jordi ya lo conoce — el workshop fue el onboarding. - Las Skills son comandos versionados en el repositorio de Onda → Jordi se beneficia sin escribirlas; a medida que avanza, las edita. - El CLAUDE.md provee contexto persistente, específico de Profile, que sobrevive entre sesiones. - Camino de aprendizaje superior: sandbox → datos reales read-only → co-arquitecto.

Por qué Google Chat como canal de agentes (y no Slack): - Profile es 100% Google Workspace — cero herramientas nuevas que adoptar. - Google Chat Spaces soporta webhooks, bots y la Chat API — suficiente para publicar outputs de agentes e interacciones estructuradas. - Coste incremental cero (incluido en Workspace). - Integración nativa de Apps Script con Sheets y Drive. - Slack añadiría 9€/usuario/mes y una superficie de notificaciones paralela sin ninguna ventaja real al volumen de Profile.

6.2 Catálogo de Skills (Claude Code)

Las Skills son comandos slash que Onda construye, versiona y mantiene en el repositorio. Jordi los ejecuta desde Claude Code. El catálogo de abajo es una propuesta inicial (ver nota * al final).

* Este catálogo es un punto de partida. A medida que el sistema se desarrolle y aparezcan necesidades nuevas, crear una Skill o un comando para cubrirlas es rápido y barato — el catálogo crece con Profile.

CLAUDE.md del workspace de Jordi — mantenido por Onda, contiene: - Contexto del negocio de Profile (tipos de deal, sectores, naming conventions) - Índice de deals activos - Guías de prompt (tono, formato, qué nunca hacer) - Reglas de comportamiento de los agentes

6.3 Los 5 roles de agente

Regla de oro: presentar la capacidad real de cada agente, no la versión aspiracional. El cliente recuerda las expectativas del Día 0.

6.4 Pipelines críticos

Un pipeline crítico es un workflow que se repite en cada deal, consume muchas horas y no admite errores — el núcleo productivo de la firma. Los identificamos por tres criterios simultáneos: alta frecuencia (ocurre en todos los deals), alto coste manual (horas de trabajo cada vez) y alto coste de error (una equivocación se propaga al teaser, al dossier o al cliente). Son los primeros que automatizamos, porque es donde el sistema devuelve más valor y antes. Cuatro en esta fase:

SABI export (.xlsx) → Drive folder (designated)
  ↓ Python (pandas + openpyxl): extract PYG, Balance, 5-year evolution
  ↓ validation: flag missing required fields, fail loudly if SABI format changed
  ↓ Google Sheets API: write tabs FINANCERA, PYG, BALANCE
  ↓ Claude API: generate narrative commentary (1-2 paragraphs per tab)
  ↓ write commentary to RESUMEN tab
  ↓ Google Chat notification (Space: 🤖 AI Agents) → Jordi for validation

Master Matrix (Google Sheet)
  ↓ Google Sheets API: read all relevant tabs
  ↓ structure data as clean JSON context
  ↓ Claude API (per section, not full document at once):
      teaser-executive-summary.md prompt
      teaser-business-description.md prompt
      teaser-financial-highlights.md prompt
      teaser-investment-thesis.md prompt
      [6-8 sections total]
  ↓ Google Docs API: write document with formatting
  ↓ apply format template (headings, tables, font = investment banking)
  ↓ Google Chat notification → Jordi for review and elevation

Cron: Mon-Fri 7:30 AM
  ↓ Routine reads Pipeline OS Sheet (Sheets connector)
  ↓ filters: active deals + next actions + blockers + days stuck
  ↓ generates structured briefing (bullets, not prose)
  ↓ posts to Gmail (primary) + Google Chat Space "🤖 AI Agents" (mirror)
  ↓ n8n fallback at 8:15 AM if no delivery notification

📋 Pipeline Profile — [date]
━━━━━━━━━━━━━━━━━━━━━━━━
🟢 ACTIVOS (N deals)
  · [Deal A] — Etapa: DD | Próximo: reunión comprador 23/05 | Días en etapa: 3
  · [Deal B] — Etapa: Captación | Próximo: enviar teaser | Pendiente: 5 días

⚠️ BLOQUEANTES
  · [Deal C] — Esperando respuesta cliente desde 7 días

📅 ESTA SEMANA
  · [relevant calendar events]
━━━━━━━━━━━━━━━━━━━━━━━━

Meeting capture tool generates transcript → email/Drive
  ↓ Sandra triggers /process-transcript [transcript-url]
     (or Routine detects new transcript → auto-triggers)
  ↓ Claude Code Skill reads transcript (Gmail MCP or Drive MCP)
  ↓ extracts: next steps, decisions made, follow-up date, owners
  ↓ proposes Pipeline OS update (Sandra confirms via Chat before write)
  ↓ Sheets MCP writes to Pipeline OS

6.5 Fuentes de datos — más allá de SABI

Este es un primer mapa de fuentes, no una lista cerrada. SABI es el núcleo desde el día uno; el resto se incorpora de forma incremental. Durante el desarrollo veremos cuáles aportan más señal real para Profile y en qué orden conviene integrarlas.

6.6 Modelo de datos

Master Matrix (una por deal):

Pipeline OS (un Sheet global):

Estructura de la pestaña Agent Logs:

Onda revisa los Agent Logs en cada check-in semanal.

6.7 El motor de matching — dos grafos vivos

El corazón de Profile es cruzar dos cosas: empresas que se venden y compradores que las quieren. El sistema lo modela con dos grafos vivos, no con listas sueltas en Excel.

Buyer Graph — el lado comprador. Una fila por comprador en la pestaña BUYER_GRAPH del Pipeline OS, con columnas estructuradas (sectores, rangos de facturación y EBITDA, geografía, estilo de operación, historial) y una columna libre team_insight para el conocimiento tácito que ningún filtro alcanza.

Company Graph — el lado vendedor: las empresas que Profile representa o ha representado, con sus características estructuradas. Esa información ya vive hoy deal a deal en cada Master Matrix; el Company Graph la consolida en una vista única y consultable.

Profile no tiene “pocas empresas y muchos compradores”: tiene volumen comparable en ambos lados. Por eso el matching es bidireccional:

• Empresa nueva → /buyer-search la cruza con el Buyer Graph y devuelve compradores rankeados, con un párrafo de razonamiento por cada uno.
• Comprador nuevo → el mismo motor recorre el Company Graph y devuelve qué empresas de la cartera encajan.

Comprador (una fila en la pestaña BUYER_GRAPH)
  ├── buyer_id: B001
  ├── sectores_interes: logística | distribución | industria
  ├── rango_facturacion: 2M€–15M€
  ├── rango_ebitda: 200K€–1,5M€
  ├── geografia: Cataluña, noreste de España
  ├── estilo_operacion: buy-and-hold | add-on | turnaround
  ├── contacto: nombre, email, LinkedIn
  ├── historial_deals: PRO-001 | PRO-004
  └── team_insight: "quiere fábricas, no servicios. Máx. 3 directivos."

Cada corrección del equipo a un resultado de matching afina el scoring de ambos grafos. Tras 20 deals, este activo es irreplicable por cualquier nuevo entrante. Trigger de migración: >100 entradas activas en un grafo → base de datos estructurada. Hasta entonces, las pestañas de Sheet bastan y son editables por humanos.

6.8 Observabilidad y fiabilidad

Cada pipeline escribe en Agent Logs. Onda revisa en cada check-in semanal. Si no hay entrada para un evento esperado → alerta a Jordi/Sandra vía Google Chat.

Naming enforcer: script Python (Drive API), ejecutado semanalmente, detecta archivos fuera de la convención de nombres → envía lista de acciones correctoras a Jordi/Sandra vía Chat. No opcional — es la higiene del sistema.

6.9 Seguridad y portabilidad

Tres modos de tratamiento de datos — cada workflow se clasifica en exactamente uno:

Por qué este patrón importa en una boutique M&A: los datos más sensibles (financieros) no pasan por ningún LLM. Las narrativas confidenciales van por API (sin persistencia, sin entrenamiento, garantía contractual). Solo la exploración de menor sensibilidad ocurre en la interfaz de chat. La arquitectura misma garantiza la confidencialidad — no solo la política.

Nota honesta: este sistema depende de Claude (Team + API). Es dependencia gestionada, no ausencia de dependencia. Lo que es siempre portable: vuestro Drive, vuestros Sheets, vuestros documentos. La capa de inteligencia es portable a nivel de prompts.

6.10 Búsqueda inteligente sobre el histórico — milestone Bloque 2/3

A medida que se acumulan deals aparece una necesidad nueva: poder preguntarle al sistema en lenguaje natural — “¿qué operaciones del sector logística hemos cerrado?”, “¿qué compradores encajaron con empresas parecidas a esta?” — y que responda buscando por significado en todo el histórico, no por coincidencia exacta de palabras.

Esa capacidad se llama RAG (búsqueda semántica): una capa que indexa todos los documentos de Profile y permite recuperarlos por lo que dicen, no por cómo se llaman. Es un hito posterior, no del arranque — solo tiene sentido construirlo cuando ya hay suficiente histórico.

Mientras tanto, no hace falta nada de eso. El Master Index — una simple hoja de cálculo con una fila por documento (deal, tipo, sector, facturación, estado, enlace a Drive) — cubre la búsqueda de sobra. Cuando el índice supere ~50 documentos y las búsquedas se vuelvan frecuentes, se construye el RAG sobre una base de datos especializada. Lo dimensionamos en ese momento, con datos reales de uso.

6.11 Captura de reuniones — decisión pendiente

Por qué importa. Hoy, lo que se habla en una reunión vive solo en la memoria de quien estuvo. Si se cierra un punto con un comprador, el resto del equipo solo se entera preguntando. El objetivo es que toda reunión de Profile quede registrada automáticamente en el sistema — transcripción, resumen, decisiones, próximos pasos e insights — para que cualquiera del equipo pueda entender qué se habló sin tener que hablar con los implicados.

El sistema mantiene un repositorio único de reuniones: cada encuentro con su resumen y sus acuerdos, buscable y enlazado a su deal. Es lo que alimenta al agente Secretario y mantiene el Pipeline OS al día.

Esto se hace con una herramienta de captura. No nos comprometemos con una en esta propuesta: la elección se decide en el kickoff, después de que el equipo pruebe un par de ellas en reuniones reales y vea con cuál se siente más cómodo. Cuatro finalistas:

Recomendación: probar Granola y Meetily en la semana 2 del Bloque 1, y decidir al final de esa semana.

6.12 Herramientas power-user (opcionales)

Dictado por voz para Jordi, para acelerar la redacción de prompts y mensajes: Wispr Flow (cloud, pulido, ~12-15€/mes) o Superwhisper (local, Mac-only, máxima privacidad). Opcional. La decisión es de Jordi, no de la arquitectura.

Week 0 — Quick wins (pre-Bloque 1)

“Valor visible antes de que empiece el proyecto formal.”

Antes de arrancar el Bloque 1, una sesión corta ataca el problema más inmediato que identificamos en nuestra llamada: parte del conocimiento de Profile vive en interfaces volátiles, no en la empresa.

El síntoma — un caso concreto que salió en la llamada, con Sandra como ejemplo: se usa ChatGPT a diario, pero no se cierran los chats para no perder el contexto acumulado. Pestañas vivas como única memoria. Es el problema central del proyecto en microcosmos.

La solución inmediata: mover el trabajo a una herramienta con contexto persistente cross-chat — claude.ai Projects — donde el contexto de Profile y las tareas habituales viven de forma estable y no hay que reexplicarlos en cada conversación.

Resultado: quien lo adopte es más productivo desde el día siguiente — y Profile gana su primer trozo de contexto que vive en la empresa, no en una pestaña. Una demostración de valor concreta e inmediata.

Bloque 1 — Fundamentos

“El sistema me ayuda. Yo disparo cada acción. Nada pasa sin mi visto bueno.”

Entregables:

Al final del Bloque 1: Todo es human-triggered. Vosotros disparáis cada acción. El sistema ahorra >5h/semana verificables. Riesgo cero.

Bloque 2 — Automatización

“Lo de bajo riesgo ya va solo. Yo solo intervengo donde mi criterio es imprescindible.”

Entregables:

Al final del Bloque 2: Los workflows de bajo riesgo van solos. Sandra adopta el sistema. Jordi ya no es un usuario: es un co-builder. Salvador tiene el dashboard como vista única del negocio.

Bloque 3 — Inteligencia

“El sistema funciona. Yo me dedico a lo que solo yo puedo hacer.”

Entregables:

Al final del Bloque 3: Profile es una boutique M&A AI-native. 3 personas hacen el volumen de 15. Los deals < 1M€, hoy no rentables, pasan a serlo.

Roadmap

Visión de conjunto del programa. La estructura es firme: Week 0, tres Bloques secuenciales y dos workstreams que corren de forma continua durante todo el proyecto. El arranque previsto es junio 2026; las fechas y duraciones exactas se cierran en la sesión de kickoff.

El calendario es una referencia de borrador. La duración real depende de la dedicación y la inversión que ambas partes pongan en el proyecto: con foco, la transformación puede completarse de forma sensiblemente más rápida. El objetivo compartido es tener el sistema dando valor cuanto antes — no estirar el proyecto.

Roadmap en borrador. El detalle — fecha de inicio, hitos intermedios y duración exacta de cada bloque — se fija en el kickoff una vez cerrado el acuerdo.

El upside del sistema

El sistema se paga solo en el primer deal adicional habilitado. A partir de ahí, todo es upside.

SaaS del cliente (OpEx mensual)

Opcional power-user (no incluido): Wispr Flow / Superwhisper para Jordi (~12-15€/mes).

Cuándo escalar más allá del Bloque 3

Inversión Onda

La propuesta de inversión concreta — estructura, importe y modalidad de pago — se presenta en la próxima sesión una vez validados los timings y el alcance definitivo de cada bloque.

Benchmark de referencia: el sistema se financia con los honorarios de 1 deal adicional habilitado en el año 1. A partir del segundo deal adicional, todo es margen incremental.