Como o Tendy transformou LLMs em um Business OS com memória, RAG e integrações

O Tendy nasceu de uma tese simples: empresas não deveriam depender apenas de chatbots genéricos para usar inteligência artificial. O valor real de um LLM aparece quando ele entende o contexto da companhia, acessa dados internos, executa ações em sistemas de negócio, mantém memória de longo prazo e pode ser distribuído por app, API e canais parceiros. O desafio era transformar essa visão em um AI Business OS operável.

A arquitetura foi desenhada como uma plataforma multi-tenant com aplicativo autenticado, API gateway em Cloudflare Workers, histórico persistente de conversas, projetos compartilhados, upload de documentos, RAG, integrações, billing e controle de modelos. Em vez de acoplar tudo em uma tela de chat, a lógica de LLM foi tratada como uma camada de infraestrutura: roteamento, contexto, ferramentas, cobrança e distribuição precisam funcionar juntos.

Gateway LLM com aliases e roteamento

No núcleo do produto, estruturei um gateway compatível com o padrão de chat completions. A plataforma expõe aliases públicos de modelo, como assistentes rápidos ou mais analíticos, enquanto mantém os IDs reais de provedores protegidos. Isso permite trocar rotas internas sem quebrar a experiência do cliente ou a API pública.

Também implementei uma lógica de classificação e roteamento para que um modelo automático possa delegar a resposta para o alias mais adequado. Essa separação entre alias público, modelo provedor e comportamento do assistente tornou o produto mais flexível: o usuário escolhe a intenção, não precisa entender a complexidade da infraestrutura por trás.

RAG, memória e contexto proprietário

A segunda camada foi contexto. O Tendy separa conhecimento por tenant e por perfil de RAG, usando ingestão de documentos, R2, filas e Vectorize para montar uma base de recuperação. O objetivo era permitir que cada empresa conectasse seus próprios documentos e dados, sem misturar contexto entre clientes.

Além do RAG, a plataforma inclui uma camada de memória com provedores como Mem0 e Zep. Essa memória foi pensada para guardar preferências, fatos persistentes e histórico útil de cada workspace. A diferença é importante: RAG recupera conhecimento documental; memória ajuda o LLM a lembrar o contexto operacional e as preferências recorrentes da empresa.

Tool calling e integrações de negócio

Um LLM corporativo não pode apenas responder. Ele precisa executar. Por isso, o Tendy integra centenas de sistemas por meio do Nango e transforma ações desses sistemas em ferramentas compatíveis com OpenAI tool calling. A plataforma normaliza o formato das tools, filtra ações executáveis e injeta descrições úteis para o modelo decidir quando usar cada ferramenta.

Esse desenho permite que o assistente trabalhe conectado a ferramentas de negócio, sem expor a complexidade técnica para o usuário. O resultado deixa de ser uma conversa isolada e passa a ser uma interface de operação: o LLM pode consultar, acionar e organizar fluxos em sistemas externos com governança por tenant.

Deploy dedicado, billing e distribuição

Também estruturei o caminho para modelos dedicados em GPU usando RunPod, com criação de deployments por tenant, aliases de modelos e simulação via Cloudflare Workers AI quando necessário. Essa camada prepara o produto para cenários em que a empresa quer mais controle sobre modelo, capacidade e infraestrutura.

A operação foi fechada com medição e cobrança: subscriptions no app, uso direto via API, metering por tokens, Stripe e distribuição por canais parceiros ou marketplaces. Isso transformou o Tendy em mais do que uma aplicação de IA. Ele passou a ser uma infraestrutura comercial de LLM: app para times, API para desenvolvedores, memória, RAG, integrações, deploy dedicado e billing no mesmo sistema.