Desarrollo de agentes de IA para empresas: operaciones y producto

Empiece por una única llamada a un LLM. Pase a un agente solo cuando la tarea reúna tres propiedades: requiere varias llamadas a herramientas cuyo orden no se puede fijar de antemano, opera sobre un estado que cambia entre turnos y el criterio de éxito es lo bastante verificable como para que el agente pueda autocorregirse. La clasificación del soporte al cliente rara vez es un agente; los flujos de operaciones que tocan cuatro APIs internas en un orden distinto cada vez, a menudo sí. Rechazamos proyectos de agentes cuando un pipeline determinista más una llamada a un LLM se entregaría en la mitad de tiempo y con una cuarta parte de los errores.

Depende de la carga de trabajo. LangGraph para agentes con estado, flujo de control con ramificaciones y puntos de control humanos — el grafo explícito compensa cuando se depura a las 2 de la madrugada. CrewAI o AutoGen cuando la colaboración multiagente es realmente el patrón (poco habitual). OpenAI Assistants cuando la carga está muy ligada al formato de herramientas de OpenAI y no necesita portabilidad. Temporal o Inngest cuando el agente es en realidad un flujo de trabajo duradero con pasos de LLM en su interior. Vercel AI SDK para front-ends en Next.js con un uso sencillo de herramientas. Elegimos por encaje operativo, no por preferencia de proveedor.

Tres controles. Presupuestos estrictos de tokens y dólares por tarea en la capa de orquestación — el agente termina con un error claro antes de entrar 40 veces en un bucle que acabe en su factura de OpenAI. Validación de las llamadas a herramientas paso a paso mediante Pydantic, para que los argumentos no válidos se detecten antes de llamar a la API y no después. Puntos de control human-in-the-loop en las acciones irreversibles (enviar un correo, publicar en producción, cobrar una tarjeta). Observabilidad con Langfuse, Helicone o Arize, que registra cada paso, cada llamada a herramientas y cada token. Las alertas de coste saltan en el orquestador, no en el panel que usted consulta el lunes.

La memoria son tres cosas, no una. A corto plazo: el búfer de la conversación actual, resumido cuando supera el presupuesto de contexto. A largo plazo episódica: hechos que el agente aprendió sobre el usuario o la tarea, guardados en una base vectorial con recuperación semántica (pgvector o Weaviate). A largo plazo semántica: el corpus del que el agente recupera información, tratado como un subsistema de RAG. Dimensionamos cada nivel de forma explícita porque meter todo sin criterio en la ventana de contexto cuesta de cinco a diez veces más por petición y degrada la calidad. El coste de memoria por agente suele ser del 30 al 60 por ciento del coste del LLM cuando está diseñada; del 300 por ciento cuando no lo está.

Con puntos de control escalonados. Nivel 1 (autónomo): acciones de solo lectura, sin aprobación humana. Nivel 2 (revisión asíncrona): una persona ve la acción y puede revertirla dentro de un plazo, pero el agente no se bloquea. Nivel 3 (aprobación síncrona): las acciones irreversibles (enviar correos, publicar en producción, cobrar) esperan la aprobación humana antes de ejecutarse. La interfaz de aprobación forma parte del entregable, no es un añadido posterior — normalmente un mensaje interactivo de Slack, una acción en cola en su panel de administración actual o una bandeja de aprobaciones a medida. El nivel se asigna por herramienta, queda por escrito y cambia mediante PR, no por Slack.

Cuatro niveles de alcance cerrado, todo incluido y presupuestados en USD. Un agente de tarea/PoC desde $2,900 (2–3 semanas): un agente de una sola tarea o una prueba de concepto funcional. Un agente con RAG desde $8,100 (4–6 semanas): recuperación y fundamentación sobre su corpus con citas. Un agente de IA autónomo desde $10,400 (6–9 semanas): orquestación de herramientas, memoria, human-in-the-loop y observabilidad. Un sistema multiagente o de ML en producción desde $13,800 (9–13 semanas). Verá el presupuesto desglosado al terminar el descubrimiento y lo aprobará antes de escribir una sola línea de código. Sin recargo de selección ni sobrecoste por herramientas; los costes de nube corren por sus propias cuentas, así que usted conserva el control del gasto.

