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 estructuras este prompt influye directamente en la 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 estructuras este prompt influye directamente en la 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 determinados encabezados (especialmente # Guardrails), y unos límites de sección claros evitan que las instrucciones se filtren de un contexto 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 cada instrucción breve, clara y orientada 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

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

Por qué es importante para la fiabilidad: En prompts complejos, los modelos pueden priorizar el contexto reciente frente a instrucciones anteriores. El énfasis y la repetición garantizan que no se pasen por alto las 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 causar pronunciaciones incorrectas o alucinaciones de voz.

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

Estrategias de normalización

Admitimos 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 como palabras antes de que el texto llegue al modelo TTS.

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

elevenlabs — Usa nuestro normalizador TTS para normalizar el texto tras la generación del LLM y antes de que llegue al modelo TTS.

• Más fiable que la normalización basada en LLM
• El prompt de sistema no se modifica
• Las transcripciones conservan un 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 “Agente”: haz clic en el icono de engranaje de la sección “Voces” para abrir el panel de ajustes comunes de voz 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 como palabras en sus respuestas (por ejemplo, john at gmail dot com en lugar de john@gmail.com). Las transcripciones de usuario generadas por 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 at gmail dot 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 inapropiadas 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 límites.

Configuración de herramientas para lograr fiabilidad

Los agentes capaces de gestionar workflows transaccionales pueden ser muy eficaces. Para hacerlo posible, 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. Las definiciones de herramientas claras y orientadas a la acción ayudan al modelo a invocarlas correctamente y a recuperarse adecuadamente de los errores.

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 el ID de pedido 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 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 sirven 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 el prompt de sistema cuándo y cómo debe usarse cada herramienta. No te bases únicamente 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 las herramientas

Cuando las herramientas requieren identificadores estructurados (correos electrónicos, números de teléfono, códigos), indica explícitamente 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 en el contexto de la conversación. Consulta datos estructurados para entradas de herramientas para conocer el contexto.

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

Gestiona adecuadamente los errores en las llamadas a herramientas

A veces, las herramientas pueden fallar por problemas de red, datos ausentes u otros errores. Incluye instrucciones claras de recuperación en el 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 indicaciones 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 constituyen la base de la fiabilidad de los agentes, los sistemas de producción requieren un diseño arquitectónico meditado. 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 conocimiento y un conjunto de responsabilidades delimitados con claridad.

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 área (facturación, programación, soporte técnico, etc.)
3. Escalado a una persona: Criterios de transferencia definidos para casos complejos o delicados

Ventajas de este patrón:

• Cada especialista tiene un prompt centrado y un contexto reducido
• Es más fácil actualizar especialistas individuales sin afectar al sistema
• Métricas claras por área (tasa de resolución de facturación, tasa de éxito de programación, etc.)
• Menor latencia por interacción (prompts más pequeños, 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 indicaciones detalladas sobre cómo crear workflows multiagente, consulta nuestra documentación sobre workflows.

Selección de modelos para la fiabilidad empresarial

La elección del 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 los equilibrios

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 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/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 según el caso de uso

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

• GPT-4o o GLM 4.5 Air (punto de partida recomendado): Lo mejor para agentes empresariales de uso general en los que hay que equilibrar latencia, precisión y coste. Ofrece una latencia baja o moderada, un buen 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.

• Gemini 2.5 Flash Lite (latencia ultrabaja): Lo mejor para interacciones frecuentes y sencillas en las que la velocidad es esencial. Ofrece la menor latencia y amplios conocimientos generales, aunque con menor rendimiento en llamadas a herramientas complejas. Es rentable a gran escala para enrutamiento y triaje iniciales, preguntas frecuentes sencillas, confirmaciones de citas y recopilación básica de datos.

• Claude Sonnet 4 o 4.5 (razonamiento complejo): Lo mejor para la resolución de problemas de varios pasos, juicios matizados y 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 tienen un coste elevado, como la resolución de problemas técnicos, el asesoramiento financiero, workflows sensibles al cumplimiento normativo y decisiones complejas sobre reembolsos o escalados.

Evalúa con tus prompts reales

El rendimiento del modelo varía considerablemente según la estructura del prompt y la complejidad de la tarea. Antes de decidirte por 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 las llamadas a herramientas
4. Optimiza para lograr el mejor equilibrio según tus requisitos específicos

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

Iteración y pruebas

La fiabilidad en producción se consigue mediante una iteración continua. Incluso los prompts bien elaborados pueden fallar en el uso real. Lo importante es aprender de esos fallos y mejorar con pruebas rigurosas.

Configura criterios de evaluación

Asocia criterios de evaluación concretos a cada agente para supervisar su é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 atendidas correctamente
• Tasa de escalado: Porcentaje de conversaciones que requieren intervención humana

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

Analiza patrones de fallo

Cuando los agentes no rinden como deberían, 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 entiende la intención del usuario? → Añade ejemplos o simplifica el lenguaje
• ¿Qué entradas de usuario hacen que se salga de su papel? → Añade medidas de protección para 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á provocando los fallos
2. Prueba los cambios con ejemplos específicos: Usa como casos de prueba conversaciones que antes fallaron
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 haya resuelto 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 basándote en el uso real.

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

Usa simulaciones para pruebas de regresión

Antes de implementar cambios en los prompts en producción, pruébalos con un conjunto de escenarios conocidos para detectar regresiones.

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

Consideraciones para producción

Los agentes empresariales requieren medidas de protección adicionales más allá de la calidad del prompt. Las implementaciones en producción deben contemplar la gestión de errores, el cumplimiento normativo y una degradación controlada.

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 conectar con 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 escalarlo 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 qué principios de fiabilidad se utilizan.

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 (“This step is important”)
• ✓ Conversión de formato en las descripciones de parámetros (normalización de correo electrónico)
• ✓ Sección específica de medidas de protección
• ✓ Descripciones precisas de herramientas que indican cuándo/cómo gestionar los errores
• ✓ Instrucciones explícitas para la gestión de errores

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

# 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:

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

Prácticas recomendadas de formato

El formato de tu prompt influye en la eficacia con la que el modelo de lenguaje lo interpreta:

• Usa encabezados de Markdown: Estructura las secciones con # para las secciones principales y ## para las subsecciones
• Da preferencia a 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 estilo oración: # Goal, no # GOAL
• Sé coherente: 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 ingeniería de prompts, configuración de herramientas y 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 a 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 simulación
• Medidas de protección: Configura la moderación de contenido para respuestas seguras de los agentes
• Privacidad: Garantiza el cumplimiento normativo y la protección de datos
• Nuestro agente de documentación: Consulta un caso de estudio completo de estos principios en acción

Para obtener ayuda con la implementación empresarial, contacta con nuestro equipo.