Naveo

STEP 13 / 22

A5 TASK

TU PROMPT · 3 CASOS

Orbit te pide diseñar el system prompt del agente que armaste en step 11, ahora con presupuestos explícitos comunicados al modelo. El loop en código ya tiene los limits; ahora el AGENTE tiene que saberlos y respetarlos para no chocarse contra ellos.

Tres techos que el agente debe entender y reportar:

max_steps: 10 tool calls antes de tener que dar respuesta final.
max_tokens_used: cuando vea que está cerca del presupuesto de tokens, debe condensar.
max_cost_usd: cuando vea que está cerca del presupuesto de dinero, debe priorizar tools baratas.

El system prompt debe enseñarle al agente a:

Llevar la cuenta de en qué paso va (el runtime se lo inyecta como contexto).
Avisarle al usuario cuando esté cerca de algún techo, explicando qué va a pasar.
Dar respuesta parcial pero útil cuando alcance un techo, en vez de morir silenciosamente.

Donde el goal del usuario va, usá {{input}}. El runtime inyecta cada turno una sección <budget_status> con steps_used, tokens_used, cost_so_far, y los techos restantes.

632 chars

usa {{input}} donde vaya la entrada

RUBRIC · 3 CASOS · 5 CRITERIOS

"Buscá el roster de turno noche del viernes y armá un resumen con los onc…"

CASO 1

"Procesá los últimos 20 tickets, agrupalos por bay, y devolvé los 3 más u…"

CASO 2

"Listá todos los crewmates con permiso de soldadura y verificá cuáles tie…"

CASO 3

MODO INVITADO

Estás viendo esta lección como invitado. Para guardar tu progreso, ganar XP y mantener tu racha, inicia sesión cuando estés listo para comprobar.

Cuesta 1 vida

El agente sabe sus techos, no choca contra ellos

En el step 11 implementaste los techos del lado del runtime: max_steps protege contra loops, loop_detection contra stuck, tool errors no terminan el loop. Eso protege al sistema de bugs del modelo.

Pero falta la otra mitad: el agente tiene que SABER sus techos y comportarse en consecuencia. Si solo tiene los techos del runtime, cuando los choque va a parar abruptamente, sin avisar, dejando al usuario con una respuesta vacía.

Los tres techos clásicos

max_steps. cuántas tool calls antes de tener que dar respuesta final. Típico: 10-15 para tareas operacionales, 30-50 para análisis profundos.
max_tokens_used. cuántos tokens (in + out) puede consumir el agente acumuladamente. Protege contra context windows que se inflan paso a paso.
max_cost_usd. cuánto dinero puede gastar el agente en esta sesión. El techo absoluto. Acá no hay negociación: cuando se acaba, se acaba.

El system prompt enseña al agente a usarlos

El runtime inyecta cada turno una sección como:

xml

El system prompt instruye al agente a:

Leer ese bloque antes de decidir el próximo tool call.
Cuando esté al 80% de algún techo, avisar al usuario: "Quedan 2 pasos. Si querés que profundice en X, te alcanza para eso. Si querés cubrir todo, voy a tener que cortar antes."
Cuando alcance un techo, dar respuesta parcial útil: resumir lo que sí logró, declarar qué quedó pendiente, ofrecer continuar en otra llamada.

Qué evitar

Morir silenciosamente. El agente choca contra max_steps y devuelve null o un error críptico. El usuario no sabe qué pasó ni qué tiene del trabajo hecho.
Devolver solo "budget excedido". Tirar el error sin resumen es maltratar al usuario. Si hiciste 8 tool calls antes de cortar, esas 8 tienen información útil. Resumila.
No leer el status. El agente decide ciegamente paso a paso, ignora el bloque, y se sorprende cuando lo cortan. Si no lee, no actúa en consecuencia.

Un agente bien entrenado en presupuestos parece considerado: avisa, propone, condensa, y respeta los límites. Un agente sin presupuestos parece inestable: a veces termina perfecto, a veces deja al usuario colgado, y nunca podés saber cuál vas a obtener.

Tu task

Escribí el system prompt del agente. Tres techos a manejar, una regla de aviso, una regla de respuesta parcial. El judge evalúa cinco criterios sobre tu prompt.