El despliegue de Paul Surkau comenzó con un brief amplio y una limitación importante: el contexto completo del negocio aún no estaba disponible. RECAST construyó la estructura departamental capaz de recibirlo de forma segura, manteniendo la afirmación pública al nivel que permite la evidencia.
Evidencia en la fecha de publicación: el 30 de mayo de 2026 se observaron 12 agentes y 33 conexiones, junto a un espacio alemán mapeado en Discord, páginas gbrain, helpers de Notion y herramientas documentales locales. El registro verifica el entorno construido, no adopción sostenida ni resultado comercial.
La empresa
El brief describe un espacio alemán que abarca gestión diaria, agenda, automatización, contenido, email, creatividad, investigación, búsqueda web, asesoría, copy de ads, prompts, habilidades, Notion y documentos. Más tarde se amplió a adquisición, ventas de comunidad y administración.
Como la fuente no conserva una descripción más completa del modelo de negocio, esta página no inventa una. El caso trata de la arquitectura entregada y la evidencia de adopción aún pendiente.
La restricción
Sin routing, cada categoría sería otro chat, herramienta o proceso manual. Paul seguiría decidiendo dónde correspondía cada solicitud, reexplicando el contexto y moviendo el resultado al siguiente canal.
Al mismo tiempo, un contexto incompleto impedía describirlo responsablemente como fuerza autónoma plenamente formada. El primer paso correcto era crear áreas claras, comportamiento visible y ejecución segura que pudieran profundizarse al llegar material operativo.
Por qué las herramientas existentes no bastaban
Los canales de Discord y páginas de Notion organizan trabajo, pero no lo enrutan. Un asistente genérico podía responder donde no correspondía, desaparecer tras una sesión fallida, consultar Notion de forma irregular o intentar usar shell cuando hacía falta un helper determinista.
RECAST reforzó respuestas visibles, allowlists, limpieza de sesiones, estabilidad del routing, memoria acotada y wrappers limitados. El valor no es simplemente “12 bots”; es una superficie donde cada función tiene dirección y acciones permitidas.
Mapa de transformación
Antes
Solicitudes de gestión, contenido, investigación y adquisición -> Paul elige chat y aporta contexto -> handoff manual
Después: arquitectura construida
Canal alemán -> agente departamental -> memoria o helper limitado -> respuesta visible -> revisión y evidencia de adopción
Un flujo de principio a fin
La ruta refleja la arquitectura configurada; no se afirma uso rutinario.
- Entrada: Paul publica una petición en un canal mapeado de gestión, contenido, investigación, adquisición o administración.
- Routing: La conexión la envía al especialista correspondiente.
- Contexto: El agente consulta sus instrucciones y el contexto disponible en gbrain.
- Herramienta: Notion o documentos usan helpers limitados; creatividad e investigación, rutas permitidas propias.
- Producción: El especialista prepara análisis, borrador, documento o siguiente acción.
- Visibilidad: La respuesta vuelve al canal designado, haciendo observables los fallos silenciosos.
- Aprobación: Paul aporta contexto faltante y aprueba acciones externas mientras cada área prueba su adopción.
Qué cambió
- Construido: Doce funciones para operaciones, contenido, creatividad, competencia, estrategia, ads, prompts, habilidades, adquisición, comunidad y administración.
- Conectado: Routing de Discord, páginas gbrain, helper de Notion y wrappers documentales locales.
- Probado: Respuestas visibles, routing, resets de sesión, memoria activa acotada y estabilidad de modelos.
- Runtime verificado: Doce agentes y 33 conexiones visibles el 30 de mayo de 2026.
- Uso activo: No se conserva actividad sostenida; no se presenta como adopción a escala.
- Dependencia restante del proveedor o cliente: El contexto completo, credenciales y activación de WhatsApp o Telegram preparados siguen pendientes.
- Resultado financiero comunicado por el cliente: Ninguno registrado.
Evidencias
- Prueba de agentes: Doce funciones departamentales identificadas.
- Prueba de routing: 33 conexiones.
- Prueba del espacio: Canales alemanes para gestión, clientes, contenido, investigación, automatización, logs, social, creatividad, asesoría, ads, prompts y habilidades.
- Prueba de control: Reglas del propietario del comando y allowlists.
- Límite: Contexto inicial incompleto y sin ledger de adopción o resultados.
Tecnología, al final
El despliegue usa OpenClaw 2026.5.7, Discord, trabajo de routing con proxy/OpenRouter, Ollama, gbrain, helper de Notion, PDF/OCR, Higgsfield, Printing Press, Apify y Kie.ai. WhatsApp y Telegram se prepararon, no se presentan como activos. La ejecución usa allowlist y prefiere wrappers a shell amplio.
Testimonio del cliente
No existe una cita textual verificable. RECAST separa un registro de entrega de un testimonio y no escribe el segundo en nombre del cliente.
Siguiente transformación
Descubre cómo el espacio de Kevin Hucker separa seis áreas de crecimiento alrededor de contexto común. La comparación reúne dos despliegues multiagente ya construidos que aún necesitan mejor evidencia de adopción: uno con seis funciones de crecimiento enfocadas y otro con una estructura más amplia de doce funciones.
Obtén tu plan de IA
Si el brief es amplio pero el contexto aún se reúne, lo honesto es demostrar un departamento cada vez. Reserva una auditoría gratuita de IA para elegir esa primera área y definir su evidencia.
Registro de fuentes
OPENCLAW-DEEP-CLIENT-CASE-STUDIES.pdf, página 7.RECAST_CASE_STUDIES_2026_UPDATED.pdf, página 14, documentoRA-CASES-001, versión 2.0.RECAST_WEBSITE_MASTER_BLUEPRINT.md, apartados 10.4, 11 y 58.