Guía de Prompting para tu worker de IA

La guía está organizada en torno a las cuatro superficies de prompting dentro de un worker de Darwin. La mayoría de las reglas aplican a todas las superficies, pero cada sección está escrita para que puedas ir directo a la que necesitas.

Dentro de un worker de IA hay cuatro secciones en las que podemos promptear instrucciones.

Un espacio donde definimos información o instrucciones globales para cada worker del workspace. Por ejemplo: ubicación del negocio, horarios de atención, información de contacto y preguntas frecuentes. Todos los workers del workspace pueden usar este contexto para responder.

Un espacio reservado para un worker específico, en el que definimos información, instrucciones y personalidad que pertenecen solo a ese worker. Por ejemplo, en un workspace con un worker de ventas y un worker de posventa, cada uno necesita precios diferentes (productos vs. mantenimiento) y personalidades diferentes (persuasivo vs. consultivo).

Tanto la IKB como la GKB contienen el mismo conjunto de subsecciones.

Un espacio para bloques personalizados o predefinidos de información en formato de texto que el worker tiene disponibles como contexto permanente. El contenido es fijo como parte del prompt y está disponible en cada etapa de cada pipeline. No es una herramienta de recuperación que se llame solo cuando se necesita.

Un espacio donde podemos cargar planillas para que el worker las use como contexto. Funciona como una herramienta de recuperación.

Un espacio donde podemos cargar archivos para que el worker los use como contexto o los envíe a la conversación.

Un espacio donde podemos configurar sitios para hacer scraping de modo que el worker pueda usar el resultado como contexto. Funciona como una herramienta de recuperación.

Una herramienta de recuperación permite que el worker consulte fuentes de datos externas para obtener información específica (planillas, PDFs, scrapes de la web) bajo demanda. Al recuperar solo lo relevante, optimiza el rendimiento y evita que la ventana de contexto del modelo se congestione.

Un espacio dentro de una etapa de IA en cualquier pipeline en el que definimos el Objetivo del worker para esa etapa en particular.

Ejemplo: Pregúntale al humano su nombre, apellido y edad.

Un espacio dentro de una etapa de IA en cualquier pipeline en el que definimos las condiciones que, al cumplirse, hacen que el worker se mueva a una etapa diferente.

Ejemplo: Si el humano mencionó su nombre, apellido y edad.

Estos principios aplican a toda superficie de prompting. Trátalos como el valor por defecto; las reglas de las secciones posteriores los refinan para contextos específicos.

El modelo es capaz, pero no tiene contexto sobre nuestras normas, nuestros clientes o cómo queremos que se hagan las cosas. Cuanto más precisamente describas el destino y los criterios de éxito, mejor será el resultado. Si un colega sin contexto sobre la tarea quedaría confundido al leer tu prompt, la IA también lo estará.

Describe el resultado que quieres, no cada micropaso para alcanzarlo. Reserva el lenguaje absoluto (Siempre, Nunca, Debe) para verdaderas invariantes — reglas de seguridad, salidas obligatorias o acciones prohibidas. Usa reglas de decisión para todo lo demás.

Explicar la razón detrás de una instrucción hace que el modelo generalice correctamente cuando la conversación se desvía de los casos que anticipaste. “Nunca uses puntos suspensivos” es más débil que “Nunca uses puntos suspensivos, porque la respuesta es leída en voz alta por un motor de text-to-speech”.

El mismo concepto siempre debe llamarse con el mismo nombre. Elige un término y mantenlo en el Objetivo, las condiciones, la IKB y la GKB. La inconsistencia es una de las principales causas de que el modelo interprete dos instrucciones como requisitos distintos.

El modelo crea lo que ve. Decirle “no escribas frases largas” igual lo predispone a frases largas. Dile primero qué debe hacer (“Escribe frases cortas y concisas”) y, solo entonces, agrega la negación si todavía hace falta.

