Conocimiento de empresa para agentes de IA: una fuente, todos los agentes

El conocimiento de empresa para agentes de IA es un conjunto consultable de decisiones, procedimientos y datos que permite a los agentes responder a partir de lo que tu empresa sabe de verdad. Tu empresa ya tiene un cerebro. Lo que pasa es que no está por escrito. El trabajo no es comprar un chatbot para cada herramienta. El trabajo es poner ese conocimiento por escrito en un solo sitio y dejar que todos los agentes lo consulten de la misma forma. Al terminar conocerás las cuatro piezas y tendrás escritas tus primeras entradas. Los pasos 1 y 2 te llevan una tarde.

Qué es el conocimiento de empresa para agentes de IA

Una base de conocimiento encerrada en una sola herramienta de chat es el siguiente silo. El patrón tiene cuatro piezas y ninguna depende de un proveedor:

Esta guía forma parte de Loops We Run. La guía principal, cómo dirigimos nuestra empresa con agentes de IA, muestra el resto.

El conocimiento vive en un solo sitio, un pipeline mantiene el índice al día y todos los agentes llegan a él a través de un único servidor MCP.

No entrenas ningún modelo

«Entrenar la IA con nuestros datos» es la idea equivocada. Un buen agente consulta antes de responder, como alguien recién contratado con el manual abierto. Esa consulta es la recuperación: el agente envía la pregunta a una herramienta de búsqueda, lee los pasajes que le devuelve y responde a partir de ellos citando la fuente. No se reentrena nada. Para cambiar una respuesta, cambia la entrada.

Te presentamos Larchmoor Cycles, la tienda inventada de nuestros ejemplos

Todos los ejemplos usan Larchmoor Cycles, una tienda de bicis ficticia con taller de reparación y alquiler.

Paso 1: elige un área y apunta las preguntas que debe responder tu conocimiento

Empieza por las preguntas que la gente ya hace. Una base de conocimiento construida a partir de un inventario de documentos responde a preguntas que nadie se hace. Elige un área y apunta las preguntas que clientes y equipo han hecho sobre ella este mes, con sus propias palabras.

Larchmoor elige alquileres y devoluciones. La lista de Maren:

1. ¿Puedo devolver un casco que me probé en la tienda?
2. ¿Cuánto es la fianza de una bici de alquiler?
3. ¿Qué pasa si devuelvo una bici de alquiler dañada?
4. ¿Me podéis devolver el dinero en vez de darme un vale?
5. ¿Cuánto se tarda en arreglar los frenos?
6. ¿Abrís los domingos?

Guarda la lista: es la prueba del paso 6.

Paso 2: pon lo que sabe tu empresa en un solo sitio

Escríbelo en el momento en que ocurre, un dato por entrada, o no se escribirá nunca. Hoy lo que sabe Larchmoor vive en la cabeza de Maren, en su bandeja de entrada y en tres documentos antiguos.

Un solo sitio guarda dos tipos de contenido y, juntos, forman la base de conocimiento de tu empresa para agentes de IA. La documentación cubre los procedimientos, las políticas y los precios que ya tienes por escrito: returns-policy, rentals, repair-prices, opening-hours. Las entradas apuntadas recogen las decisiones, los procedimientos y los datos que la gente aprende mientras trabaja. Cada entrada tiene un título, el dato, por qué es así, un responsable, una fecha de última revisión, un ámbito y, si caduca, una fecha de validez.

title:  Rental deposit is 100 per bike
fact:   Every rental bike takes a 100 deposit, refunded when it comes back undamaged.
why:    Chose 100 over 50 because a bent wheel costs about 100 to replace.
owner:  Maren
scope:  public

Cada entrada guarda un dato que un agente puede usar por sí solo, con su ámbito y, si caduca, una fecha.

Para una revisión completa de tus datos, lee preparar tus datos para la IA. Para la memoria entre sesiones de programación, consulta por qué Claude Code olvida el contexto.

¿Quieres que lo montemos con tu equipo? Cuéntanos qué preguntas te hacen cada semana tus clientes y tu equipo.

Paso 3: haz que se pueda buscar por significado

Los clientes nunca usan tus palabras, así que buscar solo por palabras les falla.

Dividimos cada documento en pasajes de unos 8000 caracteres, cortados al final de una frase, con 200 caracteres compartidos entre pasajes vecinos. 8000 es lo bastante grande para que quepa una regla entera con su excepción. El solapamiento de 200 evita que una frase quede partida por la mitad. Cada pasaje se guarda con su fuente, título y fecha de última actualización, y se convierte en un embedding.

Un embedding es una lista de números que recoge lo que significa un pasaje. Dos textos que significan lo mismo reciben números parecidos, aunque no compartan ninguna palabra.

La búsqueda puntúa a la vez el significado y las palabras, y combina ambas puntuaciones en una única clasificación. Esto es búsqueda semántica complementada con coincidencia de palabras. El significado encuentra «Devoluciones de equipo de protección» para un cliente que escribió «casco». Las palabras siguen ganando con referencias de piezas, nombres y precios. Si la búsqueda por significado no está disponible, la búsqueda recurre a las coincidencias de palabras y marca el resultado como degradado, así que el agente sigue respondiendo. Usa un servicio de búsqueda que ya tengas, o cualquier índice vectorial o híbrido.

