Spoiler: Sabiamos que existia el concepto de “segundo cerebro” pero no recordabamos como se llamaba. Lo buscamos como “DeepBrain”, “G-Brain” y “gBrain” antes de aceptar que era GBrain. Buen comienzo para una herramienta de memoria.

El problema: contratar a un genio con amnesia anterógrada

o incapacidad para formar o retener nuevos recuerdos después de un evento o lesión cerebral

Imagina que contratas al mejor desarrollador del mundo. Resuelve cualquier cosa, lee 200 archivos en segundos, no se queja del café. Pero tiene un único defecto: cada mañana se despierta sin recordar absolutamente nada de lo que hizo ayer. Ni el proyecto, ni por qué decidieron usar PostgreSQL, ni que el cliente odia el azul corporativo.

Ese desarrollador es tu “agente de IA”, el cual cada “mañana” es como iniciar una sesion nueva.

La solución del 90% de la gente es heroica y estúpida en partes iguales: volver a explicarle todo. Cada. Santa. Vez. “Mira, este es un e-commerce de impresión, el pago va después de validar con el cliente, el SKU es inmutable, no toques los precios sin leer el Excel…”. Veinte minutos de tu vida – y unos cuantos miles de tokens de entrada – para poner al genio al día. Mañana, otra vez desde cero.

Hay una alternativa a la terapia de repetición: darle una libreta. Una libreta que busca informacion, vinculos, relaciones, sola.

Qué es GBrain (sin el folleto de marketing)

GBrain es un sistema de memoria para agentes de IA. Técnicamente: una base de conocimiento con búsqueda híbrida (vectorial + BM25 + re-ranking), un grafo que conecta ideas relacionadas, y una capa de síntesis que responde con citas. Se conecta a Claude Code, Cursor o Codex vía MCP.

Traducido al humano: es la libreta del genio amnésico, pero con un bibliotecario adentro. Tú no buscas “el archivo de notas donde definicmos como se le cobrará al cliente”; Tu le preguntas “¿cuándo se cobra el pedido?” y te devuelve la decisión exacta —”pago tras validación, no antes”— sin que tengas que recordar en qué documento estaba.

Lo importante, y lo que casi nadie entiende a la primera: GBrain no es un chatbot ni gasta tu cuota de LLM por existir. Es almacenamiento inteligente. Tu agente decide cuándo consultarlo, igual que tú decides cuándo abrir Google en vez de adivinar.

En nuestra instalación corre en un host dedicado (Linux, 192.168.100.54), sobre PostgreSQL 16 + pgvector, con un detalle de plomería que vale oro: GBrain se ata a 127.0.0.1 por diseño de seguridad, así que pusimos un reenviador socat como servicio de systemd para exponerlo a la LAN sin tocar el binario. Abrir el firewall no servía de nada —el problema nunca es el firewall, normalmente es el puerto de escucha del servicios en modo loopback—. Detalle aburrido, lección cara: la mitad de los problemas de red no son de red.

Por qué NVIDIA paga la cuenta de los embeddings

Acá viene la parte que confunde a todos. Para que la búsqueda semántica funcione, cada fragmento de texto se convierte en un vector —una lista de 1024 números que captura su significado—. A eso se le llama embedding. Y los embeddings hay que generarlos con un modelo de lenguaje o LM.

¿Por qué no usar el mismo modelo que genera el código? Porque sería como contratar a un cirujano para que te corte el pan. Caro, sobrecalificado y absurdo. Generar embeddings es una tarea barata y especializada. Usamos la API de NVIDIA con el modelo bge-m3 (1024 dimensiones), por tres razones nada poéticas:

  1. Ya se dispoene de una key de NVIDIA. Por el momento (junio 2026), NVIDIA provee de acceso a los LM más potentes del mercado y de forma gratuita. con esto solo puedo decir: El mejor presupuesto es el que no gastas.
  2. bge-m3 es multilingüe de verdad. Trabajamos en español, con tildes, con “ñ”, con clientes que escriben “pendón” y “troquel”. Un modelo entrenado solo en inglés te devuelve búsquedas mediocres en cuanto sales del happy path anglosajón.
  3. Y la clave del asunto: los embeddings NO consumen tu cuota de generación. El presupuesto de tokens caro —el que se encarga en que el agente piense y escriba código — queda intacto. Los embeddings los paga otra billetera.

