Resumir contenido con:
Base de conocimientos frente a System Prompt: ¿dónde debe ir cada pieza de información?
La respuesta corta: el system prompt controla el comportamiento, la base de conocimientos suministra conocimiento, una herramienta durante la llamada obtiene datos en tiempo real de tus sistemas y el constructor de flujos impone una secuencia fija. Estas cuatro capas no son intercambiables. Si las mezclas, terminarás con un agente que responde más lentamente, que cuesta más por llamada de lo necesario y que debe volver a probarse desde cero cada vez que cambia un precio.
Observamos el mismo patrón repetidamente con los clientes de Famulor. Una empresa comienza con un system prompt limpio y breve. Tres meses después, contiene 40 respuestas de preguntas frecuentes, la lista de precios completa, horarios de apertura de las tres sedes y una lista de 60 variantes de productos. El agente sigue funcionando, pero responde con mayor lentitud, sigue la estructura de la conversación de forma menos fiable y nadie se atreve a cambiar nada.
Este artículo te ofrece una matriz de decisión: qué información pertenece a cada capa, por qué y qué te cuesta cuando te equivocas. Si acabas de empezar, merece la pena echar un vistazo primero al agente de voz con IA sin código y a los conceptos básicos en la documentación.
Las cuatro capas de contexto de un agente de voz con IA
Todo agente de voz en producción extrae sus respuestas de cuatro fuentes claramente distinguibles. La diferencia decisiva es cuándo se carga cada pieza de información.
- System prompt: se carga al completo en cada llamada y se evalúa durante toda la conversación. Siempre activo, siempre determinista, siempre pagado en tokens.
- Base de conocimientos: se recupera solo cuando el contexto de la conversación activa una búsqueda. Escala a grandes volúmenes de texto sin saturar el prompt.
- Herramienta durante la llamada: llama a una API durante la conversación y devuelve valores exactos y actuales. Es la única capa que puede calcular, ordenar y escribir datos.
- Constructor de flujos: define la ruta de la conversación en lugar de dejarla en manos del modelo. Para secuencias donde el orden no es negociable.
Regla de oro: el prompt es el cerebro de tu agente, no su enciclopedia. Todo lo que moldea el comportamiento pertenece a su interior. Todo lo que simplemente se consulta pertenece al exterior.
Cuándo el system prompt es la elección correcta
El system prompt es la base determinista. Está presente en cada llamada, independientemente de lo que diga el interlocutor. Por eso, solo deben estar ahí las cosas que siempre deben aplicarse.
Incluye en el system prompt:
- Rol y tono: quién es el agente, para qué empresa habla, cómo suena. Un agente de recepción para una asesoría contable suena diferente a un agente de llamadas salientes para instalaciones solares.
- Lógica y secuencia de la conversación: saludo, orden de las preguntas de seguimiento, cuándo abrir y cuándo cerrar.
- Salvaguardas: lo que el agente nunca debe hacer. Sin asesoramiento legal, sin compromisos de precios vinculantes, sin diagnósticos por teléfono.
- Reglas de escalado: cuándo transferir a un humano, cuándo ofrecer una devolución de llamada.
- Respuestas estándar breves y estables: tres a cinco objeciones que surgen a diario y que siempre deben responderse de la misma manera.
- Activadores para lógica estructurada: cuándo se invoca cada herramienta durante la llamada y con qué parámetros.
En concreto: una clínica dental con seis gabinetes escribe en el prompt que el agente siempre debe preguntar primero a los pacientes con dolor sobre la urgencia y transferir inmediatamente los casos agudos a recepción. Eso es comportamiento. Qué huecos están libres el jueves, por el contrario, no vive en el prompt, sino que proviene del calendario. La guía de system prompt muestra cómo estructurar un prompt de forma limpia.
Cuándo gana una base de conocimientos
Una base de conocimientos almacena texto largo y no estructurado y solo se busca cuando la conversación lo hace necesario. El agente no lleva permanentemente 20 páginas de documentación; recupera la sección relevante bajo demanda.
Incluye en la base de conocimientos:
- Documentación de soporte y producto: guías prácticas, resolución de problemas, pasos de configuración.
- Colecciones de preguntas frecuentes largas o que cambian con frecuencia: cualquier cosa que supere aproximadamente una docena de preguntas, especialmente cuando los equipos especializados mantienen el contenido.
- Políticas y lenguaje contractual: políticas de devolución, términos de garantía, avisos de privacidad donde la redacción exacta importa.
- Reglas regionales o específicas de segmento en prosa: por ejemplo, diferentes compromisos de servicio por ubicación, siempre que no haya nada que calcular.
La verdadera ganancia es organizativa. La base de conocimientos separa la materia del contenido de la lógica de comportamiento. Tu equipo de servicio puede actualizar una condición de garantía sin que nadie toque el prompt y arriesgue el comportamiento conversacional.
Los límites son igual de claros. Una base de conocimientos no puede calcular, no puede ordenar y no puede extraer de forma fiable valores individuales de una tabla de precios. Y como la recuperación depende del contexto, no es totalmente determinista: dos conversaciones similares pueden acceder a pasajes ligeramente diferentes. Para preguntas de conocimiento es inofensivo. Para números vinculantes, no lo es.
Cuándo solo funciona una herramienta durante la llamada
Tan pronto como el agente necesite un valor exacto y actual o tenga que cambiar algo en un sistema externo, no hay otra opción que una herramienta durante la llamada. Llama a una API durante la conversación y recibe una respuesta precisa.
Casos típicos:
- Datos estructurados en sistemas externos: campos de CRM, estado del pedido, plazo del contrato, nivel de stock por sucursal.
- Valores personalizados en tiempo real: saldo pendiente, próxima cita disponible, estado de entrega.
- Lógica condicional: si el tipo de cliente es empresa y el código postal está dentro del área de servicio, ofrece la opción B.
- Operaciones de escritura: crear un lead, reservar una cita, cambiar una dirección, abrir un ticket.
- Cálculos y umbrales: criterios de cualificación, descuentos por volumen, tarifas de desplazamiento.
Un ejemplo del sector de oficios: una empresa de fontanería con 14 técnicos de campo hace que el agente compruebe en cada llamada de emergencia si el código postal entra en el área de servicio y si hay un técnico disponible hoy. Ambos son valores en tiempo real. Si intentas resolver esto con una base de conocimientos, el agente prometerá ocasionalmente un trabajo al que nadie puede acudir. La implementación técnica se cubre en herramientas personalizadas durante la llamada, y la conexión con tu software existente se realiza a través de las integraciones de Famulor.
Cuándo el constructor de flujos toma el control
El constructor de flujos es la cuarta capa y el punto ciego en la mayoría de las comparaciones. Define la ruta de la conversación explícitamente en lugar de dejarla al modelo de lenguaje. Esa es la decisión correcta siempre que la secuencia no sea negociable por razones legales u operativas.
- Preguntas obligatorias: registro de consentimiento, identificación antes de la divulgación, verificación de edad.
- Captación tipo formulario: notificación de siniestros, admisión de pacientes, pre-cualificación de candidatos con campos fijos.
- Ramificación con puntos finales claros: tres tipos de solicitud, tres cierres diferentes.
La diferencia con el prompt: un prompt pide al modelo que siga una secuencia. El constructor de flujos la impone. Para una pregunta de consentimiento, eso no es una diferencia de conveniencia, sino de cumplimiento normativo.
La matriz de decisión de un vistazo
| Criterio | System prompt | Base de conocimientos | Herramienta durante la llamada | Constructor de flujos |
|---|---|---|---|---|
| Tipo de contenido | Comportamiento, tono, reglas | Prosa larga, documentación | Datos estructurados en tiempo real | Secuencia y orden |
| Cuándo se carga | Siempre, en cada llamada | Solo con contexto coincidente | Solo al invocar la herramienta | Dirige la conversación |
| Frescura de los datos | Según la última edición del prompt | Según la última indexación | Tiempo real | No aplicable |
| Coste de tokens por llamada | Alto y constante | Bajo, solo en recuperación | Bajo, solo datos de respuesta | Bajo |
| Impacto en la latencia | Aumenta el tiempo de procesamiento permanentemente | Breve retraso en la recuperación | Depende de tu API | Mínimo |
| Determinismo | Alto | Medio | Muy alto | Muy alto |
| Puede calcular y ordenar | No | No | Sí | No |
| Puede escribir datos | No | No | Sí | Vía herramientas |
| Mantenido por | Propietario del agente | Equipo de expertos en la materia | Equipo de IT o integraciones | Propietario del proceso |
| Caso de uso típico | Regla de escalado | Términos de garantía | Consultar citas libres | Capturar consentimiento |
Lo que realmente cuesta elegir la capa equivocada
El coste de una arquitectura de contexto deficiente aparece en tres lugares, y ninguno llega en una factura etiquetada como mala decisión.
Primero, los tokens. El system prompt se procesa en cada llamada. Un prompt que crece de 800 a 6.000 palabras hace que cada llamada sea más cara, independientemente de si el interlocutor necesita esa información adicional o no. Con 40 llamadas al día, pagas ese recargo 40 veces diariamente, incluso si solo dos personas preguntan por los términos de la garantía. Cómo se traduce el uso en facturación se cubre en los documentos de precios basados en el uso.
Segundo, la latencia. Por teléfono, la espera es brutalmente visible. No hay barra de carga, solo silencio. Cuanto más contexto procesa el modelo para cada respuesta, más tiempo tarda en producir la primera sílaba. Un prompt saturado ralentiza cada respuesta en la conversación, mientras que una recuperación de la base de conocimientos solo retrasa la respuesta donde realmente se necesita.
Tercero, el esfuerzo de mantenimiento. Este es el elemento más caro y el que más a menudo se pasa por alto. Si los precios viven en el prompt, cada cambio de precio es una intervención en la lógica de comportamiento del agente y requiere una ronda completa de pruebas. Si los precios provienen de una herramienta durante la llamada que lee tu sistema de inventario, un cambio de precio es simplemente un cambio de precio.
Calcula para tu propia situación cómo el volumen de llamadas, el tiempo medio de gestión y el coste del personal afectan al caso de negocio:
Calcula tu ROI automatizando llamadas
Descubre cuánto podrías ahorrar al usar voice agents con IA.
Resultado ROI
ROI 0%
Sin tarjeta de crédito
Implementación en cuatro pasos
- Haz inventario. Exporta tu system prompt actual y etiqueta cada párrafo con C para comportamiento, K para conocimiento o D para datos. Todo lo que no sea C es candidato a ser reubicado.
- Saca el conocimiento. Mueve todos los bloques K a una base de conocimientos y dale una descripción precisa para que el agente sepa cuándo buscar en ella. Una descripción vaga es la razón más común por la que la recuperación nunca se activa.
- Conecta los datos. Para cada bloque D, comprueba si existe una API. Los calendarios, CRM, inventarios y sistemas de tickets suelen poder conectarse a través de integraciones existentes o una herramienta personalizada durante la llamada. Todo lo que el agente recopile durante la llamada, guárdalo en variables y pásalo en forma estructurada.
- Bloquea las rutas obligatorias. Cualquier cosa que legalmente deba ocurrir en un orden específico se mueve al constructor de flujos. Luego, prueba con grabaciones de llamadas reales, no con diálogos de muestra inventados.
Un buen objetivo tras la limpieza: el system prompt cabe en dos o tres pantallas y no contiene ni un solo número que pueda cambiar.
Errores comunes en el campo
- Precios en el prompt. El clásico. Los precios cambian, los prompts rara vez se actualizan limpiamente y el agente cita cantidades obsoletas con total confianza durante meses.
- Horarios de apertura en el prompt. Funciona exactamente hasta el primer festivo o cierre de empresa. Los horarios son datos, no reglas de comportamiento.
- Base de conocimientos para tablas. Poner tablas de precios y descuentos escalonados en una base de conocimientos produce respuestas que suenan plausibles pero que están mal ensambladas. Las tablas pertenecen detrás de una herramienta.
- Descripción de la base de conocimientos demasiado vaga. Si el agente no sabe qué cubre la fuente, nunca la consulta y responde desde el conocimiento del modelo.
- Todo en el constructor de flujos. El extremo opuesto. Guioniza cada ruta y volverás a un menú telefónico, solo que con mejor voz. Usa rutas fijas solo donde sean realmente necesarias.
- Sin regla de respaldo. Para el caso en que una herramienta no responda o la base de conocimientos no encuentre nada, el agente necesita una instrucción clara en el prompt: admítelo limpiamente, ofrece una devolución de llamada, no adivines.
Tres ejemplos del sector
Asesoría contable con unos 400 clientes. El prompt lleva el tono, la regla de que nunca se da asesoramiento fiscal por teléfono y el escalado al gestor responsable. La base de conocimientos lleva explicaciones de plazos y documentos requeridos por tipo de caso. La herramienta durante la llamada proporciona el estado del cliente y los huecos de consulta libres. El constructor de flujos gestiona la identificación antes de cualquier divulgación.
Tienda Shopify con unos 5.000 pedidos al mes. El prompt gobierna el tono y el límite en las decisiones de cortesía. La base de conocimientos contiene la política de devoluciones y las instrucciones de retorno. La herramienta durante la llamada extrae el estado del pedido y el seguimiento del envío. El constructor de flujos guía a los interlocutores a través del registro de devoluciones para que no se pierda ningún campo obligatorio.
Concesionario de coches con taller y ventas. El prompt dirige a los interlocutores a servicio o ventas y define cuándo transferir a un asesor comercial. La base de conocimientos contiene intervalos de servicio y alcance de la garantía. La herramienta durante la llamada suministra huecos libres en el taller y disponibilidad de vehículos. Más configuraciones específicas del sector se enumeran en sectores.
Conclusión
La arquitectura de contexto no es un detalle. Es la diferencia entre un agente que dura tres meses y uno que escala durante tres años. La regla es simple: comportamiento al prompt, conocimiento a la base de conocimientos, datos detrás de una herramienta, secuencias obligatorias al constructor de flujos. Unas fronteras claras entre estas capas hacen que tu agente sea más rápido, más barato y, sobre todo, mantenible por las personas que ya poseen el contenido.
Si estás limpiando un agente existente, empieza con el inventario de la sección de implementación: exporta el prompt, etiqueta cada párrafo como C, K o D, y mueve todo lo que no sea C. En la mayoría de los casos, el prompt se reduce a más de la mitad. Con Famulor construyes las cuatro capas sin código en la misma interfaz y mantienes el control total sobre el coste, la latencia y el mantenimiento. Tienes disponible una visión general de los planes en la página de precios.
Prueba nuestro Asistente de IA
Experimenta lo natural que suena nuestro asistente telefónico de IA.
Introduce tus datos y recibe una llamada de nuestro agente de IA en segundos.
El agente está entrenado para hablar sobre los servicios de Famulor y programar citas.
Agente IA de demo
Representante de Famulor
FAQ
¿Qué pertenece al system prompt y qué no?
El prompt debe contener el rol, el tono, la lógica de conversación, las salvaguardas y las reglas de escalado. No debe contener precios, horarios de apertura, colecciones largas de preguntas frecuentes o cualquier cosa que pueda cambiar sin que el comportamiento necesite cambiar.
¿Cuándo necesito una base de conocimientos en lugar de un prompt más largo?
Tan pronto como tengas más de una docena de respuestas de preguntas frecuentes, o estés integrando texto que mantiene un equipo especializado. La base de conocimientos se recupera solo cuando es necesario y, por tanto, no carga cada llamada.
¿Por qué no debería poner precios en la base de conocimientos?
Porque una base de conocimientos encuentra texto pero no calcula y no puede extraer de forma fiable celdas individuales de las tablas. Los precios, niveles y disponibilidad pertenecen detrás de una herramienta durante la llamada con una respuesta de API exacta.
¿Aumenta una base de conocimientos la latencia de mi agente de voz?
Solo en las respuestas donde realmente se recupera. Un system prompt saturado, por el contrario, ralentiza cada respuesta en toda la conversación.
¿Cuál es la diferencia entre el constructor de flujos y el system prompt?
El prompt pide al modelo que siga una secuencia. El constructor de flujos la impone técnicamente. Para el consentimiento, la identificación y los campos obligatorios, esa diferencia es decisiva.
¿Qué tamaño puede tener un system prompt?
No hay un límite estricto, pero un buen objetivo son dos o tres pantallas. Cualquier cosa más allá de eso casi siempre significa que el conocimiento o los datos han migrado al prompt.
¿Puedo usar las cuatro capas en Famulor sin un desarrollador?
Sí. El system prompt, la base de conocimientos, las herramientas durante la llamada y el constructor de flujos son configurables a través de la interfaz. Hay más de 300 integraciones disponibles para conectar tus datos.
¿Qué sucede si una herramienta durante la llamada no responde durante la conversación?
El agente necesita una regla de respaldo explícita en el system prompt. El patrón sensato es nombrar el valor faltante abiertamente y ofrecer una devolución de llamada o transferencia en lugar de adivinar.
¿Cómo pruebo si mi arquitectura de contexto funciona?
Prueba con grabaciones de llamadas reales en lugar de ejemplos inventados. Presta especial atención a si la base de conocimientos se activa realmente en las preguntas que esperas.
Autor en Famulor