Cauce V3· flota multi-agente
Catálogo Agendar WhatsApp
Sistema multi-agente · v3

Cauce V3

Una flota de agentes de IA que fluye por un solo cauce.

Mensajería durable, identidad verificable, aislamiento multi-tenant y control humano para agentes en Claude Code, Codex y OpenClaw.

publicar → persistir → reclamar → ejecutar → confirmar
desplazá o usá ↓ / →
01 · El problema y la respuesta

Los agentes sueltos
no escalan.

Un asistente de IA suelto sirve para una charla. Una operación real necesita muchos agentes, para varios dueños, sin pisarse ni filtrarse entre sí.

  • Se pisan y duplican trabajo: nadie coordina.
  • No hay memoria: cada sesión arranca de cero.
  • Sin aislamiento: los datos de un cliente se cruzan con otro.
  • Corren en bucles caros que queman cuota sin control.
  • Nadie audita ni revisa lo que producen.
La respuesta

Cauce V3

Una flota de agentes especializados coordinada sobre un bus durable: cada entrega queda registrada, la identidad se deriva en el borde y cada adaptador reclama únicamente el trabajo que le corresponde.

14agentes en el inventario canónico
4tenants activos
3harnesses interoperables
1PostgreSQL como verdad durable
02 · Arquitectura

Del mensaje al agente, por capas

Canales externos publican por HTTP al gateway. PostgreSQL conserva el trabajo. Cada agente, vía su Adapter SDK, sostiene una conexión WebSocket por la que reclama sólo lo suyo, con claim token + epoch. El agente responde por el mismo bus. La identidad, la membresía y el aislamiento atraviesan todas las capas.

INGRESO · HTTP PUBLICO Telegram bridge CLI operador API de cliente la consola web lee y configura, no publica trabajo Gateway HTTP autentica principal · deriva identidad · aplica membresía/ACL · valida payload · publica PostgreSQL · única fuente durable mensajes · deliveries · outbox · DLQ · fan-in · agentes · configuración · auditoría pull: claim + ACK (claim_token + epoch) push: respuesta del agente Adapter SDK · consumidor durable por alias WebSocket de larga vida · reclama sólo su cola · fencing evita dos consumidores activos Harness: Claude Code · Codex · OpenClaw el adaptador normaliza la entrega y la pega en la sesión tmux/API del agente Agente especializado rol + workspace + contexto nativo + herramientas · emite {reply, messages, artifacts, notify} publicar al canal original Dispatcher · segador de reintentos • NO distribuye mensajes ni elige agentes • recupera claims vencidos y libera trabajo abandonado • corre el probe de salud de PostgreSQL Plano de terminal (operador) El agente abre una conexión saliente mTLS hacia el relay. El navegador ve la terminal; nunca expone un puerto en el contenedor del agente. navegador terminal-relay Cauce opera este plano de terminal; los harnesses sólo tienen sesión PTY. CAPA TRANSVERSAL · identidad, membresía, ACL default-deny, secretos por referencia, auditoría de mutaciones

HTTP entra, PostgreSQL persiste, el Adapter SDK tira del trabajo por WebSocket, el harness lo ejecuta, el reply vuelve por el mismo bus y se publica en el canal original. Si un agente muere, el claim vence y el dispatcher lo libera.

03 · El corazón

El bus event-driven, explicado

Cauce V3 separa la conexión durable del adaptador del turno de IA. El adaptador mantiene WebSocket; el agente sólo ejecuta cuando hay una entrega reclamada y termina con un ACK estructurado.

Publicargateway deriva identidad PersistirPostgreSQL + outbox Reclamarclaim_token + epoch Ejecutarharness + tools + rol Confirmaraccepted→started→done

Entrega durable

Mensaje, entrega, outbox y resultado quedan en PostgreSQL. La idempotencia evita reaplicar el mismo evento.

Identidad verificada

El gateway deriva actor, tenant, sesión y canal del principal autenticado; el payload no puede autodeclararlos.

Turnos acotados

El turno empieza con una entrega reclamada y termina en done o failed; el adaptador sigue conectado.

Ruteo autorizado

Origen y destino requieren membresía activa y una ACL dirigida con allow_route; el default es negar.

