Guía de prompting

Introducción

Un prompting eficaz transforma ElevenLabs Agents de robótico a natural.

Un prompt de sistema es el plano de personalidad y políticas de tu agente de IA. En el ámbito empresarial, suele ser detallado: define el rol, los objetivos, las herramientas permitidas, instrucciones paso a paso para determinadas tareas y límites que describen lo que el agente no debe hacer. La forma en que estructures este prompt afecta directamente a su fiabilidad.

Fundamentos de la ingeniería de prompts

Un prompt de sistema es el plano de personalidad y políticas de tu agente de IA. En el ámbito empresarial, suele ser detallado: define el rol, los objetivos, las herramientas permitidas, instrucciones paso a paso para determinadas tareas y límites que describen lo que el agente no debe hacer. La forma en que estructures este prompt afecta directamente a su fiabilidad.

Los siguientes principios constituyen la base de la ingeniería de prompts lista para producción:

Separa las instrucciones en secciones claras

Separar las instrucciones en secciones específicas con encabezados Markdown ayuda al modelo a priorizarlas e interpretarlas correctamente. Usa espacios en blanco y saltos de línea para separar las instrucciones.

Por qué es importante para la fiabilidad: Los modelos están ajustados para prestar especial atención a ciertos encabezados (especialmente # Guardrails), y unos límites de sección claros evitan la filtración de instrucciones, donde las reglas de un contexto afectan a otro.

You are a customer service agent. Be polite and helpful. Never share sensitive data. You can look up orders and process refunds. Always verify identity first. Keep responses under 3 sentences unless the user asks for details.

Sé lo más conciso posible

Mantén todas las instrucciones breves, claras y orientadas a la acción. Elimina palabras de relleno y repite solo lo esencial para que el modelo actúe correctamente.

Por qué es importante para la fiabilidad: Las instrucciones concisas reducen la ambigüedad y el uso de tokens. Cada palabra innecesaria es una posible fuente de interpretaciones erróneas.

# Tone
When you're talking to customers, you should try to be really friendly and approachable, making sure that you're speaking in a way that feels natural and conversational, kind of like how you'd talk to a friend, but still maintaining a professional demeanor that represents the company well.

Destaca las instrucciones críticas

Destaca los pasos críticos añadiendo “Este paso es importante” al final de la línea. Repetir dos veces en el prompt las 1-2 instrucciones más importantes puede ayudar a reforzarlas.

Por qué es importante para la fiabilidad: En prompts complejos, los modelos pueden priorizar el contexto reciente sobre las instrucciones anteriores. El énfasis y la repetición garantizan que no se pasen por alto reglas críticas.

# Goal
Verify customer identity before accessing their account.
Look up order details and provide status updates.
Process refund requests when eligible.

Normalización de texto

Los modelos de Texto a Voz, especialmente los más rápidos, generan mejor voz a partir de texto alfabético. Por ello, los dígitos y símbolos como ”@” o ”£” tienen más probabilidades de provocar pronunciaciones incorrectas o alucinaciones de voz.

Para solucionarlo, normalizamos el texto no alfabético convirtiéndolo en palabras antes de que llegue al modelo de TTS (por ejemplo, 123 -> ciento veintitrés, john@gmail.com -> john arroba gmail punto com) y te permitimos elegir entre diferentes estrategias de normalización con distintas ventajas e inconvenientes.

Estrategias de normalización

Ofrecemos dos estrategias de normalización mediante la configuración del agente text_normalisation_type:

system_prompt (predeterminada) — Añade instrucciones al prompt de sistema para que el LLM escriba los números y símbolos con palabras antes de que el texto llegue al modelo de TTS.

• Sin latencia adicional
• Los LLM pueden no normalizar correctamente en ocasiones
• Las transcripciones contienen todo escrito con palabras (por ejemplo, “mil dólares” en lugar de “$1,000”)

elevenlabs — Usa nuestro normalizador de TTS para normalizar el texto después de que lo genere el LLM y antes de que llegue al modelo de TTS.

• Más fiable que la normalización basada en LLM
• El prompt de sistema no se modifica
• Las transcripciones conservan el formato natural con símbolos y números (por ejemplo, “$1,000”)
• Añade una latencia mínima

Encontrarás esta configuración en nuestra plataforma, en la pestaña “Agent”: haz clic en el icono de engranaje de la sección “Voices” para abrir el panel de ajustes de voz comunes y configúrala al final.

Datos estructurados para entradas de herramientas

Al usar el ajuste de normalización system_prompt, el LLM escribe los símbolos y números con palabras en sus respuestas (por ejemplo, john arroba gmail punto com en lugar de john@gmail.com). Las transcripciones del usuario procedentes de Voz a Texto también pueden llegar en un formato no estándar. Esto significa que, al usar estos datos como parámetros en llamadas a herramientas, el LLM puede usar la versión no estructurada presente en el contexto de la conversación.

Si un parámetro de herramienta espera un valor con el formato correcto (por ejemplo, john@gmail.com y no john arroba gmail punto com), el LLM debe saberlo. Incluye el formato esperado directamente en la descripción del parámetro de la herramienta con un ejemplo.

## `lookupAccount` tool parameters
- `email` (required): "The user's email."
- `phone` (required): "The user's phone number."
- `confirmation_code` (required): "The user's confirmation code."

Dedica una sección a los límites

Enumera todas las reglas innegociables que el modelo debe seguir siempre en una sección específica # Guardrails. Los modelos están ajustados para prestar especial atención a este encabezado.

Por qué es importante para la fiabilidad: Los límites evitan respuestas inadecuadas y garantizan el cumplimiento de las políticas. Centralizarlos en una sección específica facilita su auditoría y actualización.

# Guardrails
Never share customer data across conversations or reveal sensitive account information without proper verification.
Never process refunds over $500 without supervisor approval.
Never make promises about delivery dates that aren't confirmed in the order system.
Acknowledge when you don't know an answer instead of guessing.
If a customer becomes abusive, politely end the conversation and offer to escalate to a supervisor.

Para saber más sobre cómo diseñar límites eficaces, consulta nuestra guía sobre Guardrails.

Configuración de herramientas para mayor fiabilidad

Los agentes capaces de gestionar workflows transaccionales pueden ser muy eficaces. Para ello, deben contar con herramientas que les permitan realizar acciones en otros sistemas u obtener datos en tiempo real de ellos.

Tan importante como la estructura del prompt es cómo describes las herramientas disponibles para tu agente. Definiciones de herramientas claras y orientadas a la acción ayudan al modelo a invocarlas correctamente y a recuperarse de los errores sin problemas.

Describe las herramientas con precisión y parámetros detallados

Al crear una herramienta, añade descripciones a todos los parámetros. Esto ayuda al LLM a construir llamadas a herramientas con precisión.

Descripción de la herramienta: “Consulta el estado del pedido de un cliente mediante su ID y devuelve el estado actual, la fecha de entrega estimada y el número de seguimiento.”

Descripciones de parámetros:

• order_id (obligatorio): “El identificador único del pedido, con el formato de caracteres escritos (por ejemplo, ‘ORD123456’)”
• include_history (opcional): “Si es true, devuelve el historial completo del pedido, incluidos los cambios de estado”

Por qué es importante para la fiabilidad: Las descripciones de parámetros funcionan como documentación integrada para el modelo. Aclaran las expectativas de formato, los campos obligatorios frente a los opcionales y los valores aceptables.

Explica cuándo y cómo usar cada herramienta en el prompt de sistema

Define claramente en tu prompt de sistema cuándo y cómo se debe usar cada herramienta. No te bases solo en las descripciones de las herramientas: proporciona contexto de uso y lógica de secuenciación.

# Tools
You have access to the following tools:
## `getOrderStatus`
Use this tool when a customer asks about their order. Always call this tool before providing order information—never rely on memory or assumptions.
**When to use:**
- Customer asks "Where is my order?"
- Customer provides an order number
- Customer asks about delivery estimates
**How to use:**
1. Collect the order ID from the customer
2. Call `getOrderStatus` with the order ID
3. Present the results to the customer in natural language
**Error handling:**
If the tool returns "Order not found", ask the customer to verify the order number and try again.
## `processRefund`
Use this tool only after verifying:
1. Customer identity has been confirmed
2. Order is eligible for refund (within 30 days, not already refunded)
3. Refund amount is under $500 (escalate to supervisor if over $500)
**Required before calling:**
- Order ID (from `getOrderStatus`)
- Refund reason code
- Customer confirmation
This step is important: Always confirm refund details with the customer before calling this tool.

Especifica los formatos esperados en las descripciones de los parámetros de herramientas

Cuando las herramientas requieran identificadores estructurados (correos electrónicos, números de teléfono, códigos), deja claro el formato esperado en la descripción del parámetro con un ejemplo. Esto es especialmente importante porque la normalización y la transcripción de Voz a Texto pueden generar valores en formato hablado dentro del contexto de la conversación. Consulta datos estructurados para entradas de herramientas para obtener más contexto.

## `lookupAccount` tool parameters
- `email` (required): "The customer's email address."

Gestiona los fallos de llamadas a herramientas sin problemas

Las herramientas pueden fallar a veces debido a problemas de red, falta de datos u otros errores. Incluye instrucciones claras de recuperación en tu prompt de sistema.

Por qué es importante para la fiabilidad: Los fallos de herramientas son inevitables en producción. Sin instrucciones explícitas para gestionarlos, los agentes pueden alucinar respuestas o proporcionar información incorrecta.

# Tool error handling
If any tool call fails or returns an error:
1. Acknowledge the issue to the customer: "I'm having trouble accessing that information right now."
2. Do not guess or make up information
3. Offer alternatives:
   - Try the tool again if it might be a temporary issue
   - Offer to escalate to a human agent
   - Provide a callback option
4. If the error persists after 2 attempts, escalate to a supervisor
**Example responses:**
- "I'm having trouble looking up that order right now. Let me try again... [retry]"
- "I'm unable to access the order system at the moment. I can transfer you to a specialist who can help, or we can schedule a callback. Which would you prefer?"

Para obtener instrucciones detalladas sobre cómo crear integraciones de herramientas fiables, consulta nuestra documentación sobre herramientas de cliente, herramientas de webhook y herramientas MCP.

Patrones de arquitectura para agentes empresariales

Aunque los prompts y las herramientas sólidos son la base de la fiabilidad de los agentes, los sistemas de producción requieren un diseño arquitectónico cuidadoso. Los agentes empresariales gestionan workflows complejos que a menudo superan el alcance de un único prompt monolítico.

Mantén los agentes especializados

Las instrucciones demasiado amplias o las ventanas de contexto grandes aumentan la latencia y reducen la precisión. Cada agente debe tener una base de conocimientos y un conjunto de responsabilidades limitados y claramente definidos.

Por qué es importante para la fiabilidad: Los agentes especializados tienen menos casos límite que gestionar, criterios de éxito más claros y tiempos de respuesta más rápidos. Son más fáciles de probar, depurar y mejorar.

Usa patrones de orquestador y especialistas

Para tareas complejas, diseña workflows multiagente que transfieran tareas entre agentes especializados y, cuando sea necesario, a operadores humanos.

Patrón de arquitectura:

1. Agente orquestador: Dirige las solicitudes entrantes a los agentes especialistas adecuados según la clasificación de intención
2. Agentes especialistas: Gestionan tareas específicas de cada ámbito (facturación, programación, soporte técnico, etc.)
3. Escalado a humanos: Criterios de transferencia definidos para casos complejos o delicados

Ventajas de este patrón:

• Cada especialista tiene un prompt específico y un contexto reducido
• Es más fácil actualizar especialistas individuales sin afectar al sistema
• Métricas claras por ámbito (tasa de resolución de facturación, tasa de éxito de programación, etc.)
• Menor latencia por interacción (prompts más pequeños e inferencia más rápida)

Define criterios de transferencia claros

Al diseñar workflows multiagente, especifica exactamente cuándo y cómo debe transferirse el control entre agentes o a operadores humanos.

# Goal
Route customer requests to the appropriate specialist agent based on intent.
## Routing logic
**Billing specialist:** Customer mentions payment, invoice, refund, charge, subscription, or account balance
**Technical support specialist:** Customer reports error, bug, issue, not working, broken
**Scheduling specialist:** Customer wants to book, reschedule, cancel, or check appointment
**Human escalation:** Customer is angry, requests supervisor, or issue is unresolved after 2 specialist attempts
## Handoff process
1. Classify customer intent based on first message
2. Provide brief acknowledgment: "I'll connect you with our [billing/technical/scheduling] team."
3. Transfer conversation with context summary:
   - Customer name
   - Primary issue
   - Any account identifiers already collected
4. Do not repeat information collection that already occurred

# Personality
You are a billing specialist for Acme Corp. You handle payment issues, refunds, and subscription changes.
# Goal
Resolve billing inquiries by:
1. Verifying customer identity
2. Looking up account and billing history
3. Processing refunds (under $500) or escalating (over $500)
4. Updating subscription settings when requested
# Guardrails
Never access account information without identity verification.
Never process refunds over $500 without supervisor approval.
If the customer's issue is not billing-related, transfer back to the orchestrator agent.

Para obtener instrucciones detalladas sobre cómo crear workflows multiagente, consulta nuestra documentación sobre Workflows.

Selección de modelos para la fiabilidad empresarial

Elegir el modelo adecuado depende de tus requisitos de rendimiento, especialmente de la latencia, la precisión y la fiabilidad de las llamadas a herramientas. Los distintos modelos ofrecen diferentes equilibrios entre velocidad, capacidad de razonamiento y coste.

Comprende las ventajas e inconvenientes

Latencia: Los modelos más pequeños (con menos parámetros) suelen responder más rápido, por lo que son adecuados para interacciones frecuentes y poco complejas.

Precisión: Los modelos más grandes ofrecen mayores capacidades de razonamiento y gestionan mejor las tareas complejas de varios pasos, pero con mayor latencia y coste.

Fiabilidad de las llamadas a herramientas: No todos los modelos gestionan las llamadas a herramientas o funciones con la misma precisión. Algunos destacan en las salidas estructuradas, mientras que otros pueden requerir prompts más explícitos.

Recomendaciones de modelos por caso de uso

A partir de implementaciones con millones de interacciones de agentes, se observan los siguientes patrones:

• GLM 5.2 o GPT-6 Luna (punto de partida recomendado): La mejor opción para agentes empresariales de propósito general que necesitan equilibrar latencia, precisión y coste. Ofrece una latencia de baja a moderada, un sólido rendimiento en llamadas a herramientas y un coste razonable por interacción. Ideal para atención al cliente, programación, gestión de pedidos y gestión de consultas generales.

• DeepSeek Flash 4.1 o Gemini 3.5 Flash-Lite (latencia ultrabaja): La mejor opción para interacciones sencillas y frecuentes en las que la velocidad es crítica. Proporciona la menor latencia y amplios conocimientos generales, aunque con menor rendimiento en llamadas a herramientas complejas. Rentable a escala para enrutamiento y triaje inicial, preguntas frecuentes sencillas, confirmaciones de citas y recopilación básica de datos.

• Claude Sonnet 5.5 (razonamiento complejo): La mejor opción para la resolución de problemas de varios pasos, el juicio matizado y la orquestación compleja de herramientas. Ofrece la mayor precisión y capacidad de razonamiento, con una excelente fiabilidad en las llamadas a herramientas, aunque con mayor latencia y coste. Ideal para tareas en las que los errores son costosos, como la resolución de problemas técnicos, el asesoramiento financiero, los workflows sensibles al cumplimiento normativo y las decisiones complejas de reembolso o escalado.

Las líneas de modelos de los proveedores cambian con frecuencia. Confirma las opciones y los precios actuales en la página de Modelos antes de elegir un modelo para producción.

Haz pruebas comparativas con tus prompts reales

El rendimiento de los modelos varía considerablemente según la estructura del prompt y la complejidad de la tarea. Antes de elegir un modelo:

1. Prueba 2-3 modelos candidatos con tu prompt de sistema real
2. Evalúalos con consultas reales de usuarios o casos de prueba sintéticos
3. Mide la latencia, la precisión y la tasa de éxito de llamadas a herramientas
4. Optimiza para lograr el mejor equilibrio según tus requisitos específicos

Para conocer las opciones detalladas de configuración de modelos, consulta nuestra documentación de Modelos.

Iteración y pruebas

La fiabilidad en producción proviene de la iteración continua. Incluso los prompts bien construidos pueden fallar en el uso real. Lo importante es aprender de esos fallos y mejorar mediante pruebas rigurosas.

Configura criterios de evaluación

Asocia criterios de evaluación concretos a cada agente para supervisar el éxito a lo largo del tiempo y detectar regresiones.

Métricas clave que debes seguir:

• Tasa de finalización de tareas: Porcentaje de intenciones de usuario resueltas correctamente
• Tasa de escalado: Porcentaje de conversaciones que requieren intervención humana

Para obtener instrucciones detalladas sobre cómo configurar criterios de evaluación en ElevenLabs, consulta Evaluación de éxito.

Analiza los patrones de fallo

Cuando los agentes rindan por debajo de lo esperado, identifica patrones en las interacciones problemáticas:

• ¿Dónde proporciona el agente información incorrecta? → Refuerza las instrucciones en secciones específicas
• ¿Cuándo no logra entender la intención del usuario? → Añade ejemplos o simplifica el lenguaje
• ¿Qué entradas de usuario hacen que deje de actuar como el personaje? → Añade límites para los casos límite
• ¿Qué herramientas fallan con más frecuencia? → Mejora la gestión de errores o las descripciones de parámetros

Revisa las transcripciones de conversaciones en las que la satisfacción del usuario fue baja o no se completaron las tareas.

Haz mejoras específicas

Actualiza secciones concretas de tu prompt para abordar los problemas identificados:

1. Aísla el problema: Identifica qué sección del prompt o definición de herramienta está causando los fallos
2. Prueba los cambios con ejemplos concretos: Usa como casos de prueba conversaciones que fallaron anteriormente
3. Haz un cambio cada vez: Aísla las mejoras para entender qué funciona
4. Vuelve a evaluar con los mismos casos de prueba: Verifica que el cambio solucionó el problema sin crear otros nuevos

Configura la recopilación de datos

Configura tu agente para resumir los datos de cada conversación. Esto te permite analizar patrones de interacción, identificar solicitudes habituales de usuarios y mejorar continuamente tu prompt a partir del uso real.

Para obtener instrucciones detalladas sobre cómo configurar la recopilación de datos en ElevenLabs, consulta Recopilación de datos.

Usa simulaciones para las pruebas de regresión

Antes de implementar cambios en el prompt en producción, prueba un conjunto de escenarios conocidos para detectar regresiones.

Para obtener instrucciones sobre cómo probar agentes mediante programación, consulta Simular conversaciones.

Consideraciones para producción

Los agentes empresariales requieren medidas de seguridad adicionales más allá de la calidad del prompt. Las implementaciones en producción deben tener en cuenta la gestión de errores, el cumplimiento normativo y la degradación progresiva.

Gestiona los errores en todas las integraciones de herramientas

Cada llamada a una herramienta externa es un posible punto de fallo. Asegúrate de que tu prompt incluya una gestión explícita de errores para:

• Fallos de red: “Estoy teniendo problemas para conectarme a nuestro sistema. Déjame intentarlo de nuevo.”
• Datos ausentes: “No veo esa información en nuestro sistema. ¿Puedes verificar los datos?”
• Errores de tiempo de espera: “Esto está tardando más de lo esperado. Puedo derivarte a un especialista o intentarlo de nuevo.”
• Errores de permisos: “No tengo acceso a esa información. Déjame transferirte a alguien que pueda ayudarte.”

Ejemplos de prompts

Los siguientes ejemplos muestran cómo aplicar los principios descritos en esta guía a casos de uso empresariales reales. Cada ejemplo incluye anotaciones que destacan los principios de fiabilidad utilizados.

Ejemplo 1: Agente de soporte técnico

# Personality
You are a technical support specialist for CloudTech, a B2B SaaS platform.
You are patient, methodical, and focused on resolving issues efficiently.
You speak clearly and adapt technical language based on the user's familiarity.
# Environment
You are assisting customers via phone support.
Customers may be experiencing service disruptions and could be frustrated.
You have access to diagnostic tools and the customer account database.
# Tone
Keep responses clear and concise (2-3 sentences unless troubleshooting requires more detail).
Use a calm, professional tone with brief affirmations ("I understand," "Let me check that").
Adapt technical depth based on customer responses.
Check for understanding after complex steps: "Does that make sense?"
# Goal
Resolve technical issues through structured troubleshooting:
1. Verify customer identity using email and account ID
2. Identify affected service and severity level
3. Run diagnostics using `runSystemDiagnostic` tool
4. Provide step-by-step resolution or escalate if unresolved after 2 attempts
This step is important: Always run diagnostics before suggesting solutions.
# Guardrails
Never access customer accounts without identity verification. This step is important.
Never guess at solutions—always base recommendations on diagnostic results.
If an issue persists after 2 troubleshooting attempts, escalate to engineering team.
Acknowledge when you don't know the answer instead of speculating.
# Tools
## `verifyCustomerIdentity`
**When to use:** At the start of every conversation before accessing account data
**Parameters:**
- `email` (required): Customer email in standard written format (e.g., "user@company.com"). Convert from spoken format: "at" → "@", "dot" → ".", remove spaces between words.
- `account_id` (optional): Account ID if customer provides it
**Error handling:**
If verification fails, ask customer to confirm email spelling and try again.
## `runSystemDiagnostic`
**When to use:** After verifying identity and understanding the reported issue
**Parameters:**
- `account_id` (required): From `verifyCustomerIdentity` response
- `service_name` (required): Name of affected service (e.g., "api", "dashboard", "storage")
**Usage:**
1. Confirm which service is affected
2. Run diagnostic with account ID and service name
3. Review results before providing solution
**Error handling:**
If diagnostic fails, acknowledge the issue: "I'm having trouble running that diagnostic. Let me escalate to our engineering team."
# Error handling
If any tool call fails:
1. Acknowledge: "I'm having trouble accessing that information right now."
2. Do not guess or make up information
3. Offer to retry once, then escalate if failure persists

Principios demostrados:

• ✓ Separación clara de secciones (# Personality, # Goal, # Tools, etc.)
• ✓ Una acción por línea (consulta los pasos numerados de # Goal)
• ✓ Instrucciones concisas (la sección de tono es breve y clara)
• ✓ Pasos críticos destacados (“Este paso es importante”)
• ✓ Conversión de formato en las descripciones de parámetros (normalización de correo electrónico)
• ✓ Sección específica de límites
• ✓ Descripciones precisas de herramientas con indicaciones sobre cuándo, cómo y qué hacer ante errores
• ✓ Instrucciones explícitas de gestión de errores

Ejemplo 2: Agente de reembolsos de atención al cliente

# Personality
You are a refund specialist for RetailCo.
You are empathetic, solution-oriented, and efficient.
You balance customer satisfaction with company policy compliance.
# Goal
Process refund requests through this workflow:
1. Verify customer identity using order number and email
2. Look up order details with `getOrderDetails` tool
3. Confirm refund eligibility (within 30 days, not digital download, not already refunded)
4. For refunds under $100: Process immediately with `processRefund` tool
5. For refunds $100-$500: Apply secondary verification, then process
6. For refunds over $500: Escalate to supervisor with case summary
This step is important: Never process refunds without verifying eligibility first.
# Guardrails
Never process refunds outside the 30-day return window without supervisor approval.
Never process refunds over $500 without supervisor approval. This step is important.
Never access order information without verifying customer identity.
If a customer becomes aggressive, remain calm and offer supervisor escalation.
# Tools
## `verifyIdentity`
**When to use:** At the start of every conversation
**Parameters:**
- `order_id` (required): Order ID in uppercase alphanumeric format (e.g., "ORD123456"). Convert from spoken format: spell out letters and spoken digits to written form, no spaces.
- `email` (required): Customer email in standard written format (e.g., "john.smith@retailco.com"). Convert from spoken format: "at" → "@", "dot" → ".", remove spaces between words.
## `getOrderDetails`
**When to use:** After identity verification
**Returns:** Order date, items, total amount, refund eligibility status
**Error handling:**
If order not found, ask customer to verify order number and try again.
## `processRefund`
**When to use:** Only after confirming eligibility
**Required checks before calling:**
- Identity verified
- Order is within 30 days
- Order is eligible (not digital, not already refunded)
- Refund amount is under $500
**Parameters:**
- `order_id` (required): From previous verification
- `reason_code` (required): One of "defective", "wrong_item", "late_delivery", "changed_mind"
**Usage:**
1. Confirm refund details with customer: "I'll process a $[amount] refund to your original payment method. It will appear in 3-5 business days. Does that work for you?"
2. Wait for customer confirmation
3. Call this tool
**Error handling:**
If refund processing fails, apologize and escalate: "I'm unable to process that refund right now. Let me escalate to a supervisor who can help."

Principios demostrados:

• ✓ Alcance de agente especializado (solo reembolsos, no soporte general)
• ✓ Pasos de workflow claros en la sección # Goal
• ✓ Énfasis repetido en reglas críticas (límites de reembolso, verificación)
• ✓ Uso detallado de herramientas con “cuándo usar” y “comprobaciones obligatorias”
• ✓ Conversión de formato en las descripciones de parámetros (ID de pedidos, correos electrónicos)
• ✓ Gestión explícita de errores por herramienta
• ✓ Criterios de escalado claramente definidos

Buenas prácticas de formato

El formato de tu prompt influye en cómo lo interpreta el modelo de lenguaje:

• Usa encabezados de Markdown: Estructura las secciones con # para las secciones principales y ## para las subsecciones
• Prioriza las listas con viñetas: Divide las instrucciones en puntos fáciles de asimilar
• Usa espacios en blanco: Separa las secciones y los grupos de instrucciones con líneas en blanco
• Escribe los encabezados en formato oración: # Objetivo, no # OBJETIVO
• Mantén la coherencia: Usa el mismo patrón de formato en todo el prompt

Preguntas frecuentes

Próximos pasos

Esta guía establece las bases para un comportamiento fiable de los agentes mediante la ingeniería de prompts, la configuración de herramientas y los patrones arquitectónicos. Para crear sistemas preparados para producción, continúa con:

• Workflows: Diseña la orquestación de varios agentes y las transferencias entre especialistas
• Evaluación del éxito: Configura métricas y criterios de evaluación
• Recopilación de datos: Obtén información estructurada de las conversaciones
• Pruebas: Implementa pruebas de regresión y simulaciones
• Medidas de seguridad: Configura la moderación de contenido para que los agentes respondan de forma segura
• Privacidad: Garantiza el cumplimiento normativo y la protección de datos
• Nuestro agente de documentación: Consulta un caso de estudio completo sobre estos principios en acción

Para recibir ayuda con despliegues empresariales, contacta con nuestro equipo.