Lectura: 5 minutos

Nos prometieron que la IA iba a "hacer todo por nosotros". En 2023 eso sonaba a expectativas muy altas. En 2025, con los AI Agents, por fin estamos cerca… pero con una condición incómoda: los agentes solo funcionan bien cuando les hablamos de forma brutalmente clara.

Un agente no es un "chat bonito". Es más parecido a tener un analista junior hiperproductivo, con acceso a tus sistemas, que sigue tus instrucciones al pie de la letra. Si tus instrucciones son vagas, el agente será vago. Si tus reglas son ambiguas, el agente será "peligroso" o peor aun "tonto". La calidad del agente está limitada por la calidad del diseño del prompt.

En otras palabras: los agentes harán todo por ti… si es que sabes pedirlo bien.

---

De "hazme un resumen" a "tú operas este proceso"

La mayoría de la gente todavía le habla a la IA como si fuera un buscador avanzado:
"Explícame esto", "hazme un resumen", "dame ideas".

Con agentes la conversación cambia. Ya no le pides solo texto, le estás delegando trabajo:

• Leer datos de una base.
• Llamar a APIs.
• Decidir según reglas de negocio.
• Devolver un resultado estructurado que otros sistemas van a consumir.

Eso implica que el prompt deja de ser un mensajito casual y se convierte en una especie de "descripción de puesto + manual operativo" para el agente. Y aquí es donde casi todo el mundo se queda corto.

---

Un patrón simple para escribir buenos prompts de AI Agents

Aunque cada caso de uso es distinto, hay un patrón que funciona muy bien para diseñar prompts de agentes. La idea es que tu instrucción tenga, al menos, estos elementos:

1. Quién es el agente (rol).
2. Qué debe lograr (objetivo).
3. Con qué información y en qué entorno trabaja (contexto).
4. Qué puede y qué no puede hacer (reglas).
5. Cómo debe entregar el resultado (formato de salida).
6. Cómo debe pensar y actuar (plan antes de ejecutar).

No lo pienses como "escribir un prompt bonito”, sino como redactar una serie de instrucciones miniatura 1para un colaborador digital, como si fuera una receta de cocina.

---

Ejemplo 1: Agente de soporte que no improvisa

Imagina que quieres un agente para soporte de primer nivel. Lo fácil sería escribir algo como:

“Ayúdame a responder tickets de soporte de mis clientes.”

Eso sirve para un chatbot, pero se queda muy corto para un agente que vas a conectar a tus sistemas. Un prompt mucho más sólido podría verse así:

Eres un Agente de Soporte Nivel 1 para nuestra plataforma SaaS.

Objetivo:
Resolver o enrutar correctamente los tickets entrantes respetando nuestras reglas de negocio.

Contexto:
- Recibes tickets con: id, customer_tier, product, category, description, language.
- Puedes consultar una API de base de conocimiento que devuelve posibles soluciones.
- Puedes acceder al estatus del cliente (active, trial, delinquent) mediante una API interna.

Reglas:
- Nunca inventes soluciones. Usa únicamente:
  - Los artículos de la base de conocimiento que te proporcione.
  - Las reglas explícitas definidas en este prompt.
- Para clientes de Tier A:
  - Propón siempre una solución temporal (workaround) si no hay una solución completa disponible.
  - Escala el caso si no estás completamente seguro de la solución.
- Cualquier ticket relacionado con facturación, temas legales o compliance debe ser escalado.
- Si no tienes información suficiente, formula 2–3 preguntas específicas de aclaración en lugar de adivinar.

Salida:
Responde siempre en JSON válido con:
- resolution_status: "resolved" | "escalated" | "need_more_info"
- reply_to_customer: string
- kb_article_ids: array of strings
- next_action: string
- escalation_queue: string o null

Razonamiento:
Antes de responder, genera internamente un razonamiento breve con un máximo de 3 viñetas que expliquen por qué elegiste ese estatus.
No incluyas el razonamiento en la salida JSON.

Aquí se ve la diferencia:

• El rol está definido: Level 1 Support Agent.
• El objetivo es claro: resolver o enrutar, no “hablar bonito”.
• El contexto delimita qué datos existen y qué APIs puede usar.
• Las reglas limitan lo que puede hacer (nada de soluciones inventadas, ciertos temas siempre se escalan).
• El formato de salida está forzado a JSON, lo que hace integrable la respuesta.
• La parte de reasoning se mantiene interna para evitar ruido.

---

Ejemplo 2: Agente de reportes ejecutivos que habla el idioma del negocio

