Lo que se construye con Thaliq.
Patrones reales,
no demos.
Cuatro patrones agénticos en producción. Cada uno incluye el spec, las tools, los guardrails y los gotchas que ya resolvimos para que tu equipo no los descubra en producción.
Resuelve tier-1 sin humanos.
Escala a humano
cuando importa.
Agente que cierra el 70% de los tickets sin tocar a un humano y escala el resto con contexto completo. Nada de regex de "contiene la palabra refund" — el HITL es declarativo en el spec del agente y se intercepta a nivel backend antes de ejecutar la tool.
El agente vive en tu Zendesk vía MCP gateway. Tokens del usuario final pasan por passthrough — Thaliq nunca los almacena. Cuando detecta frustración, una solicitud de reembolso superior a un umbral, o un caso fuera de su scope declarado, dispara una acción HITL: <code>confirm</code>, <code>select</code> o <code>form</code>, según el caso.
El thread completo (mensajes, tools ejecutadas, decisiones HITL) queda persistido en DynamoDB con TTL configurable por plan (7d / 30d / 90d). Cuando el asesor humano lo retoma, ve toda la historia con el reasoning del modelo. Sin context loss.
- Modelo
- claude-haiku-4-5
- MCP servers
- Zendesk · Stripe (refunds)
- HITL
- confirm_on_refund > $200
- Audit retention
- 90d en plan Enterprise
"Antes el bot manejaba FAQs y todo lo demás caía en cola humana. Con HITL declarativo el agente toma decisiones y solo nos llega lo que de verdad necesita criterio humano."
Copilot para tu equipo.
Conectado a tu stack
vía MCP.
Tu equipo de finanzas, ops o legal pregunta en lenguaje natural. El agente consulta tu ERP, tu data warehouse y tus políticas internas vía MCP — con permisos por rol y audit log de cada acción. La data nunca sale de tu VPC.
MCP gateway hacia tus servicios internos. Cada request del usuario se valida contra el rol del miembro (OWNER, ADMIN, SUPERVISOR, AGENT, EDITOR, VIEWER) antes de invocar la tool. Si el agente pide datos que el usuario no tiene autorizados, la tool falla con <code>403</code> — no hay leak por error.
RAG sobre tus políticas internas (Voyage embeddings + pgvector). Cuando el agente cita una política, devuelve el chunk exacto con score de relevancia. Cero alucinación de "creo que la política dice...". Las consultas + tool calls + chunks RAG quedan en LangFuse para post-mortems.
- Modelo
- claude-sonnet-4 · Opus en Enterprise
- MCP servers
- ERP · Snowflake · Linear · Notion
- RBAC
- 6 roles · enforced backend
- RAG
- pgvector · Voyage embeddings
"Antes finanzas armaba reportes a mano cada cierre de mes. Ahora preguntan al copilot, este consulta el ERP vía MCP con sus permisos, y el audit log nos cubre la auditoría externa."
Incrusta agentes
en tu producto.
Multi-tenant nativo.
Tu SaaS es multi-tenant. Cada uno de tus clientes ve solo sus datos. El SDK de Thaliq propaga el <code>X-Tenant-ID</code> del usuario final, y el agente queda scoped al tenant correcto sin que tu backend tenga que rutear nada.
Headless por diseño: <code>@thaliq/sdk</code> en TypeScript hoy, Python y Go en roadmap. Cero UI impuesta — usas tus propios componentes. Streaming SSE tipado con eventos reanudables tras HITL e idempotencia por request.
Tus tokens de cliente nunca tocan el backend de Thaliq — pasan por passthrough hacia los MCP servers que ese tenant tiene autorizados. Bill por tenant via API: cada request queda taggeada con el <code>tenantId</code> y aparece en la UI de Platform de tu cliente para que vea su consumo.
- Integración
- @thaliq/sdk · headless
- Multi-tenant
- X-Tenant-ID · isolation físico
- Streaming
- SSE tipado · reanudable
- Billing
- Per-tenant via DynamoDB ledger
"Evaluamos LangChain pero íbamos a tener que construir toda la capa multi-tenant, RBAC y audit log encima. Con Thaliq cada cliente nuestro tiene su propio tenant aislado desde el día uno."
El agente como orquestador.
Pausa en HITL,
reanuda sin context loss.
El agente lee correos, ejecuta acciones en N sistemas vía MCP tools, y se pausa en pasos críticos esperando aprobación humana. Cuando el humano responde, el agente reanuda exactamente donde estaba — el turn snapshot persistido en DynamoDB garantiza zero context loss.
Patrón de orquestación: <code>read_email → extract_intent → check_policy (RAG) → execute_action (MCP) → notify_slack</code>. En cualquier paso podés meter un HITL declarativo (<code>confirm</code>, <code>form</code>, <code>select</code>) que pausa el flow y emite un evento al humano correcto vía Slack/email/widget.
Cuando el humano responde, el frontend manda <code>actionResponse</code> al endpoint de stream. El handler levanta el turn snapshot, hidrata el contexto del modelo (history + tools + RAG chunks anteriores) y reanuda la ejecución desde donde se pausó. Sin retry, sin re-prompt, sin que el modelo "olvide" lo que ya decidió.
- Modelo
- claude-sonnet-4 · Opus para legal
- Persistencia
- TurnSnapshot · DynamoDB
- HITL types
- consent · confirm · select · form
- Resume
- Sin retry · sin context loss
"Probamos n8n y Zapier con LLMs encima — funcionaba hasta que un humano tardaba 4h en aprobar y se perdía el contexto. Con Thaliq el agente reanuda exactamente donde se quedó, incluso 48h después."
vendor=Acme · amount=$12,400confirm · CFO · slack#financeturn_snapshot.hydrate() Tu caso, en producción.
Hablemos.
Si tu patrón no está en la lista, probablemente lo construimos juntos. Free tier para empezar a experimentar, Enterprise cuando necesites SLA, white label o deploy dedicado.
Empezar gratis