Review honesta de Devic para equipos SaaS: lo bueno, lo malo y para quién no encaja

Esta review la escribimos nosotros. Vendemos Devic. Si buscas un análisis de un tercero con clientes citados y cifras auditadas, todavía no hay suficiente material público independiente: la categoría es joven y casi nadie ha publicado una review que no sea la home de un competidor. Lo que sí podemos hacer es decir qué problema intenta resolver el producto, qué trabajo sigue siendo vuestro, dónde se rompe el encaje y qué alternativa mirar cuando no somos la opción.

La pregunta útil no es "¿Devic es bueno?". Es "¿qué resuelve, qué no, y cuándo elegir otra cosa?".

Para quién es esta review (y para quién no)

Es para un CEO o un CTO de SaaS que ya vio una demo de agentes o construyó un MVP de un copiloto y está invirtiendo tiempo y recursos en llevarlo a un entorno productivo. También para quien compara construir con LangGraph o Mastra, automatizar con n8n, o no hacer un agente todavía.

No es para quien busca un descuento, un ranking de modelos o una promesa de que el agente "no se equivoca". El modelo sigue fallando. La plataforma no convierte un caso mal elegido en un caso bueno. Si todavía no tenéis métrica ni flujo, leed antes cómo elegir el primer caso y por qué una demo no es producción.

Qué problema intenta resolver Devic

El patrón que más vemos no es "no sabemos llamar a un LLM". Es "sabemos hacer el prototipo y no queremos operar un segundo producto": desarrollar una lógica multitenant, crear y mantener tools sobre vuestra API, implementar un sistema de trazas, definir políticas de límite de coste, human-in-the-loop y desplegar una infraestructura donde alojar al asistente que forma parte de tu SaaS.

Devic se sitúa en esa capa: ejecución de agentes y asistentes, RAG cuando el problema es conocimiento, conversión de APIs en tools, MCP, widgets y gobierno por tenant. No sustituye al modelo. No sustituye vuestra lógica de negocio. Intenta que no reconstruyáis esa infraestructura cada vez que añadís un agente. El mapa de capas está en el modelo no es el agente y la ficha de producto, en devic.ai/producto.

Anthropic lo cuenta en Managed Agents: el harness, el bucle que llama al modelo y enruta las tools, acumula supuestos que caducan cuando el modelo mejora, y por eso separaron sesión, harness y sandbox en un servicio alojado en lugar de mantener un único contenedor vivo. Para un equipo de producto la lectura es práctica. Operar ese runtime es un trabajo que cambia con cada modelo. Si vuestro producto no es el harness, seguís necesitando el caso, las tools y la política, pero no tenéis por qué ser quienes reescriben el bucle cada vez que el modelo cambia.

Lo bueno (con matices)

Cuatro cosas se notan cuando el encaje es el correcto, y conviene decirlas sin adorno.

El equipo pone el foco donde de verdad es experto, que es el conocimiento del negocio: qué flujo importa, qué cuenta como acierto y qué no puede hacer el agente. Esa es la parte que os diferencia. Devic no la trae hecha.

Evitáis crear y mantener la fontanería que se repite en cualquier SaaS con agentes: multitenant, ejecución, trazas, límites y el sitio donde vive el asistente. Integrar vuestra API y revisar fallos sigue llevando semanas, no una tarde. Lo que no reconstruís es el andamio entero cada vez que añadís un agente.

No hay un callejón sin salida de vendor lock-in como único camino. Podéis empezar en el producto gestionado y, cuando tengáis equipo para operarlo, pasar el mantenimiento a casa. El código se puede inspeccionar en open source. Hugging Face separa bien dos cosas que se mezclan: un plan "privado" en la API de otro sigue corriendo en servidores de otro, y local o self-hosted es hardware que controláis. El texto está en su blog sobre LLMs abiertos.

Está pensado para un producto SaaS, no para un flujo suelto entre herramientas ni para un chat genérico. Permisos por cliente, tools sobre vuestra API y un asistente dentro de la aplicación son el centro, no un extra.

Lo malo y las fricciones reales

Si sois cinco personas, probablemente es sobreingeniería. Montar el primer agente lleva minutos. Lo que no compensa a esa escala es la capa de operación: versionado de prompts, evaluaciones, costes por agente, revisión humana y tareas de mejora continua. Esa capa da valor cuando hay varios agentes, varias personas tocándolos y clientes que preguntan qué hizo el agente con sus datos. Con un caso y un equipo que además hace producto y soporte, nadie tiene tiempo de usarla. Un SDK del modelo con trazas propias os enseña más y os ata menos. Es momento de volver cuando aparezca alguna de estas señales: tres o más agentes en producción, dos personas pisándose en prompts y tools, un cliente que pide auditoría, o no saber cuánto os cuesta cada caso.

Si sois una gran empresa con requisitos a medida, seguramente no es vuestra herramienta. Devic es una plataforma, no un proyecto a medida. Pone el entorno para crear, gobernar y operar agentes. El caso, las tools sobre vuestros sistemas y la integración los pone vuestro equipo o un partner. Si la compra exige servicios profesionales dentro del contrato, desarrollo a medida, conexión con sistemas que no exponen APIs HTTP o un nivel de control sobre despliegue, datos y cambios que solo da tener el runtime en casa, mirad un integrador o un equipo de plataforma sobre un framework. Ahí no falta una función: el modelo de producto es otro.

