Cómo está construido ClawAI

Dieciocho servicios desplegables de forma independiente, cada uno con su propia base de datos, coordinados mediante una arquitectura orientada a eventos. Las respuestas se transmiten mientras se generan y cada capa está protegida por separado.

Última revisión 2026-07-25

Cómo está construido ClawAI

ClawAI son dieciocho servicios desplegables de forma independiente detrás de un único proxy inverso. Autenticación, chat, enrutamiento, conectores, memoria, archivos, investigación, espacio de trabajo, generación de imágenes, exportación de documentos, facturación, auditoría y registro se ejecutan cada uno como su propio proceso con su propia base de datos. La aplicación web accede a todos ellos a través de una sola superficie de API.

La razón es la contención. Un proveedor lento, una conversión de archivo atascada o una exportación fallida no pueden derribar el chat con ellos, porque no comparten proceso, ni grupo de conexiones, ni base de datos. Cada servicio se despliega, se escala y se revierte de forma independiente.

18: Servicios desplegables de forma independiente
Una por servicio: Nunca hay una base de datos compartida
HTTP + eventos: Llamadas síncronas más un bus de eventos asíncrono
Un solo punto de entrada: Un único proxy inverso delante de todo

Los servicios

No todos los servicios son interesantes desde fuera. Estos son los que una sola solicitud suele tocar, aproximadamente en el orden en que los toca.

AutenticaciónPostgreSQL: Cuentas, sesiones, emisión de tokens y rotación de actualización, roles y conjuntos de permisos.
ChatPostgreSQL: Conversaciones y mensajes, ensamblaje de contexto, ejecución en streaming y orquestación multimodelo.
EnrutamientoPostgreSQL: Clasifica cada mensaje, aplica el modo activo y las políticas correspondientes, y registra la decisión junto con su cadena de respaldo.
ConectoresPostgreSQL: Credenciales de proveedores, catálogos de modelos, indicadores de capacidad y comprobaciones de estado continuas.
Memoria y contextoPostgreSQL + pgvector: Registros de memoria, la cola de sugerencias, los paquetes de contexto y sus versiones, y la recuperación semántica.
ArchivosPostgreSQL: Subidas, análisis de seguridad, extracción de texto, OCR, fragmentación y retención.
InvestigaciónPostgreSQL: Búsqueda web, obtención de páginas y ensamblaje de evidencias para respuestas con fuentes.
Espacio de trabajoPostgreSQL: Conexiones OAuth con doce herramientas externas, webhooks, sincronización programada y búsqueda entre herramientas.
Generación de imágenesPostgreSQL: Solicitudes de imágenes, adaptadores de proveedores y progreso por etapas mientras se renderiza una imagen.
Generación de documentosPostgreSQL: Convertir respuestas en PDF, DOCX, CSV, HTML, Markdown, TXT y JSON.
FacturaciónPostgreSQL: Planes, suscripciones, precios con control de versiones, facturas y aplicación de cupos.
AuditoríaMongoDB: El registro inmutable de quién hizo qué, además del libro de uso del que se derivan todas las cifras de cupo.
RegistroMongoDB: Registros estructurados de cada servicio y del navegador, conservados en una ventana móvil.

Cada servicio nombra la base de datos que posee. Nada más se conecta a ella: un servicio que necesita los datos de otro los solicita por HTTP o reacciona a un evento.

Una base de datos por servicio

Cada servicio posee exactamente una base de datos y es lo único que se conecta a ella. No hay ningún esquema compartido, ningún join entre servicios, ni ninguna base de datos de informes que lea silenciosamente las tablas de todos.

El costo es que algunas preguntas requieren dos llamadas en lugar de un join. El beneficio es que un cambio de esquema en facturación no puede romper el chat, y una consulta descontrolada en el registro no puede agotar el grupo de conexiones del que depende su conversación.

Sin consultas entre bases de datos: Un servicio lee sus propias tablas y las de ningún otro. Los datos de otro lugar llegan mediante una llamada a la API o un evento.
Los esquemas son privados: Un servicio puede cambiar sus propias tablas sin coordinarse con nadie, porque ningún consumidor externo depende de su forma.
Las migraciones se ejecutan por servicio: Cada servicio migra su propia base de datos al iniciarse. No existe ninguna migración global que todos deban esperar.
Los fallos se quedan en lo local: Una base de datos lenta o no disponible degrada una sola capacidad en lugar de todo el producto.

El ciclo de vida de una solicitud

Qué ocurre entre pulsar enviar y leer la respuesta.