La pregunta dice casco y el pasaje dice equipo de protección; la búsqueda por significado lo pone el primero igualmente.

Paso 4: mantén el índice al día con un pipeline

Un índice de hace una semana responde con los precios de la semana pasada. El pipeline importa más que el motor de búsqueda. Un documento largo se vuelve a leer al actualizarse: cuando se añade por primera vez o cuando alguien guarda una versión nueva y pide al sistema que lo vuelva a leer. Nada lo vuelve a leer por su cuenta.

El pipeline se activa con dos disparadores:

Cero pasajes escritos es un fallo, nunca un «completado». La ejecución indica una causa y lo intenta una vez más. El id de cada pasaje se forma con su fuente más una huella de su texto, así que ejecutar el pipeline dos veces nunca crea copias.

Paso 5: da a todos los agentes una sola vía de acceso: un servidor MCP

Todos los agentes se conectan a través de un único servidor, y lo que pueden ver lo decide su acceso, nunca su pregunta. MCP (Model Context Protocol, el protocolo de contexto de modelos) es un estándar abierto que permite a un agente de IA llamar a herramientas de un servidor. Un agente nuevo se conecta sin que haya que reconstruir el conocimiento para él.

El servidor de conocimiento de Larchmoor tiene una sola herramienta de solo lectura, search_knowledge, que recibe una pregunta y un límite de resultados. Por defecto devolvemos los 5 mejores pasajes: suficientes para que el agente compare fuentes y lo bastante pocos para leerlos enteros. Cada resultado incluye posición, puntuación, título, fuente, fecha de última actualización y un fragmento.

Cada entrada tiene un campo scope, y el servidor filtra cada búsqueda según el acceso del agente que se conecta (su clave o inicio de sesión). El chat de la tienda solo ve public; el Claude de Teo y el ChatGPT de Maren ven public e internal. Ningún cliente puede llegar a las entradas internas a base de preguntar.

Cualquier agente que hable MCP se conecta con la dirección del servidor y una clave o un inicio de sesión. Una pregunta que no tiene nada que ver no devuelve nada, y la instrucción de Maren le dice al chat que lo diga en vez de inventárselo.

Paso 6: haz preguntas reales, con una ejecución paso a paso

Prueba con preguntas reales y arregla el conocimiento, nunca la respuesta. Una pregunta de la lista de Maren, paso a paso:

1. Un cliente en larchmoor.example.com pregunta al chat: «¿Puedo devolver un casco que me probé en la tienda?».
2. El chat llama al servidor MCP. Su clave lleva el ámbito public.

search_knowledge(query="return a helmet tried on in the shop", limit=5)

3. El servidor devuelve 3 pasajes clasificados:

El agente consulta una herramienta MCP y recibe pasajes clasificados, cada uno con su fuente, antes de escribir la respuesta.

4. El chat responde a partir del pasaje 1: «El equipo de protección sin usar se puede devolver en un plazo de 30 días con el tique. La política no cubre el equipo probado en la tienda, así que he pasado tu pregunta al equipo». Fuente: política de devoluciones.
5. Eso es un hueco, no una mala respuesta. Maren decide y escribe una entrada, con ámbito public: «Los cascos probados en la tienda se pueden devolver en un plazo de 30 días si no se han usado fuera». Por qué: los clientes se prueban tallas en la tienda.
6. La entrada se indexa al guardar. El índice pasa de 40 a 41 pasajes.
7. Con la misma pregunta, la entrada de Maren sale ahora la primera, y el chat responde a partir de ella citando su fuente.
8. Teo le pregunta a su Claude, con ámbito internal: «¿Cómo montamos neumáticos tubeless en una bici de alquiler?». La entrada del procedimiento sale la primera. No se reconstruyó nada para el segundo agente.

Una pregunta aprueba cuando la respuesta cita una entrada, nombra su fuente y esa entrada es el único sitio donde está escrita la regla. Haz lo mismo con cada pregunta de tu lista del paso 1.

Qué sale mal y la regla que dejó cada fallo

Todos los fallos que nos encontramos fueron silenciosos: algo parecía indexado o al día y no lo estaba.

La lista de revisión también recoge cualquier entrada usada en 5 búsquedas o más y no revisada en 90 días. Convertir fallos en reglas es un ciclo propio: crea un sistema de IA que mejora solo.

Dos entradas que se contradicen dan dos respuestas; sustituye la antigua, reindexa y pon fecha a los datos que caducan.

¿Quieres que lo construyamos para tu empresa?

Lo difícil es empezar. Después, escribir entradas se convierte en costumbre. En Neomanex construimos contigo la base de conocimiento, el pipeline y el servidor MCP, conectados a los agentes que ya usas. Tu equipo sigue escribiendo las entradas. Cuéntanos qué preguntas se repiten cada semana.