Usted, desde el primer día. La cesión de la propiedad intelectual se firma antes de empezar el desarrollo, de modo que el código, la biblioteca de prompts, el conjunto de evaluación, los esquemas de herramientas y la configuración de orquestación son suyos. Entregamos el repositorio, la infraestructura como código y los runbooks; no hay ningún runtime propietario cuya licencia deba seguir pagándonos para mantener vivo el agente. Las cuentas de nube y de modelos también son suyas, por eso conserva el control del gasto en lugar de pagar un traspaso con sobreprecio.

Sí. La capa de proveedor es deliberadamente agnóstica respecto al modelo, de modo que si usted está estandarizado en Azure OpenAI, Anthropic en Bedrock o Google Vertex por motivos contractuales o de residencia, el agente funciona a través de ellos sin reescribirse. En proyectos alineados con el RGPD mantenemos el plano de datos en la región que elija, documentamos cada punto en el que los datos cruzan una frontera, eliminamos o tokenizamos los datos personales antes de que lleguen a un modelo cuando es necesario y podemos ejecutar la recuperación y la memoria íntegramente dentro de su VPC. El alcance normativo (RGPD, preparación para HIPAA, PCI DSS) está incluido en el precio, no se añade después.

Toda colaboración que supera el nivel de PoC incluye un entorno de evaluación que se ejecuta en CI con cada cambio de prompt o de herramienta — no como una demo puntual. Construimos un conjunto de pruebas calificado a partir de tareas reales, puntuamos la corrección, la validez de las llamadas a herramientas, la fundamentación (en RAG) y el coste por tarea, y bloqueamos los despliegues ante regresiones. El paso a producción es un aumento gradual del tráfico tras un feature flag, con SLO de coste y latencia, de modo que los primeros usuarios reales son una parte controlada y no toda la cola. Un agente que no se puede medir es un agente que no pondremos delante de sus clientes.

A menudo, sí. Empezamos con una auditoría breve: dónde el flujo de control es emergente y no explícito, dónde las llamadas a herramientas carecen de validación o de idempotencia, dónde se dispara el coste y si la memoria está metiéndolo todo en la ventana de contexto. Recibe un listado de hallazgos por escrito con una valoración honesta — refactorizar el grafo existente o rehacer las partes de riesgo. Muchos rescates tienen menos que ver con el modelo y más con el andamiaje operativo que faltaba: presupuestos, puntos de control, trazas y evaluaciones que nunca existieron.

Defensa en profundidad, porque ningún control por sí solo basta. Los argumentos de las herramientas se validan con esquemas estrictos de Pydantic antes de cualquier llamada a la API, de modo que una instrucción manipulada no pueda colar una acción mal formada o fuera de alcance. Las herramientas irreversibles quedan tras puntos de control de aprobación síncrona, sea cual sea lo que el modelo “decidiera”. El contenido recuperado o aportado por el usuario se trata como datos no confiables, no como instrucciones, y se mantiene fuera del prompt de sistema privilegiado. Las credenciales de mínimo privilegio impiden que un paso comprometido alcance sistemas para los que nunca tuvo permiso, y cada paso se traza para que el uso indebido sea visible a posteriori.

Ese es el objetivo de la fase de despliegue, no un añadido posterior. Recibe el repositorio, la infraestructura como código, el conjunto de evaluación, los paneles de observabilidad y un runbook que cubre agentes bloqueados, caídas de herramientas y picos de coste. Formamos a sus ingenieros para añadir herramientas, ampliar el conjunto de evaluación y leer las trazas, y nos retiramos cuando su equipo opera el agente en el día a día. Si desea ayuda continuada, el soporte es un acuerdo aparte con un SLA definido — una elección, no una dependencia que fabriquemos nosotros.