Se autentica la solicitud
el proxy inverso la pasa al chat, que verifica su token de acceso y los permisos asociados a su rol.
Se comprueba el cupo
facturación confirma que su plan permite el modelo que solicitó y que su cupo diario y mensual todavía tiene margen.
El mensaje se almacena y se anuncia
chat escribe el mensaje en su propia base de datos y publica un evento. Enrutamiento está a la escucha de él.
Enrutamiento elige un modelo
el mensaje se clasifica, se aplican el modo activo y las políticas, se consulta el estado de los conectores, y se registra una decisión junto con una cadena de respaldo.
Se ensambla el contexto
chat solicita a memoria los registros y elementos de paquetes relevantes, y a archivos los fragmentos relevantes, y luego los combina en el prompt dentro de un presupuesto de tokens.
Se llama al modelo y se transmite
chat llama al proveedor y reenvía etapas, texto, razonamiento y métricas a su navegador mediante Server-Sent Events a medida que llegan.
El resultado se persiste
la respuesta, su decisión de enrutamiento, sus recuentos de tokens y su recibo de contexto se registran juntos.
Se registran el uso y la auditoría
facturación mide el costo frente a su cupo y auditoría registra el evento. Aquí también se ejecuta la extracción de memoria.

Los pasos 1 a 7 son síncronos: usted los espera. El paso 8 y la extracción de memoria ocurren después de que la respuesta ya está en su pantalla, por lo que no añaden latencia a lo que usted experimenta.

El bus de eventos

El trabajo que no necesita terminar antes de que usted vea una respuesta se publica como un evento en un intercambio de tipo topic de RabbitMQ y lo gestiona cualquier servicio interesado en él. La medición de uso, los registros de auditoría y la extracción de memoria funcionan todos así.

Los eventos son la razón por la que chat no necesita saber que auditoría existe. Chat declara lo que ocurrió; cualquier cosa que necesite reaccionar se suscribe. Añadir un consumidor no requiere ningún cambio en el publicador.

Intercambio de tipo topic: Los publicadores nombran lo que ocurrió, no quién debe escucharlo. Los consumidores se vinculan a los patrones que les interesan.
Reintentos con retroceso: Un manejador que falla se reintenta tres veces con un retraso creciente, lo cual absorbe los fallos transitorios que constituyen la mayoría de ellos.
Cola de mensajes fallidos: Un mensaje que sigue fallando tras sus reintentos pasa a una cola de mensajes fallidos en lugar de descartarse o bloquear todo lo que viene detrás.
Manejadores idempotentes: Los manejadores toleran que el mismo evento llegue dos veces, porque la entrega de «al menos una vez» garantiza que tarde o temprano ocurrirá.
Todo es auditable: Auditoría se suscribe a todos los eventos de dominio, de modo que el registro de lo ocurrido no depende de que cada servicio recuerde escribir uno.

Transmisión en tiempo real

Las respuestas llegan mediante Server-Sent Events, no por sondeo. La conexión se abre cuando usted envía un mensaje y transporta todo hasta que la respuesta termina o se cancela.

El almacenamiento en búfer está desactivado de extremo a extremo —en el proxy y en cada servicio del recorrido—, porque un flujo con búfer no es más que una respuesta lenta con pasos adicionales.

El mismo canal transporta la generación de texto, el progreso de la generación de imágenes y las investigaciones de larga duración, de modo que la interfaz tiene una sola forma de mostrar el trabajo en curso en lugar de tres.

Cambios de etapa: En cola, enrutando, ensamblando contexto, llamando al modelo, finalizando: así una pausa siempre tiene un motivo visible.
Deltas de contenido: El texto de la respuesta a medida que el modelo lo produce, token a token.
Deltas de razonamiento: Para los modelos que exponen su pensamiento, el flujo de razonamiento se entrega por separado de la respuesta y también se muestra por separado.
Pulsos de métricas: Tokens hasta el momento, tokens por segundo, tiempo hasta el primer token, y en qué se fue realmente el tiempo: carga del modelo, evaluación del prompt o generación.
Eventos terminales: Un resumen final de uso, o un error o cancelación explícitos. El flujo nunca simplemente se detiene.

Qué almacena qué

Cuatro tipos de almacenamiento, cada uno empleado para aquello en lo que destaca.

PostgreSQL: El sistema de registro para cuentas, conversaciones, decisiones de enrutamiento, memoria, archivos, conexiones y facturación: una base de datos por servicio.
pgvector: Búsqueda de similitud vectorial dentro de PostgreSQL, utilizada para recuperar memorias y elementos de paquetes de contexto relevantes sin ejecutar una base de datos vectorial independiente.
MongoDB: Eventos de auditoría, el libro de uso y registros estructurados: datos de alto volumen de solo anexado con una ventana de retención móvil.
Redis: Caché, contadores de límite de tasa y estado de coordinación de corta duración. Nada importante se almacena únicamente aquí.

