en producción
Caso — Plataforma propia · Operación de agentes

Una sola plataforma para operar y medir los agentes de cada negocio

De armar cada agente a mano en consolas separadas a una plataforma propia: cada negocio tiene su agente de voz y texto en 8 canales, con bandeja unificada, traspaso a una persona, CRM y su consumo medido.

Cliente
Producto propio
Mi rol
Producto, arquitectura y build: frontend, API, motores de voz y despliegue
Periodo
2026 · en producción
Usuario
Los negocios que atendemos y nuestro equipo de operación
Equipo
ialabs
Stack
React 19 + Vite · Node + Express · Prisma + PostgreSQL · ElevenLabs Agents · Dograh (self-hosted) · n8n
8 canales
WhatsApp, SMS, Telegram, Instagram, Messenger, correo, web chat y voz
fuente: servicio de envío del repositorio
43 modelos
Esquema Prisma: cuentas, workspaces, agentes, bandeja, CRM, formularios y facturación
fuente: schema.prisma
196 endpoints
API en 31 módulos de rutas con control de acceso por rol
fuente: server/src/routes
2 motores
De voz: ElevenLabs o Dograh autoalojado, elegido por cada negocio
fuente: agent-runtime
EXP-08 ficha de experimento · v0.1
en producción
01 · hipótesis Si el agente de cada cliente vive en un workspace propio, con sus canales, sus conversaciones y su consumo en un solo lugar, operarlo y medir lo que resuelve deja de multiplicar el trabajo con cada cliente nuevo.
02 · método Un workspace por negocio con RBAC, agente de ElevenLabs o Dograh por workspace, habilidades en n8n por webhooks firmados y credenciales propias del cliente cifradas con AES-256-GCM.
03 · resultado En producción: multi-cliente, voz con ElevenLabs, habilidades en n8n, canales de mensajería, CRM, formularios y facturación por consumo con Bold.
04 · siguiente iteración Validar en producción el motor Dograh sin servicios gestionados y el estudio de voz.
en producción · responsable Mateo Piza · evidencia: repositorio privado de la plataforma
01 — El problema

Cada agente nuevo era un proyecto nuevo

Operar agentes de IA para varios negocios termina en un tablero de voz por aquí, un flujo de automatización por allá y un número de WhatsApp en otra consola. Cada cliente nuevo multiplica cuentas, credenciales y soporte.

Y así no hay forma de responder por el resultado: el negocio necesita un solo lugar para leer conversaciones, intervenir cuando el agente no puede y saber cuánto consume.

02 — El insight
"El agente no es el producto; el resultado sí. Si cada negocio es un workspace con su agente, sus canales, sus conversaciones y su consumo, saber qué resuelve es leer un tablero, y cambiar de motor de voz o sumar un canal es configuración, no un proyecto nuevo."
03 — Antes / después
Antes
  1. Un tablero distinto por proveedor de voz, automatización y mensajería.
  2. Credenciales de cada cliente repartidas en varias consolas.
  3. Conversaciones sin bandeja común ni traspaso a una persona.
  4. Consumo de cada cliente calculado a mano.
Después
  1. Una plataforma propia, con un workspace aislado por negocio.
  2. Credenciales propias del cliente cifradas con AES-256-GCM.
  3. Bandeja unificada con traspaso a una persona, CRM y formularios.
  4. Facturación por consumo con Bold.
04 — El sistema

Flujo de capacidades automatizadas

entrada
Mensaje o llamada
Llega por WhatsApp, SMS, Telegram, Instagram, Messenger, correo, web chat o voz.
contexto
Workspace del negocio
Agente, conocimiento, canales y permisos del negocio, aislados del resto.
decisión
Motor del agente
ElevenLabs o Dograh autoalojado según el workspace; las acciones van a habilidades de n8n.
acción
Habilidad ejecutada
Agendar una cita, registrar un lead o consultar disponibilidad por webhooks firmados.
control
Bandeja e intervención
El equipo ve la conversación, toma el control cuando hace falta y el consumo se factura.
DIAGRAMA DE ARQUITECTURA DE FLUJO ialabs / EXP-08
01 · Canal
8 canales
→
02 · Workspace
RBAC + aislamiento
→
03 · Motor de voz
ElevenLabs o Dograh
→
04 · Habilidades
n8n firmado
→
05 · Bandeja
Persona + facturación
05 — Decisiones · capa técnica

