TaskWeaver AI — MVP

Concepto

B2B SaaS que automatiza procesos operativos de PYMES (onboarding de clientes, facturación, RRHH) a partir de una descripción en lenguaje natural, en vez de flujos rígidos tipo Zapier/Make. El usuario describe el proceso, un motor de planificación lo traduce a un plan JSON estructurado, y un motor de ejecución lo corre contra los conectores B2B conectados (Stripe, Google Workspace, Slack, HubSpot, Asana).

Inspirado en Semble AI (YC): "agentes de IA personalizados para operaciones empresariales".

Arquitectura

Cliente HTTP
   │  JWT Bearer
   ▼
[Security: JwtAuthFilter] ──► SecurityContext (email como principal)
   │
   ▼
Controllers (auth / workflows / connectors / dashboard)
   │
   ▼
Services
 ├─ AuthService                 → registro/login, emite JWT
 ├─ WorkflowService             → CRUD workflows, delega a NaturalLanguagePlanner
 ├─ ConnectorConnectionService  → hub de conectores (conectar/desconectar, estado)
 └─ WorkflowExecutionEngine     → motor de ejecución de agentes
        │
        ├─ planner.RuleBasedWorkflowPlanner (NaturalLanguagePlanner)
        │    detecta conectores mencionados en el texto y genera el plan JSON.
        │    Punto de extensión: sustituir por un cliente real de OpenAI/
        │    Anthropic (Spring AI) implementando la misma interfaz.
        │
        └─ connector.ConnectorActionFactory (Strategy)
             ├─ StripeConnectorAction     → client.StripeApiClient (Feign)
             ├─ GoogleDriveConnectorAction→ client.GoogleDriveApiClient (Feign)
             ├─ SlackConnectorAction      → client.SlackApiClient (Feign)
             ├─ HubspotConnectorAction    → client.HubspotApiClient (Feign)
             └─ AsanaConnectorAction      → client.AsanaApiClient (Feign)

Persistencia (Spring Data JPA, H2 embebida por defecto / Postgres en prod):
 User ─< UserConnection (OAuth2 simulado, 1 por ConnectorType)
 User ─< Workflow (description + planJson) ─< WorkflowRun ─< WorkflowStepLog

Virtual Threads: %%INLINE0%% registra un %%INLINE1%% con %%INLINE2%% como bean %%INLINE3%%. %%INLINE4%% corre en él (%%INLINE5%%), así el hilo de la petición HTTP no se bloquea esperando las llamadas I/O-bound a las APIs de terceros: %%INLINE6%% responde %%INLINE7%% de inmediato con el run en estado RUNNING, y el motor sigue ejecutando en background.

Simulación de credenciales/LLM: no hay claves reales de OAuth2 ni de un LLM en este sandbox. ConnectorConnectionService.connect() genera tokens de sandbox; RuleBasedWorkflowPlanner sustituye al LLM con reglas deterministas. Los ConnectorAction intentan la llamada Feign real y, si falla (no hay red o credenciales reales), degradan a un resultado simulado exitoso — así el flujo completo es demostrable sin dependencias externas.

Endpoints

Todos bajo %%INLINE12%%. Excepto %%INLINE13%%, todos requieren header Authorization: Bearer <jwt>.

Método	Path	Descripción
POST	%%INLINE15%%	%%INLINE16%% → {token, email}
POST	%%INLINE18%%	%%INLINE19%% → {token, email}
POST	%%INLINE21%%	%%INLINE22%% → crea workflow + plan JSON generado
GET	/api/workflows	lista workflows del usuario
GET	/api/workflows/{id}	detalle de un workflow (incluye plan)
POST	%%INLINE25%%	dispara ejecución async → %%INLINE26%% + run RUNNING
GET	/api/connectors	estado de los 5 conectores (conectado/no)
POST	%%INLINE29%%	simula el intercambio OAuth2 (%%INLINE30%% = %%INLINE31%%, %%INLINE32%%, %%INLINE33%%, %%INLINE34%%, ASANA)
DELETE	/api/connectors/{type}	desconecta un conector
GET	/api/dashboard/runs	historial de ejecuciones del usuario
GET	/api/dashboard/runs/{id}	detalle + logs paso a paso de una ejecución

Ejemplo de flujo completo