“Hazme un resumen mensual para dirección.”

Un prompt pensado en serio podría ser:

Eres un Agente de Reportes Ejecutivos.

Objetivo:
Generar un resumen mensual conciso para stakeholders C-level, enfocado en decisiones y en impacto de negocio.

Contexto:
- Recibes datos estructurados con KPIs:
  - revenue, margin, churn_rate, NPS, operating_costs, number_of_tickets, SLA_breaches.
- También recibes una lista de notable_events con:
  - event_type, date, description, impact_estimate.

Reglas:
- Evita la jerga técnica. Usa lenguaje de negocio.
- La salida total debe caber aproximadamente en una página de texto.
- Cada KPI que menciones debe responder “¿y eso qué?” en lenguaje simple.
- No especules más allá de los datos proporcionados.
- Si los datos son inconsistentes o faltan, indícalo explícitamente como un riesgo.

Salida:
Devuelve un objeto JSON con:
- summary: de 3 a 5 viñetas que capturen la historia principal del mes.
- risks: arreglo de objetos con { description, probability: "low"|"medium"|"high", impact: "low"|"medium"|"high" }.
- opportunities: arreglo de objetos con { description, expected_benefit }.
- decisions_recommended: arreglo de objetos con { description, owner_role, suggested_deadline }.

---

Probando en Postman

Body
{
    "subject":"Support ticket",
    "body_message":"Hello team, I can't log in to PortalX mobile since yesterday. I get “invalid credentials” even after resetting my password. I'm Jane Doe from ACME (account AC-4482), region US. Using Android 14 on a Samsung S23. Please advise."
}

Response
{
  "message": {
    "actions": [
      {
        "reason": "Customer is experiencing login issues despite password reset, requiring investigation.",
        "sla_hours": null,
        "target_team": null,
        "type": "CREATE_TICKET"
      }
    ],
    "classification": {
      "category": "ACCESS",
      "confidence": 0.9,
      "subcategory": "LOGIN_FAILURE"
    },
    "key_fields": {
      "account_id": "AC-4482",
      "customer_email": null,
      "customer_name": "Jane Doe",
      "device": "Samsung S23",
      "language": "EN",
      "order_id": null,
      "os": "Android 14",
      "product": "PortalX",
      "region": "US",
      "severity": null,
      "version": null
    },
    "sentiment": {
      "polarity": "NEGATIVE",
      "score": -0.4,
      "summary": "Customer reports being unable to log in to PortalX mobile and receiving an 'invalid credentials' error."
    },
    "urgency": {
      "level": "HIGH",
      "reason": "User blocked"
    }
  }
}

Reglas mentales para diseñar mejores prompts de agentes

Cuando diseñes prompts para agentes, deja de pensar en "qué quiero que el modelo diga" y concéntrate en "qué rol le estoy dando en mi sistema". Nombra explícitamente ese rol, define un objetivo que se pueda medir ("resolver tickets de nivel 1", "asignar citas sin solapamientos", "generar un reporte accionable para dirección") y especifica el contexto: qué datos recibe, qué APIs puede llamar, qué restricciones de negocio existen.

Después, marca con claridad qué cosas están prohibidas. Los agentes suelen "inventar" cuando no les dices que esa opción está fuera de la mesa. Prohíbe explícitamente inventar datos, horarios o soluciones; define cuándo debe pedir más información en lugar de seguir adelante. Esto es mucho más potente que esperar que el modelo tenga "sentido común".

Finalmente, fuerza un formato de salida desde el principio. Un agente que responde en texto libre puede impresionar a humanos, pero es difícil de integrar en pipelines y automatizaciones. Si en cambio pides JSON con campos bien definidos, listas estructuradas o tablas claras, conviertes la respuesta en algo que otros sistemas pueden consumir sin drama.

---

Cierre: el verdadero superpoder no es el modelo, eres tú diseñando el sistema

La narrativa bonita dice: "los agentes harán todo por ti". La versión honesta es: los agentes harán todo por ti si los tratas como parte de tu arquitectura, no como juguetes.

El verdadero diferencial ya no está en usar el modelo más grande, sino en saber definir buenos roles, buenas reglas y buenos formatos de salida. Empresas distintas, usando modelos similares, van a obtener resultados radicalmente diferentes solo por cómo diseñan sus prompts de agentes.

Y esa es la buena noticia: no necesitas un data center para competir; necesitas aprender a hablar con precisión a tus agentes.

Si te ha gustado este post, te invito a dejarme un comentario y leer tu opinión.