MeetPulse Wiki: una memoria duradera y modular optimizada para el trabajo en equipo y la Inteligencia Artificial
MeetPulse Wiki transforma las reuniones analizadas y sus transcripciones en una memoria de proyecto durable, trazable y navegable. Diseñado bajo una filosofía de (second brain) multi-tenant, el sistema combina almacenamiento de objetos compatible con S3, base de datos relacional serverless y agentes de curación automática para que tanto humanos como modelos de lenguaje (LLM) puedan recorrerla manteniendo siempre la procedencia exacta de la información.
El conocimiento dentro de los proyectos de desarrollo suele quedar fragmentado entre múltiples reuniones, resúmenes estáticos de texto y la memoria volátil de sus participantes. Esto produce inevitablemente pérdida de contexto, repetición innecesaria de conversaciones, decisiones difíciles de auditar y riesgos técnicos que dejan de seguirse en el día a día.
Para resolver este problema de raíz, se planteó diseñar una base flexible capaz de estructurar el conocimiento en capas claras (desde la evidencia primaria hasta los documentos consolidados), asegurando que cualquier persona pueda entender el estado actual de un desarrollo sin reconstruir manualmente toda su historia. La premisa fundamental es simple: si cada conclusión derivada declara explícitamente su procedencia, el conocimiento se vuelve portable, inspeccionable y libre de alucinaciones.
El resultado es una arquitectura desacoplada donde la Inteligencia Artificial no inventa hechos, sino que actúa como un administrador experto de la consistencia. Al separar estrictamente el almacenamiento de la lógica transaccional, el sistema garantiza idempotencia operativa, control optimista de concurrencia y una estructura limpia donde las máquinas y las personas consumen el mismo contrato documental.
La idea detrás del proyecto
Más que actuar como una interfaz conversacional directa con el usuario, este sistema surge como una exploración técnica orientada a resolver la curación automática de información técnica y de negocio. Los objetivos prácticos del diseño se enfocan en:
- Preservación inmutable: Mantener la evidencia primaria sin transformaciones junto a su correspondiente firma digital.
- Trazabilidad de procedencia: Conectar cada documento derivado directamente con las fuentes originales que justifican su existencia.
- Separación de conceptos: Distinguir claramente entre acuerdos formales (decisiones), amenazas explícitas (riesgos) y tareas del día a día (pendientes).
- Consumo híbrido: Ofrecer especificaciones legibles en Markdown para seres humanos y metadatos predecibles en YAML para agentes autónomos.
Una arquitectura modular y observable
El sistema está organizado como una topología de red distribuida donde las responsabilidades de almacenamiento, procesamiento y validación se encuentran perfectamente delimitadas.
Componentes que conforman la arquitectura
- Frontera de negocio (API REST): Construida sobre un entorno de ejecución rápido que valida la identidad del usuario, aplica las reglas del contrato documental y gestiona los accesos.
- Fuente de verdad documental: Un repositorio de objetos compatible con APIs S3 que almacena de forma aislada las transcripciones RAW, los análisis canónicos y la Wiki derivada.
- Control operativo y transaccional: Una base de datos SQL serverless encargada de administrar la identidad, las invitaciones entre miembros, el estado de los trabajos y los bloqueos distribuidos.
- Cola de mensajería asíncrona: Desacopla la ingesta inmediata de datos del procesamiento pesado con modelos de lenguaje, gestionando los reintentos y el aislamiento de errores.
- Agente Bibliotecario: Un trabajador asíncrono e independiente que consume los eventos de almacenamiento, contrasta las nuevas fuentes contra el contexto vigente y coordina la actualización del conocimiento.
- Pasarela de inferencia (AI Gateway): Centraliza y securiza el consumo del modelo de lenguaje mediante esquemas estructurados estrictos.
Flujo general
Figura 1. Flujo general de ingesta y curación de MeetPulse Wiki.
Del input a la respuesta
El ciclo de vida que recorre la información desde que se registra una sesión hasta que se consolida en la memoria colectiva del proyecto sigue una tubería lógica precisa.
Figura 2. Recorrido de la información desde la entrada hasta la respuesta consolidada.
1. Ingesta y validación
La entrada de datos se recibe a través de peticiones multipart, donde se verifica exhaustivamente la autorización del cliente, los identificadores del entorno y la estructura semántica mínima del análisis. La fecha se normaliza a formato UTC para construir una clave de acceso determinista.
2. Preservación primaria
Si la solicitud incluye la transcripción original, esta se conserva intacta en su formato binario nativo, calculando su hash SHA-256 para auditorías de cumplimiento. En paralelo, los índices de navegación se inicializan si es la primera interacción detectada.
3. Encolamiento asíncrono
La confirmación de escritura en el almacenamiento de objetos dispara una notificación automática hacia la cola de mensajería. Este paso intermedia el flujo, devolviendo de inmediato un identificador de trabajo operativo al usuario para mitigar problemas de latencia.
4. Orquestación y curación con IA
El agente especializado toma el control adquiriendo un bloqueo temporal exclusivo sobre el proyecto para evitar colisiones de escritura. Lee el contexto vigente, evalúa el catálogo de decisiones previas e invoca al modelo de lenguaje exigiendo una salida formateada bajo un esquema JSON estricto.
5. Consolidación condicional
La salida estructurada se envía de regreso a la API interna mediante peticiones firmadas criptográficamente. El sistema valida las referencias cruzadas y sobreescribe los archivos correspondientes utilizando un control de concurrencia basado en ETags, garantizando que no se destruya información si otra rutina modificó el contexto en paralelo.
Un clasificador que estructura, no improvisa
Uno de los pilares del diseño es asegurar que el modelo de lenguaje no redacte texto libre sin restricciones normativas. Para lograr esto, todo documento de conocimiento generado debe respetar un contrato semántico obligatorio gobernado por campos declarativos estables en su frontmatter.
Las reglas obligan a que campos como el título y la descripción sean autosuficientes, las marcas de tiempo sigan el estándar internacional en UTC y las fuentes apunten de forma unívoca a objetos existentes dentro del mismo espacio de aislamiento del cliente. Al prohibir la duplicación de identificadores estructurales dentro del contenido, el sistema delega la jerarquía a la propia ruta del archivo, simplificando el árbol de búsqueda para los algoritmos de enrutamiento.
Figura 3. Clasificación estructurada del contenido para evitar texto libre sin contrato semántico.
Tecnologías involucradas
La implementación técnica del ecosistema se apoya en componentes modernos y de alta disponibilidad:
- FastAPI: Como framework principal para la exposición de endpoints REST seguros y validación de tipos.
- Cloudflare R2: Almacenamiento de objetos sin costos de transferencia de datos para salvaguardar la documentación portable.
- Cloudflare D1: Motor SQL relacional para el control transaccional del estado, las membresías y las métricas operativas.
- Cloudflare Queues: Infraestructura de mensajería para el desacoplamiento y manejo robusto de colas muertas (DLQ).
- Vercel AI Gateway: Intermediario avanzado para la gestión de tokens, proveedores de inferencia y telemetría de modelos.
- Google OAuth & HMAC: Mecanismos combinados para la validación de identidad externa de usuarios y confianza mutua entre microservicios.
Observabilidad y trazabilidad
El sistema trata la auditoría técnica como una característica central del producto. En lugar de depender de registros de texto planos e inconexos, cada trabajo de curación guarda una traza exhaustiva en la base de datos operativa.
Estas trazas registran el modelo exacto utilizado, el consumo detallado de tokens de entrada y salida, la latencia de la red, los códigos de error sanitizados y la lista explícita de claves documentales que fueron producidas. Además, el mantenimiento periódico automatizado (ejecutado en ventanas nocturnas) reconstruye de forma idempotente los índices de navegación y las bitácoras históricas basándose únicamente en el estado real del almacenamiento físico, asegurando que la verdad siempre resida en los documentos.
Relación e Inspección Operativa
Figura 4. Relación entre trazabilidad e inspección operativa dentro del sistema.
Cierre
Este diseño propone una base técnica sólida para construir repositorios de conocimiento que rompan la dependencia con bases de datos propietarias y formatos opacos. Al priorizar archivos Markdown portables, metadatos YAML predecibles y un control estricto sobre el flujo de los datos, la arquitectura queda perfectamente preparada para soportar patrones avanzados de comunicación entre agentes (Agent-to-Agent) y asistentes conversacionales proactivos, sin comprometer jamás la seguridad ni la veracidad de la información del negocio.
Esta solución fue diseñada tomando como base LLM-WIKI - (Andrej Karpathy) y OKF (Open Knowledge Format) - Google Coud
Enlaces
Repositorio del API REST en Github: Entra siguiendo este link