POST /api/auth/register            {"email":"ana@pyme.com","password":"secreto123"}
POST /api/connectors/STRIPE/connect
POST /api/connectors/HUBSPOT/connect
POST /api/connectors/GOOGLE_WORKSPACE/connect
POST /api/connectors/SLACK/connect
POST /api/workflows
  {"description":"Cuando se pague una factura en Stripe, encuentra al cliente
   en Hubspot, crea una carpeta con su nombre en Google Drive y envía una
   notificación a nuestro canal de Slack #clientes"}
POST /api/workflows/1/run          → 202 { "status": "RUNNING", ... }
GET  /api/dashboard/runs           → historial con estado SUCCESS/FAILED y logs

Referencias

• Business case: Semble AI (Y Combinator) — https://www.ycombinator.com/companies/semble-ai
• Spring Boot 4.0.4 / Spring Framework 7.x / Jackson 3 (tools.jackson.*)
• Spring Cloud OpenFeign 4.2.1 para los clientes declarativos del hub de conectores
• jjwt 0.12.6 para emisión/validación de JWT

Análisis de negocio

• Problema: equipos de operaciones en PYMES pierden horas en tareas

manuales cross-SaaS; las herramientas de automatización existentes exigen configuración técnica rígida.

• Solución: bajar la barrera de entrada usando lenguaje natural para

definir el flujo, en vez de un editor visual de nodos.

• Monetización: freemium por niveles — plan gratuito limita ejecuciones/mes

y conectores (2-3); planes pagos escalan por volumen de ejecuciones, número de conectores y funciones avanzadas (lógica condicional, aprobación humana). El modelo de datos ya soporta esto: WorkflowRun cuenta ejecuciones por usuario/mes, y UserConnection limita conectores activos por plan.

• Foso competitivo: la capa de planificación en lenguaje natural

(NaturalLanguagePlanner) es el punto de extensión hacia un LLM real; a medida que mejora el prompt/modelo, el producto se vuelve más flexible que Zapier/Make sin tocar el motor de ejecución.

Cómo ejecutar

cd solutions/2026-07-07-taskweaver-ai
mvn spring-boot:run

Por defecto, con %%INLINE43%% en el classpath y sin %%INLINE44%% configurado, Spring Boot levanta una base H2 embebida automáticamente (ideal para el MVP). Para producción, configurar spring.datasource.* apuntando a PostgreSQL — las entidades JPA ya son compatibles sin cambios.

mvn clean compile   # verifica que compila
mvn clean package   # genera el jar ejecutable

---

FinOps Analysis

Estimación de Costos Operativos

Para TaskWeaver AI, los costos operativos iniciales se han estimado de forma conservadora, asumiendo un despliegue mínimo viable pero robusto en la nube y un uso moderado de LLMs de alta calidad.

• Tokens LLM Mensuales: Se estima un consumo de aproximadamente 2 millones de tokens/mes. Esto considera la creación/actualización de flujos de trabajo por parte de 20 clientes activos (ej. 10 flujos/cliente/mes, con prompts complejos y respuestas JSON de hasta 1000 tokens por interacción), además de un búfer para pruebas internas, reintentos y posibles usos secundarios del LLM (ej. explicaciones de errores, sugerencias).
• Desglose de Costos Mensuales:

* LLM (OpenAI gpt-4o): $20/mes (asumiendo 1M input @ $5/M + 1M output @ $15/M). * Cloud Hosting (AWS EC2 t3.small + ALB): $35/mes (instancia de cómputo para Spring Boot y balanceador de carga para alta disponibilidad/escalabilidad futura). * Base de Datos (AWS RDS db.t3.micro PostgreSQL): $15/mes (instancia administrada con 20GB de almacenamiento). * Monitoring & Logs: $10/mes (para servicios básicos de monitoreo y almacenamiento de logs en la nube). * Total Estimado: $80/mes.

Estimación de Ingresos y Margen de Beneficio

Basado en el modelo de monetización B2B SaaS freemium por niveles, se proyecta un escenario inicial con 20 clientes de pago en el plan más básico.

• Ingreso Mensual Estimado: $500/mes (20 clientes x $25/mes por el plan básico).

Margen de Beneficio: ((500 - 80) / 500) 100 = 84%.

El alto margen de beneficio inicial refleja la eficiencia de una arquitectura lean para un MVP y el valor de la automatización que ofrece el producto. Los costos de LLM, aunque cruciales, son una fracción menor de los costos operativos totales en comparación con la infraestructura cloud básica.

Optimizaciones FinOps Clave

Para mantener este margen y escalar de manera rentable, se recomiendan las siguientes optimizaciones:

1. Estrategia de Modelos LLM Gradual: Utilizar %%INLINE46%% solo cuando la complejidad del prompt lo justifique. Para tareas menos críticas o usuarios en planes freemium, optar por modelos más económicos como %%INLINE47%% o gpt-3.5-turbo puede reducir significativamente los costos de LLM.
2. Caching de Respuestas LLM: Implementar una capa de caché para las respuestas del LLM. Si un usuario (o diferentes usuarios) solicita la automatización de un flujo de trabajo con una descripción muy similar o idéntica, se puede servir la respuesta JSON previamente generada, evitando llamadas redundantes a la API del LLM.
3. Optimización de Prompts: Refinar continuamente los prompts enviados al LLM para que sean concisos y eficientes, minimizando el número de tokens requeridos para obtener una respuesta precisa. Esto también reduce la probabilidad de reintentos costosos.
4. Ajuste Continuo de Infraestructura: Monitorizar de cerca el uso de EC2 y RDS. A medida que el tráfico crece, escalar vertical u horizontalmente según sea necesario, pero siempre comenzando con las instancias más pequeñas y ajustando proactivamente para evitar el sobreaprovisionamiento.
5. Adopción de Serverless para Escala: Para el motor de ejecución de flujos de trabajo, considerar migrar a una arquitectura serverless (ej. AWS Lambda invocada por un SQS para cada ejecución). Esto transformaría un costo fijo de cómputo en un costo variable, pagando solo por el tiempo de ejecución real del flujo, lo cual es ideal para cargas de trabajo intermitentes.