Hubo trampa, claro. GBrain no traía un conector directo a NVIDIA. El “recipe” genérico (litellm) tenía un catch-22 delicioso: exigía declarar las dimensiones del vector, pero rechazaba cualquier valor personalizado. Un formulario que te pide un dato y luego te dice que ese dato no vale. En resumen, una dependencia circular. La salida fue usar el recipe dashscope —que sí acepta 1024 dimensiones— y redirigir su endpoint a NVIDIA por configuración. Es un caballo de Troya elegante: el sistema cree que habla con Alibaba y en realidad habla con NVIDIA. Funcionó. La ingeniería real es 10% diseño y 90% convencer a dos APIs de que se lleven bien.

La matemática del segundo cerebro: dónde ahorras y dónde te clavan

Tener un segundo cerebro ahorra tokens, pero solo si lo usas como bisturí y no como manguera.

El escenario caro (sin GBrain): arrancas la sesión, el agente no sabe nada, así que hace lo único que puede: grep, abrir archivos, leer 4.000 líneas de documentación para entender el proyecto. Cada archivo que lee entra a su contexto. Cada token de entrada se paga. Multiplica eso por cada sesión, por cada proyecto, por cada vez que pierdes el hilo. Es una hemorragia silenciosa.

El escenario barato (GBrain como recall): el agente hace una consulta puntual —”recall: contexto de tarjetea.me”— y recibe de vuelta una síntesis ya digerida. En vez de leer doce documentos enteros, recibe el párrafo que importa. El trabajo pesado —convertir tu pregunta en vector, rankear, encontrar lo relevante— lo hizo NVIDIA por fuera de tu cuota. Pagas un puñado de tokens por el resultado, no un riñón por el contexto completo.

Y ahora la letra chica, porque no tener una receta: el ahorro se evapora si haces las cosas mal. Dos formas de fusilar el presupuesto que tanto cuidaste:

  • Queries glotonas. Si le pides a GBrain “tráeme todo lo del proyecto” y te devuelve 50 fragmentos, acabas de meter al contexto la misma basura que querías evitar, solo que con pasos extra. La búsqueda quirúrgica gana; el volcado de cerebro pierde.
  • Síntesis con LLM cuando no la necesitas. Algunas herramientas de GBrain (ask, think) razonan con un modelo de lenguaje para darte una respuesta elaborada. Eso sí gasta tokens de generación. Para “¿qué decidimos sobre los pagos?” no necesitas que un LLM filosofe: un recall o un search te devuelve el dato crudo, sintetizado al indexar, prácticamente gratis. Reservá la artillería pesada para cuando de verdad necesites conectar puntos entre proyectos.

La regla de oro: almacenar y recuperar es barato; razonar es caro. El segundo cerebro brilla cuando lo usas para recordar, no para pensar por ti. Si cada consulta dispara una síntesis con modelo, no compraste una libreta: contrataste un segundo genio amnésico que cobra por hora.

Los pros y los contras, sin vaselina

A favor:

  • Coherencia en el tiempo. La decisión que tomaste en abril sigue ahí en junio, aunque tú ya la olvidaste. El agente no.
  • Conocimiento que cruza proyectos. “¿Cómo resolvimos el email transaccional en el otro proyecto?” deja de ser un viaje arqueológico por carpetas. Mailtrap por API, no SMTP, decidido y guardado. Listo.
  • Onboarding instantáneo. Una sesión nueva arranca sabiendo quién eres, qué stack prefieres y por qué descartaste MongoDB. Sin reunión de inducción.

En contra (porque nada es gratis):

  • Basura entra, basura sale. Un segundo cerebro mal alimentado es peor que no tener ninguno: te da respuestas confiadas y equivocadas. Memoria desactualizada es desinformación con buena postura.
  • El mantenimiento es real. Hay que decidir qué se guarda, redactar secretos (jamás indexes una API key, por favor), reconstruir el grafo cuando migras la base. No es “instalar y olvidar”.
  • La falsa sensación de orden. Tener un cerebro centralizado no te vuelve organizado, igual que comprar pesas no te vuelve fuerte. Si no defines cuándo escribir y cuándo leer, terminas con un vertedero searchable.