Recuperable

Las entregas terminales fallidas conservan causa y evidencia en DLQ; el replay exige controles explícitos.

Recuperación cercada

El dispatcher vence claims rancios. El epoch impide que un consumidor viejo confirme después del reemplazo.

04 · Multi-tenant

Aislamiento
por diseño

Cada cliente es un tenant con salas, membresías y ACL propias. El gateway y PostgreSQL aplican la frontera; la ubicación física se gestiona aparte y puede compartir contenedor dentro del mismo tenant.

  • Identidad no editable: tenant y alias salen del principal autenticado.
  • Default-deny: sin membresía y ACL dirigida no hay ruteo ni lectura.
  • Visibilidad mínima: compartir un hub no concede acceso a mensajes ajenos.
  • Gobierno por agente: rol, workspace, contexto nativo y permisos se mantienen por alias.
  • Credenciales fuera del mensaje: se vinculan al runtime autorizado, no viajan en entregas.
Tenant hub configurado como datos Cliente A Cliente B Cliente C Cliente D ✕ = bloqueado salvo ACL dirigida explícita
05 · Cómo se gobierna

Gobierno visible, no magia

La flota se opera desde datos durables: roles, agentes, cuentas, rutas, colas y cambios quedan visibles. La consola no inventa estado; consulta las fachadas filtradas del gateway.

Control operacional
liveFlota y entregas en vivoEstado por alias, mensajes, colas, reintentos, DLQ y último error accionable.
termTerminal seguraAcceso web a PTY y ficheros de gobierno mediante relay con fencing y mTLS.
faninDelegación que vuelveEl fan-in materializa respuestas de cadenas A→B→C antes de devolverlas al origen.
Configuración durable
OCCCambios versionadosMutaciones con revisión esperada evitan que dos operadores se pisen en silencio.
RBACPermisos explícitosRuteo, lectura y control nacen en false; cada capacidad se concede por política.
auditAuditoríaLas decisiones del borde y las mutaciones quedan registradas para reconstruir qué ocurrió.
control humano

Cauce coordina y deja evidencia; no reemplaza la autoridad. Las acciones sensibles conservan gates humanos definidos por cada organización.

06 · Capacidades

Qué trae listo

Cauce V3 es la capa común entre canales, almacenamiento, agentes y operación. No depende de un solo CLI ni de un solo proveedor de IA.

Entradas reales

Telegram, consola web y CLI de operador publican por la misma frontera autenticada.

Multi-harness

Claude Code, Codex y OpenClaw hablan el mismo contrato durable mediante adaptadores.

Multi-tenant

Membresías, ACL, visibilidad y configuración se aplican por tenant con default-deny.

Entrega durable

Mensajes, ACK, reintentos, fan-in y DLQ sobreviven reinicios y desconexiones.

Flota como datos

Altas, bajas, harnesses, roles y ubicación se derivan de un inventario canónico.

Fencing

Epoch y claim tokens impiden que una conexión vieja confirme trabajo ajeno o repetido.

Cuentas gobernadas

Suscripciones, límites de ruteo y fallback son configuración durable y auditable.

Observabilidad

Consola, auditoría, métricas y terminal muestran el estado que realmente existe.

07 · Diferenciadores

Por qué es diferente

Lo que Cauce V3 no es

  • No es un chatbot: es una flota que trabaja, coordina y se audita.
  • No es un pipeline rígido: los agentes reaccionan a eventos, no a un orden fijo.
  • No es un fan-out sin memoria: cada delegación queda registrada y se sigue.
  • No es un SaaS de terceros: corre en infraestructura propia, con los datos en casa.

Lo que lo hace distinto

  • Durable + event-driven: el trabajo nace de una entrega registrada.
  • Identidad derivada: el payload no puede elegir quién dice ser.
  • Aislamiento reforzado a nivel de datos, no solo por convención.
  • Claims cercados: un consumidor reemplazado no puede cerrar trabajo.
  • Interoperabilidad: tres harnesses bajo un contrato común.
  • Self-hosted: control operativo sobre datos, red y credenciales.
08 · Protocolo

Cada entrega habla el mismo idioma

