La agencia Promptingque los disena, los prueba, los versiona, cablea el contexto, recorta el coste tokenfiable, no a corazonadas.
Una agencia prompting que trata el prompt engineering como trabajo de produccion, no como cacharreo en un playground. Disenamos los system prompts, anadimos few-shot y chain-of-thought solo donde se ganan sus tokens, restringimos la salida a un JSON estructurado, y cableamos el contexto con RAG para que el modelo vea lo que necesita. Luego lo respaldamos con un harness de evals sobre tus casos reales, versionamos los prompts como codigo, y elegimos el modelo (Claude, GPT, Gemini) que de verdad encaja con la tarea, para que tus features de IA aguanten bajo trafico real.
Activecampaign
Adalo
AdCreative.ai
Ahref
Airtable
Allo-The-Mobile-First-Company
Apify
Apolloio
Attio
Base44
Baserow
Brevo
Bright-Data
Browse-Ai
Bubble
Captaindata
ChatGPT
Claude
Claude Code
Claude Cowork
Claude Design
Clickup
Cursor
DeepSeek
Depuración Make
Depuración n8n
Depuración Zapier
Dust
ElevenLabs
Fillout
Flutterflow
Folk-Crm
Freepik Spaces
GammaUna agencia prompting disena fiabilidad, no frases ingeniosas.
Cualquiera puede escribir un prompt que funcione una vez. Hacerlo funcionar en cada entrada, medirlo, y mantener el coste a raya es otro trabajo. Estas son las cuatro cosas que asumimos.
- Diseno de prompts
System prompts que hacen un solo trabajo, predecible
Una frase ingeniosa en un playground no es un prompt de produccion. Disenamos toda la capa de instruccion: un system prompt apretado, los ejemplos few-shot adecuados, chain-of-thought donde se gana sus tokens, y una salida JSON estructurada que tu codigo puede parsear. Elegimos el modelo que encaja con la tarea (Claude, GPT, Gemini) en vez de tirar del que este abierto, y ajustamos temperature y condiciones de parada para que la misma entrada te devuelva la misma forma de respuesta cada vez.
Ver un build tipo - Evals y testing
Prompts en los que confias porque estan medidos
La diferencia entre una demo y un producto es un harness de evals. Construimos un set de tests a partir de tus casos reales, definimos que es una buena respuesta, y puntuamos cada cambio de prompt contra el, para que envies con pruebas, no porque un ejemplo se viera bonito en una reunion. Cuando un modelo se actualiza o ajustas una instruccion, el harness te dice si la calidad se movio antes de que lo descubran tus usuarios.
Ver el metodo - Context engineering y RAG
El contexto correcto, no todo el pajar
La mayoria de las malas respuestas no son un problema de prompt, son un problema de contexto. Disenamos lo que el modelo de verdad ve: un retrieval que saca los pasajes relevantes (RAG), tool use que trae datos en vivo, y una ventana de contexto llena de lo que importa y de nada que solo queme tokens. Anadimos guardarrailes para que siga en la tarea y salida estructurada para que el resultado caiga directo en tu pipeline.
Ver las integraciones - Prompt ops y traspaso
Una prompt library que tu equipo puede poseer
Los prompts se pudren cuando viven en capturas de pantalla e hilos de Slack. Los versionamos como codigo, documentamos por que cada uno tiene esa forma, y seguimos el coste en tokens por llamada para que la factura sea predecible. Somos una agencia de automatizacion e IA primero, asi que los prompts encajan en como tu producto ya funciona, y tu equipo se va capaz de cambiar un prompt sin romper el eval que lo protege.
Ver la capacitacion IA
Disenamos los prompts como software, no como hechizos.
La mayoria del trabajo de prompt muere igual: un ejemplo se ve genial en una reunion, sale, y los casos limite afloran en produccion sin forma de saber que rompio. Asi que tratamos el prompting como ingenieria: system prompts acotados, salida estructurada, el contexto correcto via RAG, y un harness de evals que puntua cada cambio contra tus casos reales antes de que salga.
- Auditoria · mapeamos tus features de IA, los casos que rompen, y donde el problema real es el prompt vs el contexto vs el modelo
- Build · system prompts, few-shot, salida estructurada, RAG y guardarrailes, acotados por tarea
- Medir · un harness de evals sobre tus casos reales para que cada cambio se puntue, no se adivine
- Traspaso · una prompt library versionada que tu equipo edita sin romper los evals
Nosotros enviamos features LLM a diario.
No vendemos magia de prompt. Construimos features de IA que corren sobre trafico real, incluidas las que hay detras de este sitio, asi que disenamos los prompts como sobreviven en produccion: system prompts acotados, salida estructurada, contexto cableado con RAG, y evals que atrapan una regresion antes que tus usuarios. Es exactamente lo que falta cuando el prompting se queda en una linea ingeniosa en un playground.
- Enviamos features LLM en produccion, asi que disenamos los prompts como sobreviven al trafico real, no como se ve un solo ejemplo de playground.
- Los evals antes que las opiniones: puntuamos los cambios de prompt contra tus casos reales, para que la calidad sea un numero que ves, no una sensacion en una demo.
- Honestos con el limite: un mejor prompt no arregla datos malos, un proceso roto o el modelo equivocado, y algunas tareas piden codigo o fine-tuning. Te lo diremos.
- Te quedas autonomo: los prompts, el harness de evals y la doc viven en tu repo, asi que tu equipo los posee sin nosotros.
Los prompts en el centro, la ingenieria alrededor.
Construimos las partes que convierten el prompting en output fiable, y luego las conectamos a como tu producto ya funciona. Esto es lo que cubre una mision real de prompt engineering.
- Setup
System y task prompts
Escribimos el system prompt que fija el rol, el tono y las reglas del modelo, mas los task prompts alrededor, para que el comportamiento sea consistente en vez de derivar con cada cambio de fraseo.
- Setup
Few-shot y chain-of-thought
Anadimos ejemplos few-shot donde suben la precision y chain-of-thought donde la tarea necesita razonamiento, y cortamos ambos donde solo queman tokens sin mejorar la respuesta.
- Setup
Salida estructurada / JSON
Restringimos el modelo a una salida JSON estructurada y valida que tu codigo puede parsear sin regex ni reintentos, para que un paso LLM se comporte como una funcion fiable en tu pipeline.
- Setup
RAG y context engineering
Disenamos el retrieval y el ensamblado del contexto para que el modelo vea los pasajes relevantes y los datos en vivo que necesita, lo que arregla muchas mas malas respuestas que reformular el prompt.
- Setup
Harness de evals
Construimos un set de tests a partir de tus casos reales y un metodo de scoring, para que cada cambio de prompt y cada subida de modelo se mida contra una calidad que tu definiste, no a ojo.
- Setup
Prompt library y versionado
Versionamos los prompts como codigo, documentamos la intencion de cada uno, y seguimos el coste en tokens por llamada, para que tu equipo cambie un prompt con seguridad y mantenga la factura predecible.
Diagnosticamos tu feature de IA, te llevas un plan.
Antes de cotizar nada, dedicamos 60 minutos a mirar tus features de IA, los casos donde rompen, y si es el prompt, el contexto o el modelo lo que de verdad falla. Te llevas una lectura honesta de que arreglar primero y que atraparia un harness de evals. Cero pitch, solo la mirada de un ingeniero sobre tus prompts.
- Una lectura honesta: ¿es el prompt, el contexto o el modelo?
- Los prompts y evals que vale la pena construir primero
- Donde el RAG o la salida estructurada arregla mas que reformular
- Una opinion franca sobre lo que un mejor prompt no va a arreglar
Como llevamos una mision de prompt engineering.
Cinco pasos, en orden. No reescribimos prompts antes de conocer la causa real, no enviamos un cambio sin puntuarlo contra los evals, y tu equipo posee la library al final. Cada paso tiene un entregable y validas antes de que avancemos.
- Paso 1 · Auditoria de prompts
Encontrar si es el prompt, el contexto o el modelo
Miramos tus features de IA y los casos donde salen mal: alucinaciones, formatos inconsistentes, respuestas que ignoran tus datos, costes que se disparan. La mitad del valor es el diagnostico. A menudo el arreglo no es un prompt mas listo, es retrieval, un cambio de proceso, u otro modelo, y te lo diremos antes de que nos pagues por reescribir instrucciones que nunca fueron el problema.
- Paso 2 · Disenar los prompts
Construir la capa de instruccion que aguanta
Disenamos el system prompt, los ejemplos few-shot, y chain-of-thought donde se gana su sitio, luego restringimos la salida a un JSON estructurado que tu codigo puede parsear. Elegimos el modelo que encaja con la tarea y ajustamos temperature, condiciones de parada y guardarrailes para que la misma entrada devuelva la misma forma de respuesta. Cada prompt esta acotado a un trabajo, no un parrafo que intenta hacer cinco.
- Paso 3 · Cablear el contexto
Darle al modelo con que acertar
La mayoria de las malas respuestas son un problema de contexto, no de fraseo. Disenamos el retrieval (RAG) para que el modelo vea los pasajes relevantes, anadimos tool use para traer datos en vivo, y ensamblamos la ventana de contexto para cargar lo que importa y soltar lo que solo cuesta tokens. Los guardarrailes lo mantienen en la tarea, y la salida estructurada hace que el resultado fluya directo a tu pipeline.
- Paso 4 · Construir los evals
Medir la calidad para enviar con pruebas
Construimos un set de tests a partir de tus casos reales y definimos como se ve una buena respuesta, luego puntuamos cada cambio de prompt y de modelo contra el. Cuando Claude, GPT o Gemini saca una actualizacion, el harness te dice si la calidad se movio antes que tus usuarios. Dejas de enviar sobre un solo ejemplo bonito y empiezas a enviar sobre numeros que puedes defender.
- Paso 5 · Traspasar la library
Versionarla, documentarla, y luego quitarse de en medio
Versionamos los prompts como codigo, documentamos por que cada uno tiene esa forma, y seguimos el coste en tokens por llamada para que la factura sea predecible. Tu equipo puede cambiar un prompt y el harness de evals atrapa una regresion antes de que se envie. Si quieres ir mas a fondo, nuestro curso de IA cubre prompting, evals y context engineering de principio a fin para que construyas la siguiente feature sin nosotros.
Nos juzgan por las features que aguantan.
Ningun badge de partner que exhibir, asi que lideramos con lo que importa: los comentarios de los equipos a cuyas features de IA les disenamos los prompts, y si esas features siguieron fiables tras irnos. Nuestras resenas de Trustpilot vienen de esos equipos, no de un deck de marketing.
- Los prompts y los evals viven en tu repo, propiedad de tu equipo
- Cada cambio de prompt puntuado antes de tocar a un usuario
- Contexto cableado con RAG, salida restringida a JSON
- Las resenas de Trustpilot vienen de los equipos a los que les construimos prompts
Las preguntas que nos hacen en bucle.
¿Que hace exactamente una agencia prompting?
Una agencia prompting disena la capa de instruccion detras de tus features de IA para que sean fiables en produccion, no solo impresionantes en una demo. Disenamos los system prompts, los ejemplos few-shot y la salida JSON estructurada, cableamos el contexto con RAG y tool use, elegimos el modelo que encaja con la tarea, y construimos un harness de evals que puntua cada cambio contra tus casos reales. Tambien versionamos los prompts y seguimos el coste en tokens. El objetivo son features de IA en las que tus usuarios confian, no prompts que funcionan una vez y rompen a la siguiente entrada.¿En que se diferencia el prompt engineering de solo escribir un buen prompt?
Escribir un buen prompt te da una respuesta bonita una vez. El prompt engineering te da la misma calidad en la llamada mil, sobre las entradas que no previste. Eso significa un system prompt apretado, few-shot y chain-of-thought usados solo donde ayudan, salida estructurada que tu codigo puede parsear, el contexto correcto inyectado via RAG, guardarrailes, y un harness de evals que prueba que un cambio mejoro las cosas en vez de romper un caso limite en silencio. Es la diferencia entre una frase ingeniosa y un componente que puedes enviar.¿Cuando una agencia prompting NO es la opcion adecuada?
Cuando el problema no es el prompt. Un mejor prompt no arregla datos malos o faltantes, un proceso roto aguas arriba, o el modelo equivocado para el trabajo, y te lo diremos en la auditoria en vez de venderte una reescritura. Algunas tareas piden codigo, una pipeline de retrieval, o fine-tuning en vez de una instruccion mas lista. Si tu feature falla porque el modelo nunca ve el contexto correcto, ningun pulido de prompt la salvara. Preferimos acotar el arreglo real que cobrarte el equivocado.¿Que es un harness de evals y por que importa para el prompting?
Un harness de evals es un set de tests de tus casos reales mas una forma de puntuar como maneja un prompt cada uno. Importa porque sin el envias a ojo: un ejemplo se vio bien, asi que sale a produccion, y encuentras las regresiones con tus usuarios. Con evals, cada cambio de prompt y cada actualizacion de modelo (Claude, GPT, Gemini) se puntua contra una calidad que definiste, asi que envias con pruebas. Es la razon mas grande por la que las features LLM de produccion siguen fiables mientras los prompts de playground se caen.¿Podeis reducir nuestro coste en tokens y en modelo?
Si, y suele ser la ganancia mas rapida. Seguimos el coste en tokens por llamada, recortamos el contexto que quema tokens sin mejorar la respuesta, cortamos el chain-of-thought donde no aporta, y elegimos un modelo mas barato para los pasos que no necesitan el flagship. La salida estructurada reduce los reintentos, y un prompt mas apretado significa menos tokens malgastados por peticion. Optimizamos el coste contra el harness de evals, para que la factura baje sin que la calidad baje con ella.¿Con que modelos trabajais, y como elegis?
Trabajamos con Claude, GPT y Gemini, y la eleccion es parte del trabajo, no un reflejo. Algunas tareas quieren el mejor razonamiento, otras velocidad y coste bajo, otras una ventana de contexto larga o un comportamiento de tool use concreto. Probamos las opciones realistas contra tu harness de evals y elegimos por resultados, no por el proveedor que nos guste. Como los prompts y los evals son conscientes del modelo, cambiarlo despues es un cambio medido, no una reescritura desde cero.¿Un mejor prompt va a reemplazar el fine-tuning o construir en codigo?
No, y no vamos a fingir que el prompting es magia. El prompt engineering te lleva muy lejos y es mucho mas barato y rapido de iterar que el fine-tuning, asi que es el primer movimiento correcto para la mayoria de las features. Pero algunas tareas de verdad necesitan fine-tuning, una pipeline de retrieval, o codigo plano, y un prompt no sustituye eso. Usamos el prompting donde es la herramienta correcta y te decimos con honestidad cuando el trabajo pide otra cosa, para que no sobreinviertas en instrucciones que tocan techo.¿Formais a nuestro equipo o solo entregais los prompts?
Ambos, porque un prompting que solo vive en nuestras cabezas muere en cuanto nos vamos. Entregamos una prompt library versionada, el harness de evals, y la doc sobre por que cada prompt tiene esa forma, luego formamos a tu equipo para cambiar un prompt sin romper el eval que lo protege. Si quieres ir mas a fondo, nuestro curso de IA cubre system prompts, few-shot, context engineering, RAG y evals de principio a fin, para que tu equipo construya y mida la siguiente feature sin nosotros.
Deja de enviar prompts a corazonadas. Disenalos.
Una auditoria de 60 minutos, tu feature de IA diagnosticada, un plan con los evals incorporados. Si tu equipo puede correr la prompt library en casa tras el setup, te damos el playbook. Si encajamos, lo hacemos nosotros.