La memoria institucional de laburen.com. Vive en archivos, la leen los LLMs, la escribimos entre todos.
Es una memoria colectiva donde guardamos lo que va pasando en la empresa — llamadas con clientes, decisiones que tomamos, sesiones de trabajo, novedades. Los archivos están en formato de texto simple, organizados de manera que Claude (y otras AIs) puedan leerlos y respondernos preguntas sobre ellos. Lo importante: cualquier respuesta que te dé la AI se puede verificar abriendo el archivo concreto del que la sacó. No inventa, no adivina.
Cuando Claude te responde algo, te dice de qué archivo concreto lo sacó. Lo abrís, lo chequeás. Cero "el modelo alucinó".
No usa búsquedas por similitud que tiran resultados aproximados. La AI lee archivos concretos según lo que le preguntás.
Son archivos de texto comunes (.md). Cualquiera puede abrirlos y leerlos. No hace falta software especial.
Le hablás a Claude como a una persona. Los skills (instructivos que la AI sigue) se ocupan de la parte técnica por vos.
No es un producto comprado. Lo construimos para que el conocimiento no se nos pierda entre Asana, mails, WhatsApp y cabezas.
Los skills ya están listos en la cuenta de Claude de la empresa: ya los tenés disponibles sin instalar nada. Lo único que hace falta es conectar Claude al brain.
Es un link público pero con seguridad: solo entran cuentas con dominio @laburen.com. Lo copiás del recuadro de abajo.
Vas a Settings → Connectors → Add custom connector, pegás el link y le das conectar. Claude lo reconoce y te pide que te identifiques.
Te va a abrir el login de Google. Usás tu mail @laburen.com. Cualquier otro dominio queda afuera. Listo: ya tenés el brain como herramienta dentro de Claude.
Dos verbos, una idea grande. Vos pedís en lenguaje natural, Claude se encarga del resto. Los ejemplos de abajo son largos a propósito: cuanto más contexto le des desde el primer mensaje, mejor te va a entender. Cinco palabras de más al inicio te ahorran tres idas y vueltas.
La AI lee primero el índice general, después decide qué archivos consultar y te responde diciéndote cuáles miró. Mientras más específica sea tu pregunta (qué team, qué cliente, qué período), más precisa la respuesta. Si no sabe, te dice "no encontré X" — no inventa.
Le pegás texto crudo y la AI lo organiza. Pero ayudala desde la primera línea: decile quién sos, de qué team, sobre qué cliente/agente/proyecto. Si esa info no está clara, la AI tiene que preguntar, y eso son vueltas que te podés ahorrar.
Estas son las cinco cosas que se pueden ingestar hoy. Ningún tipo es exclusivo de un team: Ventas carga llamadas, Growth carga sesiones de contenido, Delta carga sesiones técnicas, Eco carga llamadas y updates de cliente, Alpha carga decisiones y discovery.
| Entidad | Cuándo cargarla | Ejemplo |
|---|---|---|
| Sesion | Después de trabajar 1–4hs focalizado en algo. Cualquier team, con o sin AI. | "Sesión de Juan (alpha) trabajando en la bubble pública: implementación E2E del JWT de visitante + verificación con Playwright. Siguiente paso: validar con cliente." |
| Llamada | Después de cada reunión con un contacto del cliente. Importa quién la condujo, qué se decidió. | "Quarterly review con BaitPisos: revisión de resultados del Q1, decisión de ampliar el piloto al marketplace, próxima sync en 2 semanas, riesgo de cambio de stakeholder." |
| Decisión | Cuando una decisión es lo suficientemente importante como para que dentro de 3 meses alguien quiera saber por qué se tomó. | "Pasamos el classifier a temperatura 0.2 — contexto del problema, opciones consideradas, qué decidimos, consecuencias esperadas y cómo lo vamos a medir." |
| Bitácora | Al cierre del día. Una entrada por día por persona. No se reescribe — solo se agrega. | "Hoy (Facundo, delta): trabajé en el creador de usuarios simulados de evals-app, me trabó la generación de personalidades, mañana sigo con eso." |
| Update cliente | Cuando cambia algo del cliente: estado, contactos, contexto. No es una llamada — es un cambio de estado. | "BaitPisos pasó de prospecto a firmado, contrato Pack Pro, kickoff la semana que viene, contacto principal pasa a ser Lucía." |
Esta es probablemente la pata más importante del brain. Cada cliente vive en su propia carpeta, y ahí adentro está todo: quiénes son, qué hacen, cómo ganan plata, quiénes son sus stakeholders, qué jerga usan, qué reglas tienen, qué decisiones tomamos juntos, qué llamadas hubo. Hoy esa información vive repartida en cabezas de Eco y Ventas — y por eso Delta tiene que pedirla cada vez, los nuevos arrancan de cero y los clientes sienten que "les contamos lo mismo de nuevo". Pasar eso a archivos es la sesión de hoy.
# todo lo del cliente, junto: clientes/{nombre-del-cliente}/ ├── overview.md # quiénes son, estado, contactos, sales lead ├── contexto.md ★ modelo de negocio + glosario + reglas + rituales ├── status.md # estado actual (lo regenera un skill) │ ├── personas/ # contactos del cliente, c/u con su rol │ ├── per-NN-cfo.md │ ├── per-NN-tech-lead.md │ └── per-NN-usuario-final.md │ ├── calls/ # cada llamada con compromisos y decisiones │ ├── 2026-05-12-quarterly-review.md │ ├── 2026-05-20-techsync.md │ └── 2026-05-27-escalation.md │ ├── ventas/ # historial comercial │ └── decisiones/ # ADRs específicos de este cliente └── 2026-04-12-piloto-en-marketplace.md
Lo más importante que cargues hoy es probablemente contexto.md — ese archivo es el que te permite onboardear gente nueva sin tener que estar repitiendo.
El skill se encarga. Le decís "vamos a crear el cliente X, te cuento…" y arma la carpeta entera con todos los sub-archivos necesarios.
Es el documento de relevamiento. Tiene seis secciones canónicas (las que vas a ver acá abajo). Se va completando de a poco — no hace falta tenerlo todo el día uno.
La CFO Lucía no es un string suelto en algún archivo: tiene su propio archivo en personas/ del cliente, con su rol, si es decisora, si es sponsor. Eso permite preguntarle al brain "¿con quién hablamos en BaitPisos para temas técnicos?".
Estas son las secciones que vive el contexto.md de cada cliente. No hace falta llenar todo el día uno — se completa de a poco a medida que aprendemos.
Industria, sub-industria, operaciones core, canales por los que venden, su escala. Sin esto, cualquier propuesta nuestra está adivinando.
Sponsor, decisores técnicos, decisores económicos, usuarios finales. Cada uno con su rol y su nivel de decisión. Te ahorra preguntar "¿esta persona puede aprobar esto sola?".
Si en sus calls dicen "pedido directo", "OC", "tarja" o nombres internos de sus productos, queda acá. Lo que en una nueva sesión te ahorra veinte minutos de "¿qué significa eso?".
Reglas duras: legales, de marca, de seguridad, de tono. "No mencionar competencia", "tono siempre formal", "GDPR aplica", "no se puede tocar la facturación". Estas reglas son las que más caro salen si nadie las sabe.
Weeklies los martes 10am hora México, canal preferido WhatsApp Business, escalan a CFO si pasa una semana sin respuesta. Las cosas chicas que hacen que la relación funcione.
Enlaces a las decisiones importantes que dieron forma a la relación: por qué arrancamos con el agente X y no con Y, por qué se pausó el piloto Z, qué objeción importante se resolvió.
Ejemplos concretos para mapear hoy un cliente. Notá cómo cada uno arranca dando contexto rico: quién sos, qué cliente, qué parte querés actualizar. Cinco palabras al inicio te ahorran tres vueltas.
El protagonista principal es el Agente (porque atraviesa todos los teams y responde la pregunta "¿tenemos algo que resuelva X?"). El Cliente es el contenedor comercial donde viven sus llamadas y contexto. Las sesiones de trabajo viven adentro de la persona que las hizo, no del agente — y se conectan con todo lo demás vía enlaces internos.
# brain/ brain/ ├── AGENTS.md # contrato del KG (lee toda AI) ├── INDEX.md # geografía top-level + contadores ├── relevamiento.md # contexto del negocio │ ├── 00-meta/ # convenciones, schemas, taxonomías │ ├── ontology.md # fuente de verdad: qué entidades hay │ ├── conventions.md # naming, IDs, fechas, frontmatter │ ├── id-registry.md # IDs reservados │ ├── frontmatter-schemas/ # 11 schemas YAML │ └── taxonomies/ # vocabularios controlados │ ├── clientes/{cli-NNN-slug}/ │ ├── overview.md # entity page │ ├── contexto.md # modelo de negocio del cliente │ ├── status.md # DERIVADO — no editar │ ├── personas/ # contactos del cliente │ ├── calls/ # llamadas (cualquier team) │ └── decisiones/ │ ├── agentes/{agt-NNN-slug}/ │ ├── overview.md │ ├── implementacion/ # spec, prompt, tools, reglas │ ├── deployments/ │ ├── relevamiento/ │ └── resultados/ │ ├── personas/interno/{per-NNN-slug}/ │ ├── overview.md │ ├── status-actual.md # DERIVADO │ ├── bitacora/ # append-only │ └── sessions/ # append-only, cualquier team │ ├── teams/ # growth · ventas · eco · delta · alpha ├── conocimiento/ # integraciones · playbooks · conceptos └── indices/ # REGENERABLES — vistas materializadas
Una vez que entendés estas tres, el resto se deduce solo.
No el Cliente. El Agente atraviesa los teams y responde la pregunta "¿tenemos algo que resuelva X?". Un mismo agente puede correr en varios clientes a la vez (cada instancia es un "deployment").
No adentro del agente. Esto permite que dos personas de distintos teams trabajen sobre el mismo agente sin pisarse — sus sesiones quedan en sus respectivas carpetas y los índices las agrupan automáticamente.
Sesiones, llamadas, bitácoras y decisiones no se editan después de cargadas. Si hay corrección, se crea una entrada nueva que referencia la anterior. La historia queda intacta — sabés qué se pensó antes y qué cambió.
Cuando una sesión menciona a un cliente, un agente o una persona, ese vínculo se guarda como un enlace interno (algo así como un link de Wikipedia entre artículos). Eso convierte al brain en una red: desde cualquier punto podés saltar a todo lo relacionado, sin tener que buscar a mano.
Una sesión donde una persona del equipo Alpha trabajó sobre el agente de un cliente en su instancia de producción aparece desde cuatro lugares distintos: desde la carpeta de la persona, desde la del agente, desde la del cliente y desde la del deployment.
Esto significa que Ventas puede saber qué prometió Delta, Delta puede saber qué contexto conoce Eco, y Growth puede saber qué decisiones se tomaron antes de un launch — sin tener que preguntarle a nadie.
Este es el "encabezado" que el skill kb-ingest escribe automáticamente — vos no lo tipeás, lo arma él:
--- id: ses-005 type: sesion fecha: 2026-05-27 session_type: working-session autor: "[[per-003-juan]]" team: alpha agente: "[[agt-001-baitpisos-ml]]" cliente: "[[cli-003-baitpisos]]" deployment: "[[dep-002-bp-prod]]" integraciones_tocadas: - "[[int-mercadolibre]]" next_steps: - "validar con BaitPisos antes de prod" summary: > Implementación E2E del JWT de visitante para la bubble pública. ---
Vos no tipeás nada de esto. Vos decís "cargá esta sesión al brain, soy Juan del equipo alpha, trabajé en la bubble pública…" y el resto lo arma el skill: le asigna ID, encuentra tu carpeta, escribe el archivo y actualiza los índices.
Antes vivía repartido entre Asana, GitHub, mails, grupos de WhatsApp, llamadas que nadie transcribió y cabezas que olvidan. Cada onboarding empezaba de cero, cada cliente sentía que "le contábamos lo mismo de nuevo", cada decisión olvidada se re-discutía tres meses después. Esto resuelve eso — pero solo si lo escribimos juntos.
Los nuevos no preguntan "¿qué pasa con el cliente X?" — abren el brain y leen. El tiempo que tardan en aportar valor cae a una fracción.
Las decisiones quedan con su contexto, las opciones que se consideraron y las consecuencias esperadas. Nadie re-discute lo ya cerrado por olvido.
Los enlaces entre archivos hacen que un cambio en un cliente afecte la vista de quien sea que lo toque. No hay silos.
Si Claude te dice algo, te dice de qué archivo lo sacó. Lo abrís, verificás. Cero "el modelo alucinó".
El brain arma la historia por vos. No tenés que reconstruirla en tu cabeza ni en un doc nuevo.
¿Falta un tipo de entidad? ¿Una categoría nueva? ¿Una relación que el brain no captura? Se charla y se agrega. Esto se construye entre todos.
La diferencia entre un brain útil y un brain que nadie mira está en cómo se carga. La regla más importante: más contexto siempre es mejor.
El contexto está fresco. Si esperás, perdés los porqués y queda solo el "qué". El brain sirve por los porqués.
"Tuve call con BaitPisos" no sirve. "Tuve call con BaitPisos, hablamos del agente ML-atención, decidimos pasarlo a piloto, Juan queda a cargo, próxima review en 2 semanas, hay riesgo de cambio de stakeholder del lado del cliente" — eso es oro. La AI no te juzga por escribir largo.
No tenés que aprender la parte técnica — el skill arma todo. Pero ayudalo: en vez de decir cargá esto al brain, decí cargá esta sesión mía al brain, soy [nombre] del equipo [team], es sobre [agente/cliente/proyecto]: [texto]. La AI está hecha para preguntar si le falta algo crítico — pero cada vuelta de pregunta-respuesta es tiempo que perdés. Cinco palabras de contexto al inicio te ahorran tres idas y vueltas.
Claude está armado para activarlos automáticamente, pero igual: decir usá kb-search o cargá con kb-ingest al principio de tu mensaje lo orienta de entrada. No cuesta nada y evita que se mande a hacer algo distinto.
Las decisiones que se quedan adentro del resumen de una sesión se pierden a los 2 meses. Pedile a la AI formalizá esa decisión como ADR y te crea una Decisión separada que vive en su propio archivo.
Si el texto que cargás los tiene, la AI te avisa y los omite. Esos van al vault de secrets, no al brain.
Decile a Claude explicame cómo funciona kb-ingest o explicame la ontología. Los skills están versionados en la org y la AI te los lee y los explica como si fuera tu mentor. No hay magia escondida.
¿Falta un tipo de entidad (ej. "Contrato")? ¿Una categoría nueva? ¿Una relación que el brain no captura? Se charla con quien mantiene el brain y se agrega primero a la ontología, después al resto. Esto se construye entre todos.
La pregunta de oro al cargar algo: "¿alguien que entre en 3 meses va a entender esto?". Si la respuesta es no, agregale contexto.
Las dudas más comunes. Si la tuya no está acá, le preguntás a Claude — el skill está documentado y te lo explica.
kb-ingest lo convierte a markdown con frontmatter,
reserva el ID, encuentra el path canónico y escribe el archivo. Si querés ver cómo quedó, lo abrís — es legible
como cualquier texto plano.
team del frontmatter dice de qué team es la sesión.
ontology.md (el documento que define qué tipos de cosas existen), después se le crea
una plantilla en frontmatter-schemas/, después se actualizan los skills. No se crea
por sorpresa: una entidad sin contrato es un archivo huérfano que nadie va a encontrar.
explicame el skill kb-ingest (o kb-search). Los skills están en la
cuenta de Claude de la empresa y la AI los lee y te los explica como si fuera un mentor. Si querés
ir más profundo: mostrame el SKILL.md de kb-ingest y te lo abre. Y si querés cambiar algo,
lo charlás con el equipo y se modifica.
@laburen.com autenticadas vía Google. El servidor rechaza
cualquier otro dominio. Para revocar acceso a alguien, se desactiva su cuenta de Google y
deja de poder entrar.
qué hay en el brain o mostrame un resumen general. Hoy
está arrancando: 5 personas internas, 7 sesiones y 1 bitácora cargadas. Falta cargar el grueso
de clientes, agentes, llamadas y decisiones — y eso es justamente lo que esta presentación busca
empezar a destrabar.
No hay un equipo de "knowledge management" que llene esto por nosotros. Lo llenamos nosotros — cada llamada que se carga, cada decisión que queda registrada, cada sesión que se documenta — es valor que ya no se pierde. Cada onboarding que se acorta es tiempo ganado. Cada decisión que no se re-discute es energía liberada.
┌──────────────────────────────────────────────────────────────────────────┐ │ laburen.com · company-brain · v0.2.0 │ │ │ │ → MCP https://ca-company-brain.agreeableriver-8a6b0b11 │ │ .eastus.azurecontainerapps.io/sse │ │ │ │ → AUTH @laburen.com vía Google OAuth │ │ → SKILLS kb-ingest · kb-search (ya en la org) │ │ │ │ built by us, for us. │ └──────────────────────────────────────────────────────────────────────────┘