quieromisitiowebgratis
Beta
Programador
¡Usuario con pocos negocios! ¡Utiliza siempre saldo de Forobeta!
Hace varios meses vengo desarrollando Digimates. La idea nació de una pregunta bastante simple: ¿qué tendría que existir para que una pyme pueda tener un agente de IA realmente operativo, conectado a sus sistemas y listo para trabajar, sin tener que montar toda la infraestructura técnica que hay detrás?
No hablo de un chatbot con un prompt. Hablo de un agente con reglas propias, conocimiento de la empresa, memoria persistente, herramientas, permisos, acceso a archivos, repositorios, APIs, capacidad de ejecutar tareas y canales como webchat o WhatsApp. El objetivo que me propuse fue que todo eso pudiera configurarse visualmente y que, desde la creación del cliente hasta tener el agente desplegado, el proceso pudiera hacerse en menos de una hora.
Cómo está armado
La parte visual y de gestión está desarrollada en Laravel. Desde ahí puedo crear clientes, crear agentes, asignar usuarios, definir reglas e instrucciones, cargar conocimientos, configurar memoria, conectar herramientas, repositorios, APIs y canales, elegir modelo y razonamiento y desplegar el agente.
Pero Laravel no ejecuta la IA directamente. Construí un runtime separado al que llamé MateClaw, desarrollado en Python/FastAPI. Laravel se comunica con MateClaw mediante una API interna y el runtime se encarga de la ejecución real del agente, herramientas, workspaces, memoria, repositorios y permisos.
A grandes rasgos:
Usuario/Empresa -> Digimates/Laravel -> API interna -> MateClaw/Python -> Agente -> herramientas/datos/APIs/Git/archivos
Cada agente trabaja dentro de su propio entorno y tiene únicamente las capacidades que se le habilitan. La idea es que no sea simplemente una IA que responde, sino una pieza operativa dentro de la empresa.
Conocimiento, reglas y memoria
Cada agente puede tener conocimiento específico de la empresa: documentación interna, procedimientos, productos, políticas, información comercial y archivos PDF, DOCX, XLSX, TXT, etc. Ese conocimiento se procesa y llega al runtime para que pueda utilizarlo durante las tareas.
También puede tener reglas propias. Por ejemplo: “no modificar producción sin confirmación”, “para este cliente el stock se calcula de determinada manera”, “no mostrar cierta información a usuarios externos” o “al terminar una modificación de código, compilar y verificar antes de entregar”.
Además implementé memoria persistente. La idea es que el agente pueda conservar información útil entre conversaciones sin depender únicamente del historial del chat.
Herramientas y acciones
Para mí esta es una de las partes más interesantes. El agente puede tener herramientas reales: consultar APIs, leer archivos, trabajar sobre repositorios Git, modificar código, ejecutar comandos, compilar, consultar bases de datos, procesar documentos o comunicarse con otros servicios.
Eso permite pasar de “te explico cómo hacerlo” a “lo hago, verifico el resultado y te cuento qué pasó”.
También implementé integración con GitHub con acceso de solo lectura o lectura/escritura. En modo escritura un agente puede analizar el repo, modificar código, validar, compilar o ejecutar pruebas, revisar el diff, hacer commit y push.
Entornos aislados y canales
Los agentes se despliegan de manera aislada por cliente. Cada empresa puede tener su propio entorno, archivos, configuración, memoria, credenciales y herramientas.
También integré canales de conversación. Hoy un agente puede atender desde webchat, portal, API y WhatsApp. La misma lógica del agente puede utilizarse desde distintos canales sin construir otro bot desde cero para cada uno.
Qué intento construir
No intento construir un modelo de IA. Uso modelos existentes como motor de razonamiento. Lo que estoy intentando construir es la capa que convierte ese modelo en algo realmente utilizable por una empresa:
modelo + conocimiento + reglas + memoria + herramientas + permisos + infraestructura + canales = agente operativo
Y que toda esa complejidad quede escondida detrás de un panel sencillo.
Lo comparto porque llegué a un punto donde me interesa mucho más recibir opiniones técnicas que mostrar una landing bonita. Me interesa especialmente saber qué opinan sobre la separación Laravel/runtime Python, aislamiento por cliente, herramientas y permisos, memoria persistente, agentes trabajando sobre repositorios reales, riesgos de seguridad y casos de uso donde algo así tendría sentido o donde creen que no.
Si alguno quiere verlo: digimates.com.ar
Toda crítica técnica es bienvenida.
No hablo de un chatbot con un prompt. Hablo de un agente con reglas propias, conocimiento de la empresa, memoria persistente, herramientas, permisos, acceso a archivos, repositorios, APIs, capacidad de ejecutar tareas y canales como webchat o WhatsApp. El objetivo que me propuse fue que todo eso pudiera configurarse visualmente y que, desde la creación del cliente hasta tener el agente desplegado, el proceso pudiera hacerse en menos de una hora.
Cómo está armado
La parte visual y de gestión está desarrollada en Laravel. Desde ahí puedo crear clientes, crear agentes, asignar usuarios, definir reglas e instrucciones, cargar conocimientos, configurar memoria, conectar herramientas, repositorios, APIs y canales, elegir modelo y razonamiento y desplegar el agente.
Pero Laravel no ejecuta la IA directamente. Construí un runtime separado al que llamé MateClaw, desarrollado en Python/FastAPI. Laravel se comunica con MateClaw mediante una API interna y el runtime se encarga de la ejecución real del agente, herramientas, workspaces, memoria, repositorios y permisos.
A grandes rasgos:
Usuario/Empresa -> Digimates/Laravel -> API interna -> MateClaw/Python -> Agente -> herramientas/datos/APIs/Git/archivos
Cada agente trabaja dentro de su propio entorno y tiene únicamente las capacidades que se le habilitan. La idea es que no sea simplemente una IA que responde, sino una pieza operativa dentro de la empresa.
Conocimiento, reglas y memoria
Cada agente puede tener conocimiento específico de la empresa: documentación interna, procedimientos, productos, políticas, información comercial y archivos PDF, DOCX, XLSX, TXT, etc. Ese conocimiento se procesa y llega al runtime para que pueda utilizarlo durante las tareas.
También puede tener reglas propias. Por ejemplo: “no modificar producción sin confirmación”, “para este cliente el stock se calcula de determinada manera”, “no mostrar cierta información a usuarios externos” o “al terminar una modificación de código, compilar y verificar antes de entregar”.
Además implementé memoria persistente. La idea es que el agente pueda conservar información útil entre conversaciones sin depender únicamente del historial del chat.
Herramientas y acciones
Para mí esta es una de las partes más interesantes. El agente puede tener herramientas reales: consultar APIs, leer archivos, trabajar sobre repositorios Git, modificar código, ejecutar comandos, compilar, consultar bases de datos, procesar documentos o comunicarse con otros servicios.
Eso permite pasar de “te explico cómo hacerlo” a “lo hago, verifico el resultado y te cuento qué pasó”.
También implementé integración con GitHub con acceso de solo lectura o lectura/escritura. En modo escritura un agente puede analizar el repo, modificar código, validar, compilar o ejecutar pruebas, revisar el diff, hacer commit y push.
Entornos aislados y canales
Los agentes se despliegan de manera aislada por cliente. Cada empresa puede tener su propio entorno, archivos, configuración, memoria, credenciales y herramientas.
También integré canales de conversación. Hoy un agente puede atender desde webchat, portal, API y WhatsApp. La misma lógica del agente puede utilizarse desde distintos canales sin construir otro bot desde cero para cada uno.
Qué intento construir
No intento construir un modelo de IA. Uso modelos existentes como motor de razonamiento. Lo que estoy intentando construir es la capa que convierte ese modelo en algo realmente utilizable por una empresa:
modelo + conocimiento + reglas + memoria + herramientas + permisos + infraestructura + canales = agente operativo
Y que toda esa complejidad quede escondida detrás de un panel sencillo.
Lo comparto porque llegué a un punto donde me interesa mucho más recibir opiniones técnicas que mostrar una landing bonita. Me interesa especialmente saber qué opinan sobre la separación Laravel/runtime Python, aislamiento por cliente, herramientas y permisos, memoria persistente, agentes trabajando sobre repositorios reales, riesgos de seguridad y casos de uso donde algo así tendría sentido o donde creen que no.
Si alguno quiere verlo: digimates.com.ar
Toda crítica técnica es bienvenida.