Nuestro punto de encaje está en medio: SaaS de entre 20 y 500 personas con varios casos en marcha o a la vista, que no quieren construir y operar la infraestructura. Fuera de ese rango, el encaje baja rápido.

Todavía no hay reseñas externas que podáis contrastar. Quien busca "Devic review" se encuentra sobre todo con nuestra web y con este mismo texto, y eso tiene una consecuencia práctica: no podéis comparar diez casos públicos con nombre y con un retorno auditado por terceros, algo que sí querríais tener antes de decidir. Lo sensato es pedirnos referencias, plantear un piloto con vuestra propia API y acordar de antemano cuándo lo daríais por fallido, en lugar de fiaros de cómo os lo contamos.

Con Devic el coste no desaparece, se traslada. Dejáis de pagar buena parte del runtime que tendríais que mantener vosotros, pero seguís pagando el modelo, las llamadas a las tools, la revisión humana y el tiempo de la persona que define el caso, así que el precio de lista no refleja lo que os va a costar de verdad. Conviene mirar pricing junto con cuánto cuesta implementar un agente, porque solo con ambas se ve el coste completo.

Qué trabajo sigue siendo tuyo

Aunque el runtime no lo escribáis vosotros, estas piezas no se delegan.

El caso de uso y la métrica: qué flujo, qué es un acierto y quién es el usuario.

Las tools sobre vuestro dominio y los errores que solo vuestro producto conoce.

La política: qué puede escribir, qué pide confirmación y qué no toca. El diseño de permisos está en identidad y límites.

El conjunto de casos con los que evaluáis si el agente mejora, y la lectura de trazas cuando algo falla. Sin eso no hay mejora. La lista de qué reconstruir está en trazabilidad.

Una persona con nombre que se haga cargo a los seis meses. La plataforma no asiste a vuestra reunión de roadmap.

Si no hay nadie para esas piezas, no compréis todavía. Os vais a frustrar con el vendor por un vacío que era de producto.

Open source y producto gestionado

No son dos empresas. Son dos momentos del mismo problema.

Muchos equipos empiezan usando el producto que operamos nosotros, porque el cuello de botella es el calendario y el foco en el caso. Llegado el momento, cuando tienen los recursos, absorben el mantenimiento y la gestión in-house. Esa es la salida: no un salto el primer día, sino la posibilidad de quedaros la operación cuando el equipo dé para ello.

Elegid el producto gestionado si lo que os frena es el tiempo. Elegid open source, o un framework vuestro, si ya tenéis quien lo opere y el control pesa más que la prisa. No elijáis open source solo porque suena a menos dependencia si nadie va a mantener ese código.

Para quién encaja

Devic encaja en SaaS de entre 20 y 500 personas que quieren incorporar agentes tanto a sus operaciones internas como a su producto, y que ya tienen claro un primer caso acotado, con una API o unos datos sobre los que el agente pueda actuar. Su equipo sabe definir las tools y decidir qué puede hacer el agente y qué no, pero prefiere no dedicar meses a construir y mantener la infraestructura que hay debajo.

Sirve igual para una herramienta de backoffice que para una funcionalidad de producto, aunque en la práctica lo habitual es que las expectativas y el orden no coincidan. Muchos equipos llegan pensando en el agente dentro del producto, y es comprensible, pero acaban empezando por un caso de operaciones internas: el retorno se mide con menos incertidumbre, el riesgo queda mejor controlado porque los usuarios son vuestro propio equipo, y lo que se aprende por el camino (tools, permisos, lectura de trazas) se reutiliza después cuando el agente salga al cliente. Conviene ir con esa expectativa desde el principio, y tener presente que el primer mes suele ser de integración y ajuste, no de resultados espectaculares.

Por último, encaja cuando antes de la prueba ya podéis decir quién se hará responsable del agente y con qué métrica vais a juzgar si funciona.

Para quién no encaja

No encaja si ya tenéis un equipo de plataforma con mandato de construir y operar el runtime, sobre todo por encima de ese rango de tamaño. Ahí un framework (LangGraph o Mastra, según el stack) suele ser más coherente. La comparativa de capas está en herramientas para añadir IA a un SaaS.

No encaja si el trabajo es solo clasificar un lead y avisar en Slack. n8n, Make o Dify llegan antes, porque ahí no hay un agente con permisos ni una traza que enseñar.

No encaja si todavía no hay caso. Una plataforma no sustituye la priorización.

No encaja si necesitáis un resultado que dependa de no equivocarse nunca. Ningún producto da eso. Da límites, trazas y un sitio donde parar.

Alternativas honestas según caso

Build vs buy con más matices, incluido cuándo no comprarnos, está en tu equipo puede construir el agente.

Cómo evaluar el encaje

Antes de la prueba, responded estas preguntas con vuestra API delante, y acordaos de antemano qué resultado daríais por fallido.

¿El usuario del primer caso es vuestro equipo, un cliente del SaaS, o los dos en fases distintas?

¿Hay un flujo concreto, con una métrica, y no "el agente de toda la empresa"?

¿Podéis decir qué no puede hacer el agente, con permisos, no con un párrafo en el prompt?

¿Sabéis cuánto estáis dispuestos a gastar en ese caso antes de darlo por malo, y quién toma esa decisión?

¿Hay una persona que leerá las trazas la primera semana?

Si podéis responderlas, el siguiente paso es una prueba con el alta. Si veis que no podéis responder a alguna, mirad las alternativas de la tabla que está encima de estas líneas.