Mecanismos de seguridad

Controles concretos que existen en el producto. Sin afirmaciones de certificación: consulte la nota al final.

Tokens de acceso y actualización: Tokens de acceso de corta duración con rotación de actualización. Reutilizar un token ya rotado invalida la sesión.
Cifrado de contraseñas: Argon2 con sales por usuario. Las contraseñas nunca se almacenan ni se registran en ninguna forma recuperable.
Control de acceso basado en roles: Los roles llevan conjuntos explícitos de permisos, aplicados mediante guardas en cada endpoint de cada servicio, no solo en la interfaz.
Credenciales cifradas: Los secretos de proveedores y conectores se cifran en reposo con AES-256-GCM y ninguna API los devuelve nunca.
Validación de esquemas: Cada cuerpo de solicitud se valida contra un esquema de Zod con límites explícitos de longitud y tamaño antes de llegar a cualquier lógica.
Limitación de tasa: Regulación por cuenta en cada servicio, de modo que un solo cliente no pueda agotar la capacidad de todos los demás.
Cabeceras de seguridad: Una política de seguridad de contenido estricta con nonces por solicitud, HSTS, y las cabeceras de refuerzo estándar en cada respuesta.
TLS en todas partes: TLS desde el navegador hasta el borde y de nuevo en cada salto interno, con verificación de certificados entre servicios.
Redacción de registros: Los tokens, contraseñas, claves de API y cabeceras de autorización se eliminan antes de escribir nada en un registro.

ClawAI no cuenta hoy con certificaciones de seguridad de terceros: ni SOC 2, ni ISO 27001, ni HIPAA. Describimos los mecanismos anteriores en lugar de dar a entender garantías que no hemos obtenido. Las organizaciones con requisitos formales deben planteárnoslos para que puedan dimensionarse como parte de un proyecto.

Observabilidad

Cada servicio emite las mismas señales con la misma forma, y todas terminan en algún lugar consultable. Un operador que responde a «qué pasó con esta solicitud» no debería tener que abrir dieciocho archivos de registro.

Registros estructurados: Registros JSON de cada servicio y del navegador, transportados por el bus de eventos y conservados en una ventana móvil.
Correlación de solicitudes: Se genera un ID de solicitud en el navegador y se transporta a través de cada salto entre servicios, de modo que un solo identificador reconstruye todo el recorrido.
Eventos de auditoría: Un registro independiente e inmutable de las acciones relevantes para la seguridad y el negocio, mantenido aparte de los registros operativos.
Libro de uso: Cada llamada medida se escribe como una entrada en el libro. Las cifras de cupo se derivan del libro, no de un contador que pudiera desviarse.
Agregación de estado: Un servicio dedicado consulta a todos los demás servicios e informa de una sola vista consolidada de lo que está en funcionamiento.

Cuando algo falla

Los proveedores de modelos sufren interrupciones, límites de tasa y días lentos. La plataforma está diseñada para absorberlos en lugar de trasladárselos a usted como un indicador de carga que nunca se resuelve.

Cadenas de respaldo: Cada decisión de enrutamiento lleva una lista ordenada de alternativas. Si el modelo elegido falla, se prueba el siguiente automáticamente y se registra la sustitución.
Evitación basada en el estado: El estado de los conectores se comprueba de forma continua, y el enrutador evita un proveedor que está fallando hasta que se recupera.
Reintentos seguros: Los manejadores de eventos toleran la entrega duplicada, de modo que un reintento corrige un fallo en lugar de cobrar su cupo dos veces.
Los errores son visibles: Cuando todas las opciones fallan, se escribe un error explícito en la conversación y se envía por el flujo. No hay ningún fallo silencioso que deje la interfaz esperando.
Radio de impacto: Procesos y bases de datos separados hacen que un fallo degrade una sola capacidad. Que la generación de imágenes esté caída no le impide chatear.

La misma arquitectura, dentro de su red

Todo lo que aparece en esta página describe el servicio alojado, pero la arquitectura no está atada a él. Los mismos dieciocho servicios, el mismo bus de eventos y el mismo modelo de datos pueden desplegarse dentro de la propia red de una organización.

En esa configuración, los proveedores de modelos externos se sustituyen por modelos de pesos abiertos servidos en sus propias GPU, de modo que ningún prompt, documento o conversación sale de su infraestructura. Se trata de un proyecto delimitado y no de un plan que se compra: lo dimensionamos junto con su equipo.

Hable con nosotros sobre un despliegue privado

Véalo en funcionamiento

La forma más rápida de juzgar una arquitectura es usar lo que produce. El plan gratuito tarda un minuto en configurarse.

Cree su cuenta Hable con nosotros sobre un despliegue privado