Los modelos modernos siguen las instrucciones de forma literal. Si una regla debe aplicar de forma amplia, dilo (“aplica esto a cada paso”, “en cada respuesta”, “en cada canal”). La generalización implícita ya no es confiable.

Si el Objetivo dice “siempre saluda por el nombre” y la GKB dice “nunca saludes por el nombre cuando la conversación se reabre en menos de una hora”, el modelo tiene que adivinar cuál gana. O reconcilia ambas en un solo lugar, o escribe una regla explícita de prioridad (“las instrucciones de la etapa tienen prioridad sobre los valores por defecto de la base de conocimiento”).

Los prompts de Objetivo son leídos por el modelo como texto plano, pero la estructura markdown dentro de ellos le da al modelo señales fuertes sobre jerarquía e intención. En todo prompt de Objetivo, sigue estas convenciones.

Cuando un Objetivo tiene múltiples fases o ramificaciones, sepáralas con encabezados (#, ##, ###). Los encabezados le dan al modelo un mapa inequívoco de la estructura y permiten anidar subinstrucciones de forma limpia.

Cuando quieras que el asistente diga algo de forma literal, ponlo dentro de un blockquote. Esto separa visualmente el habla literal de las metainstrucciones.

“Hola {nombre}, ¿en qué te puedo ayudar hoy?”

Usa bullets - para conjuntos de ítems en los que el orden no importa (FAQs, opciones que el humano puede elegir, cosas a confirmar en cualquier orden).

Usa 1., 2., 3. cuando el orden de ejecución importa. La numeración le comunica al modelo una secuencia que debe respetar. Cuando un paso necesita dividirse en subpasos que también corren en orden, usa notación decimal debajo de él (1.1, 1.2, 1.3, …) para que la jerarquía quede explícita.

Ejemplo:

La negrita y la cursiva rara vez cambian el comportamiento del modelo y agregan ruido visual. Usa encabezados, listas y blockquotes para dar énfasis. Reserva negrita o cursiva solo para destacar un único token crítico en un párrafo largo cuando no haya una alternativa más limpia.

El Objetivo le dice al worker qué debe lograr durante una etapa. Es la pieza de texto más influyente de una etapa — todo lo demás es contexto.

Evita relleno de cortesía como “Por favor, ¿podrías…?”. Comienza por el Objetivo.

“Tu Objetivo es…”

El system prompt ya define quién es el Asistente al combinar su nombre, rol, empresa y personalidad. Repetir esa caracterización dentro del Objetivo es redundante y empuja la tarea real hacia abajo. Comienza por la tarea en sí, no por una declaración de identidad.

Los modelos prestan más atención al comienzo y al final de un prompt. Pon el comando principal primero. Si hay una sola restricción no negociable, repítela al final como recordatorio de cierre.

Usa “Humano” dentro del prompt. No “lead”, no “cliente”, no “consumidor”. Esto mantiene el vocabulario consistente entre el Objetivo, las condiciones y las bases de conocimiento.

Usa “Asistente” o “IA” para referirte al worker. No “tú” ni ningún otro pronombre. Los pronombres de segunda persona cambian el encuadre del modelo de formas difíciles de predecir.

Dile al modelo qué hacer de forma imperativa.

“Menciona X.” “Pregunta Y.”

Las restricciones rígidas pueden hacer que el worker entre en loop sobre la misma tarea. Una restricción rígida es la que empieza con “Siempre”, “Solo” o palabras absolutas similares.

Ejemplos a evitar:

“Siempre pídele al humano su nombre.” “Solo menciona que vendemos autos.”

Usa los absolutos solo para invariantes verdaderas (seguridad, salidas obligatorias, prohibiciones duras).

Cuando algo no debe pasar, márcalo con “Nunca” para que el modelo lo trate como un límite duro.

“Nunca menciones X.” “Nunca preguntes Y.”

No promptees solo lo que el modelo no debe hacer. Dile primero qué debe hacer y, luego, agrega la negación.

Si una etapa tiene demasiada lógica, el modelo empezará a tomar atajos. Divídela en varias etapas dentro de la misma pipeline para que cada Objetivo se mantenga pequeño y autocontenido.

Si la etapa necesita una secuencia específica, usa una lista numerada.

Un fallback cubre el caso en que la suposición de tu instrucción no se cumple. Sin uno, el modelo inventa.

Fallback zero-shot (sin ejemplo, solo la regla):

Fallback one-shot o few-shot (incluye un ejemplo del estilo deseado):

‘Hola {nombre}, ¿cómo estás?’ Si no lo conoces, saluda sin llamar a ningún nombre.”

Usa few-shot cuando el formato, tono o frase deseados sean difíciles de describir con palabras. Mantén los ejemplos cercanos a conversaciones reales y cubre los casos límite.

Los Objetivos y las condiciones de la siguiente etapa están profundamente relacionados: un Objetivo suele existir para recolectar la información que una condición de transición requiere. Todo lo que se menciona en una condición también debe pedirse (o ser alcanzable) desde el Objetivo.

Mal ejemplo:

Buen ejemplo:

Los modelos siguen las instrucciones de forma literal. Si una regla debe aplicar de forma amplia, dilo.

El Objetivo debe describir qué hacer en la etapa, no qué es el negocio. Mueve precios, políticas, FAQs, horarios de atención y detalles de producto a la IKB o GKB. Esto mantiene el Objetivo corto y hace que los hechos del negocio sean reutilizables entre etapas.

Dile al modelo cuándo la etapa está terminada. Sin un criterio de éxito explícito, el modelo puede seguir haciendo preguntas de seguimiento o cerrar de forma prematura.

“La etapa está completa cuando el humano haya confirmado su nombre, su email y una fecha preferida. Apenas los tres estén presentes, deja de hacer preguntas de seguimiento.”

Las condiciones son lo que hace que el worker se mueva de una etapa a otra. Se evalúan como triggers de herramientas de transición — equivocarse en ellas crea la peor clase de bug: el worker transitando silenciosamente al lugar equivocado, o no transitando nunca.

Cada condición debe comunicar un único propósito en una sola frase corta. Si una condición necesita más de dos cláusulas — encadenadas con “y”, “o”, “pero” o punto y coma — divídela en condiciones separadas dentro del mismo grupo.

Esto vale para los dos tipos de grupo. En un grupo all, en lugar de escribir una frase que une varios requisitos con “y”, escribe cada requisito como su propia condición — el grupo en sí ya significa “todos deben ser verdaderos”. En un grupo any, en lugar de escribir una frase que une varias alternativas con “o”, escribe cada alternativa como su propia condición — el grupo en sí ya significa “cualquiera lo hace verdadero”. Dejar que el grupo haga el trabajo mantiene cada condición enfocada en un solo hecho, que el modelo puede evaluar de forma limpia en lugar de colapsar toda la cadena en una sola verificación borrosa.

Una frase con negativos incrustados (“…pero no si X”; “esto solo es verdad después de Y”) es la señal más fuerte de que hace falta descomponer. Los negativos suelen pertenecer como sus propias condiciones atómicas o como calificadores plegados dentro de los gatillos positivos — reformular el lado positivo a menudo vuelve redundante el negativo.

Mismo vocabulario que en el Objetivo. No “lead”, no “cliente”, no “consumidor”.

No “tú” ni ningún otro pronombre.

Evita “compartió” al hablar de lo que dijo el humano. Usa “mencionó”.

“El humano mencionó que está interesado en…”

Agregar “explícitamente” le dice al modelo que la condición solo se dispara cuando el trigger está inequívocamente presente en el mensaje. Esta es la palanca más eficaz para reducir falsos positivos.

“Si el humano mencionó explícitamente…”

Si dos condiciones se parecen pero llevan a etapas distintas, el modelo va a adivinar. Referencia la condición A dentro de la condición B para exponer la diferencia.

Condición A: “Si el humano mencionó explícitamente que su preferencia es X.” Siguiente etapa: Etapa A.

Condición B: “Si el humano mencionó explícitamente que su preferencia es Y, que es diferente de X porque…” Siguiente etapa: Etapa B.

Para disparar una transición a partir del valor de retorno de una herramienta, nombra la herramienta y describe el valor que contiene el retorno.

“Si el retorno de la herramienta indica X.”

Cuando sea posible, cita el token literal que usa el retorno para que el modelo no tenga que interpretarlo.

“Si el retorno de la herramienta contiene explícitamente la palabra ‘paciente’.”

Una zona muerta es un valor que ninguna condición cubre. El modelo elegirá una de las condiciones adyacentes, normalmente la equivocada.

¿Qué pasa exactamente en 50? Incluí el borde en una de las dos condiciones (≥ 50 y < 50) o agregá una tercera condición para el caso de igualdad. Lo mismo aplica para fechas, rangos y cualquier otra variable continua.

Para números, fechas y horas, usa comparadores inequívocos (≥, ≤, <, >, =, entre X e Y inclusive). Evita palabras coloquiales como “más que”, “algunos”, “pronto”, “recientemente”, a menos que la rúbrica de auditoría tenga una definición para ellas.

Usa un nuevo bloque de información para cada tema nuevo y dale a cada bloque un nombre descriptivo (Promociones, Ubicación, Contactos, Reglas generales, etc.). Un tema por bloque mantiene la recuperación del modelo limpia.

Si una pieza de dato es muy grande (por ejemplo, un catálogo de productos), no pertenece a un bloque de texto. Muévela a un catálogo (planilla), archivo o sitio donde el worker pueda buscarla mediante una herramienta de recuperación.

La sección de FAQs es para pares pregunta/respuesta que el worker debe reusar de forma literal o casi literal. Úsala solo para una relación 1:1 entre una pregunta y una respuesta. Mezclar lógica, ramificaciones o política de formato largo dentro de las FAQs degrada la calidad de la recuperación.

Todo lo que deba valer para cada worker del workspace va en la GKB. Todo lo que solo aplica a un worker (su personalidad, sus precios, sus scripts) va en la IKB. Esto mantiene el conocimiento reutilizable y evita que las particularidades de un worker se filtren a otro.

Si una instrucción pertenece al Objetivo de una etapa, déjala ahí. Ponerla también en la base de conocimiento crea una redundancia que el modelo eventualmente tratará como conflicto.

Usa estos dos verbos y cita el nombre de la herramienta.

“Ejecuta la herramienta .” (donde tool_name es el nombre de la herramienta) “Llama la herramienta .” (donde tool_name es el nombre de la herramienta)

Si prompteas una llamada de herramienta dentro del Objetivo de una etapa, esa herramienta debe estar disponible en la sección de herramientas de esa etapa. De lo contrario, el modelo puede alucinar una llamada a una herramienta que no tiene.

Si prompteas una llamada de herramienta desde la IKB o GKB, esa herramienta debe estar disponible en cada etapa en la que el worker podría alcanzar el prompt. De lo contrario, el modelo puede alucinar la llamada en etapas donde la herramienta no está.

Una llamada de herramienta sin instrucción posterior es trabajo desperdiciado. Describe qué debe pasar para cada valor que la herramienta pueda retornar.

“Si el retorno de la herramienta indica que el humano tiene deuda, menciona…” “Si el retorno de la herramienta indica que el humano no tiene deuda, continúa con…”

Si una herramienta es cara, lenta o one-shot (no se puede repetir), declara las condiciones bajo las cuales el modelo NO debe llamarla. Empareja esto con el trigger positivo de la regla 4.

“Llama la herramienta solo después de que el humano haya confirmado tanto la fecha como la ubicación. Nunca la llames antes de que ambas piezas de información estén presentes, y nunca la llames más de una vez por conversación.”

Usa el carácter @ como comando para seleccionar el archivo que querés que el worker pueda enviar.