Framework de orquestación agéntica

Construye productos con IA que actúan, no solo conversan.

Flow convierte tu API en agentes que consultan, deciden y ejecutan sobre tus sistemas reales. Usan la credencial correcta en cada turno, funcionan en web, voz, WhatsApp o Telegram y tienen garantías que no dependen de que el modelo se porte bien.

Agenda una sesión técnica Ver cómo se integra

Integrado en casos reales: restaurantes · agro · e-commerce · operaciones

Flow 1 turno

Web · voz

Agente Personalidad, herramientas, modelo y conocimiento

tools/list

Herramientas MCP Generadas desde tu OpenAPI

JWT · ES256

Tu API Valida el token contra nuestro JWKS

Un turno, del canal a tu API: el agente descubre sus herramientas y cada llamada viaja con un token firmado.

01 — El problema

Un demo de IA se arma en una tarde. Un producto, no.

El chat funciona en la demo. Después aparecen las preguntas que deciden si llega a producción:

¿Con qué permisos actúa el agente cuando llama a tu API?
¿Qué pasa cuando el token de tu proveedor vence a la hora?
¿Cómo evitas que el modelo revele un dato, o que diga que hizo algo que nunca ejecutó?
¿Cómo lo llevas a WhatsApp, a tu web o a una mesa con voz sin reescribirlo todo?

Flow resuelve esa capa una sola vez, para todos tus agentes.

02 — Cómo funciona

Defines agentes como datos. La plataforma pone el resto.

Agentes declarativos

Cada agente se define con personalidad, herramientas permitidas, modelo y conocimiento. Un agente para una vertical nueva es configuración, no un release. Los equipos de agentes completos se exportan e importan como un bundle JSON.

Conectores desde tu OpenAPI

Apuntas a tu especificación y cada endpoint se vuelve una herramienta MCP con su schema. La autenticación puede ser API key, bearer, OAuth2 client credentials con renovación automática, o cabeceras que tu backend firma en cada turno.

Canales

Widget embebible de texto o voz con un solo snippet, WhatsApp y Telegram. El mismo agente atiende todos los canales, con una conversación por usuario y sin código por canal.

Identidad y permisos

Proveedor de identidad propio, con tokens firmados (ES256) que tu backend valida contra nuestro JWKS. Incluye audiencia por cliente, catálogo de scopes y pantalla de consentimiento. Los secretos nunca pasan por el navegador.

Orquestación multi-agente

Un agente manager delega en especialistas, cada uno con sus herramientas y su modelo. Cada ejecución remota queda trazada de punta a punta.

Conocimiento

Bases de conocimiento por cuenta en formato abierto (markdown con frontmatter, validado al importar). El agente las consulta solo si tiene permiso explícito.

Cualquier modelo, con tu key

Eliges proveedor y modelo por agente: Gemini o cualquier API compatible con OpenAI (OpenRouter, OpenAI, Groq, Together). BYOK por cuenta.

03 — Casos de uso

Lo construimos integrando sistemas reales. Así se aplica.

Restaurantes

Un cajero por voz en cada mesa

El comensal escanea el QR y le habla al agente desde su celular.

El backend del restaurante firma un token de sesión (JWT) por comida: sub es la sesión y ctx es el contexto de la mesa.
Flow sella ese contexto y lo reenvía como cabecera en cada llamada del agente a la API del menú. El navegador no puede alterarlo.
La voz se procesa en el borde: transcripción y síntesis ocurren en el gateway, así que el agente sigue trabajando en texto. El botón flotante está pensado para smartphones.
El agente consulta el menú, filtra por etiquetas, arma el pedido y lo envía con clave de idempotencia.

También aplica a: room service, retail en tienda, kioscos, turnos.

Agro

Agentes de campo sobre una plataforma que ya existe

Equipos de agentes (jefe de campo, scout) que consultan campos, lotes y monitoreos dentro de la plataforma del cliente.

