La AI es el núcleo, no un envoltorio

El pitch no es «usamos AI». La mitad del mundo usa AI. El pitch es que en cada lugar donde la AI aparece en nuestro stack, la AI es lo que hace que la función funcione, si se quita la AI, la función colapsa, no solo se degrada. Esa es una categoría diferente a la de un chatbot-on-top-of-product, y es difícil de copiar.

Donde la AI es el núcleo (no un facilitador)

Designer Studio

• 14 atomic tools de 5 AI providers externos (Anthropic, OpenAI, recraft, replicate, quiver) bajo un único orquestador.
• Claude Sonnet ejecuta el multi-step pipeline: analyze → extract → vectorize → recurse → compose.
• Multimodal: el agent VE los resultados intermedios y decide si recurrir más, recurrir a rutas alternativas o preguntar al user.
• Toma de decisiones a nivel de agent: «¿este trace es lo suficientemente limpio?» → recurse / edit_image fallback / human prompt.
• No es «la AI genera una imagen», la AI orquesta un pipeline de identidad de marca de 14 tools.

Market Research AI

• Claude Sonnet 4 con GPT-4o fallback.
• Uso de tools sobre una base de datos PostgreSQL live con 121 production tables y un event-stream de PostHog con más de 60 events.
• El agent genera SQL on the fly, lo ejecuta, valida los resultados, sintetiza rich answer blocks.
• Streaming SSE con rich response blocks renderizados por surface (web → full blocks; Telegram → TG-friendly vía un segundo parser-prompt).
• «Nunca fabriques números» se aplica en el system prompt.
• Esto no es chat-with-our-docs. Esto es un agent haciendo live data work en un real production schema.

Social Tracker

• pipeline de 3 tiers con conciencia de costos: 1. Claude Haiku, caption screen (cheap) 2. Claude Haiku-vision, thumbnail check (cheap-ish) 3. Claude Sonnet + Whisper, deep video and audio analysis (expensive, gated)
• Aproximadamente 10× de reducción de costos vs. ejecutar todo a través del heaviest tier.
• Sistema de product-context custom por app, el mismo pipeline se ejecuta de manera diferente para una fitness app vs. una dating app.

Builder API

• AsyncAnthropic, 5 analyzer endpoints.
• Lee los GitHub repos de los creators → extrae SDK events / funnel / push / referral hooks.
• Parallel-gather para análisis multi-repo.
• Esta es la layer que hace factible el cross-ecosystem porting, mismo repo, múltiples ecosystems.

Donde la AI es un facilitador (no el núcleo)

• Pro dashboard, content recommendations, AI-powered insights.
• Push management [planned], copy auto-generado para drip campaigns.
• @appss search [planned], semantic search.

Estas son AI applications útiles. No son a lo que nos referimos cuando decimos «AI moat».

El stack completo de AI

Provider	Models que usamos	Usado por
Anthropic Claude	Sonnet 4, Haiku, Haiku-vision	Designer Studio, Market Research AI, Social Tracker, Builder API
OpenAI	GPT-4o (fallback), gpt-image-1 (edit), Whisper	Market Research, Designer Studio, Social Tracker
recraft.ai	Vectorizer	Designer Studio
Replicate	rembg, [planned] SAM2	Designer Studio
quiver.ai	Text-to-vector	Designer Studio

Por qué esto es un moat

1. Compositional moat. Los providers individuales están disponibles para todos. Nuestra orquestación de todos ellos bajo un único Telegram-creator-flow no lo está. El costo de lograr que doce capabilities se coordinen en torno a un user-flow se paga en meses, no en semanas.

2. Data moat. Los Claude agents en Market Research leen nuestra production database de 121 tablas, acumulada durante más de 2 años. Un competidor con los mismos models y tools no tiene la data layer. Mismo SQL, diferentes respuestas.

3. Optimización de costos como engineering, no como configuration. El Social Tracker de 3 tiers, las heurísticas de recursion-stop en Designer Studio, el prompt-caching en sesiones de agent de larga duración, estos son detalles de engineering, no flag flips. La carrera por $/operation la ganan los teams que pulieron durante meses.

4. Fallback resilience. Claude → GPT-4o; recraft → Replicate. No dependemos del uptime de un solo provider.

Patrones de UX impulsados por AI que usamos

• Candidate model. La AI genera una candidate-version; el user hace clic en «Apply» para commit. Nunca «la AI cambia cosas en silencio».
• Multi-modal recursion. El agent observa el resultado de un tool-call y decide si profundizar.
• Style descriptor passing. Una tool devuelve un structured-string listo para la siguiente.
• Fallback ladder. Step 1 → Step 2 → Step 3 (preguntar al user). Nunca «la AI produjo algo diferente a lo solicitado en silencio».
• Single answer, per-surface renderer. La respuesta canónica es producida una vez por el heavy model. Cada UI surface (web, Telegram bot, futuros Discord / LINE) la vuelve a renderizar vía un cheap second parser-prompt (Gemini-Flash / Haiku) adaptado a las constraints de esa surface. Así es como la cross-ecosystem expansion se mantiene cheap, misma respuesta, nuevo renderer por surface.

Cifras y afirmaciones citables

• 6 AI / ML providers integrados.
• 14 atomic tools en Designer Studio, 10 max iterations en el agent loop.
• pipeline de 3 tiers en Social Tracker = ~10× de reducción de costos vs. heavy-model-everywhere ingenuo.
• 121 production tables + más de 60 event types consultables por Market Research AI.

Preguntas abiertas

• Gasto mensual total en AI.
• Costo por user (Pro / Free / pay-as-you-go).
• Fallback hit-rate (Claude → GPT-4o).
• Average prompt-caching hit-rate.

Leer a continuación

• Positioning, por qué ser un stack, no una tool, hace de esta orquestación el product.
• Business model, cómo Market Research AI como hero use-case moldea el pricing.
• Two-sided marketplace, por qué la misma agent infrastructure desbloquea un valor diferente en cada lado del loop.

Para el total spend, costo por user y roadmap de cost-optimisation, envía un email a mark@engagelabs.org.