Panel calcado al comité real: arquitectos de startups AI, cultura framework-first (LangChain/LangGraph como vara), que cuestionan toda manera nueva de innovar y priorizan resiliencia y escalabilidad. Cada intercambio termina con un veredicto honesto: lo que se gana, lo que se defiende como tradeoff de etapa, y lo que se admite y va al roadmap.
"Construyeron un orquestador de agentes propio en 2026. LangGraph ya trae grafos de estado, checkpoints, human-in-the-loop y streaming, con miles de equipos en producción. Convénceme de que esto no es síndrome NIH."
El substrato no compite con LangGraph: son primitivas más aburridas. Postgres tipado + un executor durable (Inngest) + un catálogo cerrado de 17 operaciones. Lo que ningún framework trae puesto es el producto: cada decisión humana convertida en memoria tipada consultable con SQL (claims), y gobernanza estructural — el servidor valida cada plan en 4 capas y fuerza el punto de aprobación humana: el modelo no tiene camino para saltárselo, ni siquiera en los planes que compone Nova. Esa capa la tendríamos que escribir igual encima de cualquier framework.
Y la dependencia resultante es más estable: SQL y un executor, contra un framework que rompió APIs mayores entre versiones. Si mañana una operación necesita LangGraph adentro, cabe dentro de una operation del catálogo. La inversa no es cierta.
"Ok, pero el bus factor. Contrato un senior y conoce LangChain; tu substrato no lo conoce nadie. Comunidad cero, Stack Overflow cero. ¿Cuánto cuesta onboardear a alguien acá?"
El costo existe y lo asumimos. Mitigación verificable, no promesas: 782 tests (319 unit de la app + 237 E2E/visual + 226 del motor), un manual vivo de 31 pasos que un navegador real re-verifica contra producción antes de cada demo, y la historia técnica completa documentada capítulo a capítulo. Onboardear acá es leer Postgres y un executor de DAGs — tecnología que cualquier senior ya domina — no aprender las abstracciones propietarias de un framework.
Lo que no tenemos, y es justo decirlo: el "esto lo conoce todo el mercado".
"¿InsForge? ¿Quién? Pusieron la identidad de su producto en un BaaS que no conoce nadie."
El patrón es estándar aunque el vendor sea chico: JWT + refresh todo server-side (el browser jamás ve service keys), magic links de un solo uso con consumo atómico, gate de acceso fail-closed. El riesgo es del vendor, no del patrón — y la superficie que usamos es deliberadamente conmutable: un perfil JSONB y dos tablas; migrar a Supabase o Auth0 no toca el modelo de dominio. PII mínima: email y nombre.
Lo elegimos por velocidad de etapa, aislado detrás de una capa server-side propia. Si el vendor preocupa al comité, el plan de swap está articulado.
"Una caja Hetzner. Una. Sin réplica de Postgres, sin multi-AZ, nginx único. Si esa caja muere un viernes a la noche: ¿qué pasa con los trabajos en vuelo y cuándo vuelve el servicio?"
Respuesta por dominios de falla, con honestidad. Contra el dominio frecuente — crashes de proceso, deploys, reinicios, lo que pasa todas las semanas — los workflows son durables: un human-gate suspendido hasta 24h sobrevive reinicios del motor, verificado con test de restart a mitad de ejecución. Contra el dominio catastrófico — pérdida de la caja — hay backup nightly de Postgres (RPO de hasta 24h) y la recuperación es restaurar + redesplegar systemd.
Lo que NO hay, dicho sin vueltas: alta disponibilidad, RTO formalizado, ni drill de restore documentado. A esta etapa — beta privada con gate de founder — es un tradeoff de costo deliberado. El compromiso: RTO/RPO formales y drill calendarizado antes de abrir el acceso.
"Tu 'durabilidad' de Inngest vive en la MISMA caja. Es durabilidad contra ustedes mismos, no contra el mundo."
Correcto — y está dicho así en nuestra propia acta. La durabilidad protege del dominio de falla frecuente (proceso, deploy, restart); el backup protege del catastrófico (caja), con su ventana RPO. No vendemos multi-región: vendemos que el pedido del cliente no se pierde por un deploy — que es el incidente que de verdad ocurre cada semana, no el meteorito.
"¿Quién se entera si el motor se cae a las 3am? ¿SLOs? ¿On-call?"
Observabilidad de ejecución sí: Langfuse v3 con traza y costo por paso, health endpoint con checks de DB y observabilidad, monitoreo del VPS. Alerting proactivo formal y SLOs: no hay todavía. Compromiso: alerta automática sobre el health endpoint y la cola de ejecución antes de abrir la beta.
"Todos los usuarios de la beta comparten UN workspace. Eso no es multi-tenancy — es una demo con login. ¿Cuál es el camino real a 100 clientes?"
Es la crítica más justa de la sala, y es exactamente la razón por la que la beta es cerrada con autorización manual de founder. Lo que ya está: el modelo de datos es multi-tenant desde el día uno — workspace_id en cada tabla de datos del motor (intents, traces, artifacts, claims, chat, manifests, superskills; los plans lo heredan vía su intent), validado como UUID hasta en el filesystem del briefing. Lo que falta: routing y auth por tenant, tokens por tenant y presupuestos LLM por tenant.
Y la propiedad que importa para el camino a 100: agregar clientes no enciende infraestructura nueva — un agente es una ficha en el catálogo, no un proceso; el tenant cien corre sobre el mismo motor que el uno. Es el ítem #1 del roadmap técnico.
"El LLM corre sobre una sesión de suscripción Max con un CLI headless. Eso es un hack de costo: sin SLA, throughput serializado, y términos de un plan personal sirviendo un producto multi-usuario. ¿Y si Anthropic les corta la cuenta mañana?"
Separemos arquitectura de etapa. La arquitectura es un adapter propio con dos backends: el CLI (sesión Max, costo marginal $0) y la API oficial — el fallback ya existe en el código, no es un plan en un slide. Y como cada paso registra su costo notional en dólares ($0.013–0.022 por digest), conocemos HOY la economía unitaria del switch: prender la API es configuración con margen ya contabilizado, no re-arquitectura.
El throughput: cierto, la sesión serializa — lo medimos en producción (un compose largo compitiendo con el chat) y la respuesta de escala es la misma: API con presupuestos por tenant. El riesgo de continuidad de la cuenta es real y está asumido conscientemente para la beta, con el switch listo como mitigación.
"Un solo bearer token para toda la superficie del motor. ¿En serio?"
Para el tráfico que existe hoy — exclusivamente server-to-server, la app en Vercel hacia el motor; el browser jamás lo ve — con superficie mínima en nginx (health, workspaces, approvals, intents; el endpoint de Inngest no es público), comparación timing-safe y rotación simple. Tokens por tenant llegan con el mismo ítem de roadmap que la pregunta 07: multi-tenancy.
"¿Dónde están los evals? ¿Cómo saben que el digest de hoy no es peor que el de hace un mes? '8 Evaluators' suena a marketing."
Tres capas hoy, y un faltante honesto. Una: los 8 evaluators son verdicts en runtime por paso del plan — gates de ejecución, no benchmarks. Dos: el manual vivo — 31 pasos E2E que un navegador re-corre contra producción antes de cada demo; la semana que lo ampliamos cazó un bug real de streaming que ningún test unitario veía. Tres, la más valiosa: el human gate hace que cada entregable lleve etiqueta humana — aprobado o rechazado, con comentario — y eso ya acumuló 100+ claims tipados. Eso ES un dataset de evaluación etiquetado, creciendo solo, como subproducto del producto.
El faltante: regresión offline sistemática (LLM-judge sobre ese dataset, corrida en CI). Va al roadmap con nombre y apellido.
"Lock-in total con Anthropic: prompts afinados a Claude, CLI de Claude, todo Claude."
Lock-in de modelo lo tiene todo el mundo — también con LangChain: cambiar de proveedor siempre re-tunea prompts. Lo que importa es el radio de impacto: acá los prompts viven en 17 operaciones tipadas del catálogo, cada una con costo y verdict por paso, así que un swap se mide operación por operación contra el dataset etiquetado del human gate. No es costo cero; es costo acotado y medible.
"¿pgvector? Los equipos serios usan una vector DB dedicada."
A esta escala es exactamente al revés. Los embeddings (3072d, DiskANN) son una columna al lado de los hechos tipados: un JOIN entre similitud semántica y claims estructurados en una sola query, sin dual-write ni sincronización con un índice externo. Una vector DB dedicada resuelve un problema de volumen que no tenemos, y agrega el problema que sí tendríamos: consistencia entre dos stores. Re-evaluamos con millones de vectores; hoy sería complejidad sin retorno.
"La base de esto SON marcas grandes: Postgres, nginx, Vercel, Cloudflare, Anthropic, Inngest. Lo custom es una capa fina, tipada y con 782 tests. No innovamos en infraestructura — innovamos en qué pasa con las decisiones humanas: se vuelven memoria estructurada del equipo. Esa capa no viene en ningún framework."
1. Ensayá los 4 rojos primero (04, 06, 07, 10). Son los que definen tu credibilidad: la sala perdona carencias admitidas con compromiso, no perdona humo. Los verdes salen solos.
2. La regla de los absolutos: nunca discutas contra "¿y si se cae todo?" en abstracto — respondé siempre con dominios de falla (frecuente vs catastrófico) y etapa (beta cerrada vs producto abierto). Es el patrón de las respuestas 04 y 05.
3. Nombrá lo incómodo antes que ellos: la sesión Max (08) y el workspace único (07) van a salir sí o sí. Quien los pone primero sobre la mesa, controla el encuadre.
4. Tené el manual abierto en otra pestaña: tres de las defensas (02, 10) terminan en "esto se puede ver en vivo" — mostrarlo vale más que decirlo.