El backend del cliente valida los tokens de Flow contra nuestro JWKS y lee tenant_id y scopes de los claims. Es un estándar, no una integración a medida.
El conector pide y renueva solo su token OAuth2, así que los tokens que vencen cada hora dejan de ser un problema.
Cada agente ve solo sus herramientas: allowlist por personalidad, por ejemplo 6 de 15 endpoints.
El equipo completo se exporta como bundle y se replica en otra cuenta.

También aplica a: cualquier SaaS vertical que quiera sumar agentes sin rehacer su autorización.

E-commerce

Postventa sobre Tiendanube

Conector REST sobre la API de la tienda.
La verificación del comprador es una primitiva de la plataforma. request_verification genera el código y lo manda por email sin pasar por el modelo, y verify_code solo devuelve sí o no. El agente no puede filtrar un código que nunca vio.
Los identificadores que limitan el acceso vienen del runtime, nunca de los argumentos que escribe el modelo.

También aplica a: seguimiento de pedidos, cambios, cualquier flujo donde el agente necesita saber con quién habla.

Operaciones

Un manager que coordina especialistas

El agente orquestador recibe la tarea y la delega en workers especializados.
Caso real: el proveedor de email rechazó el remitente (403). El worker leyó el error, lo corrigió y completó el envío. El manager recibió la respuesta junto con el id de la ejecución remota y el pod que la corrió.

También aplica a: back-office, reportes, coordinación entre sistemas.

Atención por mensajería

WhatsApp y Telegram

Traes tu propio número o bot, y cada binding conecta un canal con un agente.
Una cola inbox/outbox en Postgres registra y despacha cada mensaje, y reencola lo que falla.

04 — Integración

Tu cliente se adapta a un estándar, no a un proyecto.

Recomendado

Estándar Flow

Tu backend valida nuestros tokens con JWT y JWKS. Es un solo modelo de identidad para todos tus agentes.
Credenciales de turno

Si ya tienes tu propia autorización, la declaras como datos (qué cabeceras viajan) y tu backend las firma en el token de sesión.
Credencial estática

API key o bearer, para el caso simple.

Si integrar un sistema nuevo exige tocar el código del framework, lo que se corrige es el modelo, no se agrega una excepción.

De tu API a un agente en producción

Sube el OpenAPI de tu sistema y tus endpoints se vuelven herramientas.
Define el agente: personalidad, herramientas permitidas, modelo y conocimiento.
Elige el canal: snippet web, número de WhatsApp o bot de Telegram.
Tu backend firma el token de sesión, y el agente queda funcionando.

05 — Bajo el capó

Hecho para que lo opere un equipo de ingeniería.

Kubernetes-native

Agentes y servidores MCP son recursos declarativos que un controlador reconcilia. El despliegue es GitOps.

Aislamiento por cuenta

Cada cliente tiene su propio namespace, con sus agentes, conectores, conocimiento y secretos.

Default-deny

Un agente sin configuración no tiene ninguna herramienta.

Credenciales de turno selladas

Se cifran en base de datos, se borran al cerrar el turno y nunca aparecen en logs.

MCP como estándar

Las herramientas se descubren en tiempo de ejecución con tools/list.

Contract-first

Cada servicio publica su contrato OpenAPI.

Observable

Cada ejecución tiene su id, cada herramienta su tarea, y la voz registra la latencia de cada etapa.

06 — Principios

Lo que aprendimos integrando, convertido en framework.

Un prompt pide; una primitiva garantiza.
Lo que tiene que cumplirse está en el código.
El agente nunca elige con qué permisos actúa.
El contexto llega firmado por tu backend.
Cero código por cliente.
Tu dominio vive en datos, no en el framework.
El agente piensa en texto; los canales son bordes.
Sumar voz no cambió la identidad, el consentimiento ni los límites.

Trae tu API y un caso de uso.

Te mostramos un agente actuando sobre tu sistema, con tus credenciales y en tu canal.

Agenda una sesión técnica