El bus normaliza lo que un harness devuelve: una respuesta que vuelve (reply), los traspasos que se abren (messages), las intervenciones humanas (notify) y los artefactos que localizan la evidencia.

resultado.cauce
{
  "reply": "Entrega lista para revisión.",
  "messages": [],
  "notify": [],
  "status": "done",
  "retryable": false,
  "artifacts": [
    {
      "name": "aplicacion-verificada",
      "uri": "/entregas/producto",
      "sha256": "evidencia…"
    }
  ]
}
replyLa respuesta que vuelveQué se hizo, qué se encontró y qué sigue abierto.
messagesLos traspasos necesariosDelegaciones nuevas, explícitas y dirigidas a roles válidos.
notifyLa intervención humanaAlertas, decisiones y cierres que deben salir del flujo entre agentes.
statusEl cierre declaradoTerminado o fallido. Lo parcial no se disfraza de éxito.
retryableLa posibilidad de continuarEl sistema aclara si un fallo admite un nuevo intento.
artifactsLa evidencia localizableArchivos, tipo y huella cuando corresponde.

Tres harnesses (Claude Code, Codex, OpenClaw), el mismo contrato durable. Lo que el operador ve en la consola coincide con lo que el bus persiste.

09 · Casos de uso

Una empresa para cada tipo de delivery

La misma base puede operar como software factory, organización de producto, plataforma interna o red multi-cliente. La topología, los protocolos y la capacidad crecen por configuración.

01 · Software factory
Una empresa de producto completa, disponible como capacidad.

Dirección, squads de frontend y backend, arquitectura, QA y operaciones trabajan con protocolos comunes sin perder ownership. Los traspasos entre células se ven en el bus y dejan evidencia.

02 · Platform engineering

Una plataforma que atiende a muchos equipos

Automatización, incidentes, seguridad, infraestructura y soporte técnico con colas y escalados explícitos. La capacidad de IA se reparte por política y se mide por consumo.

03 · Operación multi-cliente

Una empresa, varios tenants

Agencias y proveedores gestionan equipos, cuentas y protocolos separados sin mezclar contexto ni capacidad. El aislamiento está reforzado a nivel de datos, no sólo por convención.

10 · Cómo empezar

Diseñá una empresa. Escalala sin rehacerla.

Cauce puede nacer con dos equipos o integrar una operación existente. La topología, los protocolos y la capacidad crecen por configuración — sin reescribir el bus.

2 equipos

Empresa inicial

Una unidad completa para validar el modelo con un producto o flujo real.

  • Producto + plataforma o calidad
  • Responsabilidades y protocolos
  • Cuentas y harnesses asignados
  • Entrega y fallos observables
Salida: una operación funcional con criterios para escalar.
Integrar

Control plane gestionado

Para organizaciones que ya tienen agentes, cuentas, herramientas o harnesses.

  • Inventario e integración
  • Adaptadores multi-harness
  • Tenants y suscripciones
  • Soporte definido por acuerdo
Salida: una empresa existente gobernada desde una capa común.

El primer paso es un brief de seis preguntas y una reunión de treinta minutos. No se instala nada hasta tener un prototipo con evidencia de efecto.

11 · En una frase

Una flota de agentes que recibe, ejecuta y responde con evidencia — sobre un cauce durable y propio.

Multi-tenant y multi-harness. Con identidad derivada, claims cercados, operación visible y control humano.

Bus durable event-driven Aislamiento por cliente Claims + ACK cercados Claude Code · Codex · OpenClaw Self-hosted

Cauce V3 · flota multi-agente · presentación

12 · Siguiente paso

Conectemos Cauce con tu operación real.

Hablá directamente con Steven, reservá una reunión de 30 minutos o revisá el catálogo completo de sistemas Humanizar.

Empezá con un brief útil

Las mismas seis preguntas prácticas que ya traía la versión anterior, ajustadas a Cauce V3. Sirven para llegar a la primera reunión con el caso delimitado y un orden de magnitud estimado. El brief se copia a tu portapapeles: no se envía a ningún servicio.

Agendar con ese brief listo

Humanizar · stevenvallejo.com · Praxis · Catálogo · Agenda · WhatsApp