Tips para que no termine siendo un vertedero

  1. Namespaces por proyecto. ppcommerce/*, tarjetea/*, meta/*. Un cerebro sin estantes es una pila de papeles.
  2. Redacta secretos antes de indexar. Passwords, tokens, keys → [REDACTADO]. El segundo cerebro no es una caja fuerte; trátalo como una postal.
  3. Instruye el arranque en el CLAUDE.md. El agente no consulta la memoria por telepatía. Una línea —”al iniciar sesión, haz recall del contexto”— convierte la libreta opcional en reflejo automático.
  4. Guarda decisiones, no narraciones. “Pago tras validación del cliente, no antes” es oro. “Hoy trabajamos en el módulo de pagos” es ruido que caduca en una hora.
  5. El grafo se construye a mano (a veces). Los enlaces entre ideas son lo que distingue una memoria de un cajón. Vale el esfuerzo de conectar “diseño visual” con “lo que contradice del diseño visual”.

Ejemplos al pie del teclado

  • Arrancas una sesión en un e-commerce. Antes de tocar nada, el agente recupera: workflow de pedidos en dos niveles, estados configurables y reordenables, archivos que se borran a los 15 días. No reinventa la rueda; la encuentra ya inflada.
  • Empiezas un proyecto nuevo desde cero. El cerebro ya sabe que prefieres PHP sobre Node para sitios de larga vida, que el email va por API y no por SMTP, y que el SKU es siempre la clave de sincronización. El proyecto nace con criterio heredado, no con amnesia.
  • Vuelves a un proyecto que cerraste hace dos meses. Un recall y estás de vuelta en contexto: la seguridad ya estaba resuelta, la siguiente fase era el billing con Stripe. Cero arqueología.

Cómo Reactiv te ayuda a construir el cerebro de tu empresa

Todo lo anterior fue para un desarrollador y unos proyectos. Ahora escala el problema: una empresa entera de gente que toma decisiones, las olvida, se va de vacaciones, renuncia, o simplemente no le cuenta al de al lado por qué se eligió tal arquitectura. El conocimiento institucional vive en cabezas, en hilos de Slack muertos y en un Confluence que nadie actualizó desde 2023. Esa es la amnesia que de verdad cuesta plata.

En Reactiv integramos memorias centralizadas —segundos cerebros corporativos— como infraestructura, no como juguete:

  • Arquitectura — Diseñamos el esquema antes de tocar nada: qué se guarda, cómo se versiona, quién accede, dónde viven los datos. Un cerebro sin diseño previo es un vertedero con buscador.
  • Ethical Hacking — Una base de conocimiento centralizada es un objetivo jugoso. La probamos ofensivamente antes de que lo haga alguien con peores intenciones.
  • Revisión de Código — Validamos que los secretos se redacten, que los accesos respeten el mínimo privilegio y que la integración con tus agentes no filtre lo que no debe.
  • Remediación — Cuando aparece la grieta —y aparece—, la cerramos. Migraciones de motor, rotación de credenciales, reconstrucción de índices y grafos sin pérdida de conocimiento.

Lo armamos sobre stack que se mantiene solo en el tiempo —Linux, PostgreSQL, PHP, Caddy— y que no te ata a la nube de moda de este trimestre. Porque un segundo cerebro que depende de un servicio que cierra en dos años no es memoria: es una deuda con fecha de vencimiento.

Conclusión

Un segundo cerebro no te vuelve más inteligente. Te vuelve consistente —que, a tres meses de un proyecto, vale más—. Decidir bien una vez y no tener que volver a decidirlo es la diferencia entre avanzar y correr en círculos con buena onda.

Eso sí: úsalo como bisturí, no como manguera. Guarda decisiones, no diarios. Redacta tus secretos. Y por favor, dale un nombre y recuérdalo —es lo mínimo que le puedes pedir a una herramienta de memoria.

gbrainIAsegundo cerebro