Separa la regla de negocio del prompt de tu agente

Meses después llega una consulta sobre una solicitud concreta: qué política estaba vigente cuando se evaluó, quién la cambió por última vez, qué se probó antes de publicarla. Para responder tienes que reconstruir el estado de esa regla en una fecha. Si la política y las instrucciones de conversación son el mismo texto, cada edición entra a la misma línea de tiempo, y distinguir un ajuste de redacción de un cambio de política queda a criterio de quien lea el historial.

Versionar el prompt completo no separa el historial de la regla del historial de las instrucciones de conversación. Las dos siguen compartiendo archivo, autor y commit, aunque ese archivo esté en un repositorio.

No toda instrucción necesita separarse. La pregunta útil es si el resultado de esa regla tiene que poder comprobarse, y si su cambio tiene que poder revisarse o reconstruirse más adelante. Un monto máximo, un criterio de elegibilidad o un porcentaje de descuento cumplen las dos condiciones. Una instrucción sobre cómo saludar o pedir un dato puede seguir dentro del prompt.

Si necesitas comprobar el resultado o reconstruir el cambio, escribe la regla como lógica explícita. Así puedes probarla y desplegarla por separado, y su historial queda registrado como un cambio propio.

En un repositorio, la política entra al mismo circuito que cualquier otro cambio de software: puedes ver qué cambió, quién lo hizo y conservar su historial. Quién hace esa revisión y cómo se registra la aprobación del negocio lo define cada organización. La regla queda disponible para una revisión separada del prompt.

Jelou Functions hace que ese archivo corra dentro del flujo. Una Function es código TypeScript que despliegas y el agente invoca como herramienta. Recibe los datos que el flujo ya consultó, aplica la política y devuelve una decisión estructurada. En este patrón la Function no consulta nada por su cuenta, y por eso puedes ejecutarla contra datos que escribes tú.

No inventa la regla: ejecuta la que tu empresa ya decidió. En el ejemplo que seguimos, la política entera son tres constantes:

La respuesta trae la decisión y las razones que la sostienen. El agente usa esas razones para explicar el resultado, y quien escribió por WhatsApp ve una sola conversación.

Riesgo sube el tope a 200 y eso es una línea en un archivo.

En el diff ves qué se modificó y nada más. Las pruebas corren contra los casos conocidos, con datos que no salen de producción. El despliegue tampoco se dispara solo, porque el workflow del ejemplo no tiene trigger por push: se ejecuta desde la pestaña Actions, cuando una persona le da Run workflow.

La misma solicitud de 180 dólares devuelve un rechazo con el tope en 150:

Con el tope en 200, devuelve una aprobación:

El prompt no se tocó. Para responder la consulta del principio puedes seguir tres registros: el commit muestra qué cambió y quién lo hizo; el historial de despliegues indica cuándo entró en producción; y, si pasó por un pull request, ahí queda registrada la revisión.

Separar una regla cuesta: defines entradas y salidas, escribes pruebas, despliegas código y lo mantienes. Para una instrucción que orienta el tono de una respuesta ese costo no se justifica, y dentro del prompt está donde tiene que estar.

Abre el prompt de alguno de tus agentes y busca las frases que deciden algo: un monto, un límite, una elegibilidad. Por cada una, pregúntate si alguien podría necesitar comprobar por qué esa decisión salió así, o revisar el cambio que la modificó. Esas son buenas candidatas para llevar a una lógica separada.