Departamento de Agentes y Desarrollo
El departamento arranca ahora, así que todavía no tenemos casos de cliente que enseñar. Lo que sí podemos demostrar es cómo trabajamos: el diagrama que acompaña a este texto no es una ilustración, es un bloque a medida construido para esta web. La misma clase de pieza que montamos dentro de tu operativa.
Cuatro tipos de pieza, pensadas para combinarse. Cuáles hacen falta y en qué orden es una decisión del proyecto, y se toma al acotar el proceso, no antes.
Un agente es un programa que recibe una tarea, decide qué pasos dar y usa herramientas para darlos: leer un buzón, consultar el ERP, generar un documento, avisar por chat. Lo construimos ad hoc para una tarea concreta de tu empresa, con sus reglas y su vocabulario, en lugar de entregar un asistente genérico al que hay que explicarle el contexto cada vez.
El trabajo que hoy se hace copiando de una pantalla a otra. Conectamos las herramientas que ya usas y dejamos el proceso corriendo solo, con un registro de qué hizo y cuándo, para que se pueda auditar y repetir si algo sale mal.
Un buscador interno que responde con tu documentación y no con lo que hay en internet. RAG —generación aumentada por recuperación— significa que, antes de redactar, el sistema recupera de tus documentos los fragmentos que vienen al caso y el modelo escribe a partir de ellos. Encima de eso añadimos la referencia al documento del que sale cada respuesta: no forma parte de RAG, es una decisión de construcción, y es lo que permite comprobar lo que responde.
Nada de esto sirve si vive fuera de tus sistemas. Trabajamos contra las API de lo que ya tienes —correo, CRM, ERP, gestor documental, hojas de cálculo— y, cuando una herramienta no ofrece API, se dice antes de empezar y se decide qué vía de entrada y salida se monta en su lugar.
El modelo de lenguaje se ocupa del texto y del significado. El código se ocupa de los datos y de los números. La decisión final es de una persona.
Parece una obviedad y es justo la línea que separa una automatización fiable de una demostración bonita. Un modelo de lenguaje es excelente entendiendo un correo ambiguo y pésimo sumando una columna: si le pides el total de una factura, a veces acierta. El código también tiene errores, pero es determinista: con la misma entrada devuelve siempre la misma salida, así que un fallo se puede reproducir, localizar y corregir de una vez. Eso es lo que necesitas cuando ese número acaba en una declaración.
Lee, clasifica, resume, redacta y reconoce a qué caso se parece lo que acaba de entrar. Todo lo que es lenguaje y criterio.
Suma, compara contra la base de datos, aplica el impuesto, valida el identificador fiscal y escribe en el sistema. Todo lo que tiene que salir exacto todas las veces.
Aprueba lo que tiene consecuencias: enviar al cliente, pagar, firmar. El agente prepara y propone; el paso irreversible lo da alguien de tu equipo.
De ahí sale la otra regla de la casa: cada automatización que entregamos deja rastro. Qué entró, qué interpretó el modelo, qué calculó el código y quién dio el visto bueno. Si no se puede reconstruir lo que pasó, no está terminado.
Una revisión de toda la web, contada en las dos versiones: repasando página por página, o con un proceso que las recorre todas y deja registro de lo que tocó.
| Concepto | A mano | Automatizado |
|---|---|---|
| Enlaces sin destino | 154 enlaces | 0 enlaces |
| Imágenes sin texto alternativo | 221 imágenes | 0 imágenes |
| Archivos sin nombre con sentido | 46 archivos | 0 archivos |
| Cómo se recorre | Página por página | Una pasada verificada |
Medición de agosto de 2026 sobre esta misma web.
No hace falta saber qué se puede automatizar antes de preguntarlo. Empieza por donde trabajas y mira si te suena el problema.
Facturas que llegan por correo, cada proveedor con su formato, y hay que meter a mano en el ERP. Un agente las lee, extrae los campos, comprueba que el importe cuadra con el pedido y deja el asiento preparado. Lo que no cuadra no se cuela: se queda en una bandeja de revisión con el motivo por el que se ha parado.
Correos y formularios que hay que cualificar, resumir y volcar al CRM antes de que la oportunidad se enfríe. Un agente resume la conversación, la clasifica según tus criterios, actualiza la ficha y deja escrito el borrador de respuesta para que el comercial solo tenga que leerlo, ajustarlo y enviarlo.
Una misma pieza que hay que adaptar a varios canales con el mismo mensaje y distinto formato. Un agente parte del material ya aprobado, respeta el tono de la marca y deja las variantes listas para revisión. La publicación sigue siendo una decisión de una persona, no un automatismo.
Candidaturas, dudas repetidas de plantilla y documentación de incorporación. Un agente cruza cada currículum con los requisitos reales del puesto y explica por qué encaja o no, en lugar de dar una puntuación sin justificar. Y un copiloto responde las preguntas del convenio citando el documento del que sale cada respuesta.
Gobernanza
Es la pregunta que hay que responder antes que ninguna otra, y admite una respuesta concreta: el perímetro de confianza se decide contigo antes de empezar y queda por escrito.
Un agente puede correr entero dentro de tu infraestructura, o usar un proveedor de modelo externo solo para la parte de lenguaje. Son dos decisiones distintas, con dos costes distintos y dos niveles de exposición distintos. Se toman juntos, no por defecto.
El ERP, el CRM y los documentos siguen donde están. El agente trabaja contra sus API.
Aquí viven las reglas, los permisos y el registro de cada ejecución.
Puede correr dentro de tu infraestructura o ser un servicio externo. Es una decisión que se toma antes de empezar, no después.
Cuando haya proyectos entregados y el cliente autorice publicarlos, se contarán aquí: el problema de partida, lo que se construyó y lo que se midió. Todavía no hay ninguno.
Aquí se publicará el primer proyecto entregado, cuando exista y el cliente autorice contarlo.
El segundo espacio queda a la espera del mismo requisito: trabajo terminado y permiso para publicarlo.
El tercero se rellenará cuando haya recorrido suficiente que enseñar, no antes.
Las dudas técnicas que salen siempre en la primera reunión, respondidas sin rodeos.
No. Un chatbot conversa; un agente ejecuta. La diferencia práctica es que un agente tiene permiso para hacer cosas en tus sistemas —leer un buzón, escribir en el CRM, generar un documento— y una lista acotada de pasos que puede dar. Algunos proyectos incluyen además una interfaz de conversación, pero suele ser la parte menos importante del encargo.
Se da por hecho que alguna vez se va a equivocar, y por eso el diseño no depende de que acierte siempre. Los cálculos y las validaciones los hace código, que es determinista. Lo que el modelo interpreta se contrasta contra el dato original siempre que ese dato exista, y lo que no supera la comprobación no sigue adelante: se queda esperando revisión con el motivo anotado.
No es el punto de partida. Se trabaja contra lo que ya usas, a través de sus API. Si alguna herramienta no ofrece forma de conectarse, se dice antes de empezar y se decide qué hacer: buscar otra vía de entrada, cambiar el orden del proceso o dejar ese paso fuera del alcance.
Con el que encaje con el caso y con tu política de datos, y se puede cambiar después. Los proyectos se construyen de forma que el proveedor de modelo sea una pieza sustituible y no el cimiento: atarse a uno solo es un riesgo innecesario en un mercado que se mueve cada pocos meses.
Depende del proceso y de lo accesibles que sean los sistemas, y no vamos a dar un plazo aquí sin haberlo visto. Lo que sí es fijo es el orden: primero se acota un proceso concreto y comprobable, se construye eso, se pone a funcionar de verdad y solo entonces se amplía. Abrir un alcance grande de entrada es una de las formas más habituales de que un proyecto de automatización se quede sin llegar a producción.
Se entrega documentado y con el registro de ejecuciones accesible, para que tu equipo pueda ver qué está pasando sin depender de nosotros. A partir de ahí, el mantenimiento puede quedarse dentro o llevarlo nosotros; se decide al cerrar el proyecto, no al firmarlo.
Ordenados del todo, no. Accesibles, sí. Si un dato solo existe en la cabeza de alguien o en un PDF escaneado sin capa de texto, hay un trabajo previo que hacer y conviene saberlo antes y no a mitad. La primera conversación sirve sobre todo para detectar eso.
Mejor. Se revisa lo que hay, se dice con claridad qué se aprovecha y qué no, y se construye encima. No hay ningún interés en rehacer algo que ya está funcionando.
Escríbenos con el proceso que más tiempo te está costando esta semana. En la primera conversación te decimos si se puede automatizar, qué haría falta para hacerlo y qué no tiene sentido intentar todavía. Si la respuesta es que no compensa, también te la damos.
¿Todavía necesitas saber por dónde empezar? Empieza por una consultoría de diagnóstico.