Cada pieza, con su razón

Arquitectura basada en trade-offs deliberados y consecuencias reales de negocio.
Tecnología Node + Prisma (PostgreSQL)
Función Núcleo multi-cliente
Decisión y trade-off Cuenta, workspace y agente en un solo esquema de 43 modelos, con control de acceso por rol en cada petición. Trade-off: una base compartida obliga a aislar cada consulta por workspace.
Consecuencia Un producto para muchos negocios
Tecnología Dograh autoalojado
Función Motor de voz alternativo
Decisión y trade-off Fork del proyecto abierto Dograh (BSD-2) con parches propios para operar sin sus servicios gestionados, con embeddings locales o del cliente. Trade-off: hay que seguir el proyecto original.
Consecuencia Voz sin depender de un solo proveedor
Tecnología n8n detrás de la marca
Función Habilidades del agente
Decisión y trade-off Las acciones del agente (agendar, registrar, consultar) son flujos de n8n por webhooks firmados que el cliente final nunca ve. Trade-off: una pieza más que operar.
Consecuencia Habilidades nuevas sin tocar el núcleo
Tecnología Proxy deny-by-default
Función Acceso del panel al motor de voz
Decisión y trade-off El frontend nunca habla directo con el motor: pasa por un proxy que solo deja las rutas permitidas y la organización del propio workspace. Trade-off: cada ruta nueva hay que habilitarla.
Consecuencia Un negocio no puede tocar el motor de otro
06 — Evidencia
TELEMETRÍA DE PROYECTO en producción
Una sola plataforma para operar y medir los agentes de cada negocio
De armar cada agente a mano en consolas separadas a una plataforma propia: cada negocio tiene su agente de voz y texto en 8 canales, con bandeja unificada, traspaso a una persona, CRM y su consumo medido.
CanalWorkspaceMotor de vozHabilidadesBandeja
Del mensaje del cliente final a la habilidad ejecutada y la bandeja del equipo. Abajo, cómo llega el panel al motor de voz.
$ /api/voice/* → proxy deny-by-default
[auth] sesión + rol del usuario (RBAC)
[policy] ruta en la lista permitida · el resto se deniega
[tenant] organización Dograh del propio workspace, no la de otro negocio
[forward] petición reenviada al motor de voz: OK
07 — Quién hizo qué
ialabs
Producto completo: frontend, API y esquema, integración de canales, motores de voz, habilidades en n8n, facturación y despliegue.
Equipo del cliente
Producto propio: no hay cliente externo.
Terceros
ElevenLabs, Dograh (BSD-2), n8n, Meta, Twilio, Bold y Resend.
08 — Qué es distinto

Lo habitual es entregar la consola de un proveedor de voz y que el cliente se las arregle. Aquí operamos los agentes desde una plataforma propia: cambiamos de motor por cliente, sumamos canales y medimos el consumo de cada negocio, sin que el cliente tenga que administrar nada.

09 — Lecciones y siguiente iteración
  • En una plataforma multi-cliente el aislamiento se diseña en cada capa: la sesión, la consulta y el proxy al motor.
  • Límite conocido: el motor Dograh sin servicios gestionados y el estudio de voz siguen en validación, y dos capas de guardrails todavía no actúan.
  • Siguiente paso: validar Dograh en producción y abrir a clientes el motor de texto alternativo.
From Idea to Infinity.

¿Tus clientes escriben por varios canales y nadie mide qué se resuelve?

En 48 horas te devolvemos un diagnóstico con el resultado que podemos prometer.