Construindo uma plataforma de IA do zero: da arquitetura ao uso real

Fazia tempo que eu não acompanhava um produto inteiro tão de perto. Geralmente, mesmo participando de decisões amplas de engenharia, existe uma parte do sistema que ocupa mais o dia: uma API, uma funcionalidade, uma tela. A visão do que acontece antes e depois é construída junto com outras pessoas do time.

Construir a plataforma de IA na Cobli me colocou de novo em contato com esse caminho completo. Da infraestrutura ao frontend, passando pelo backend, cache, filas e processamento assíncrono. E, junto disso, a parte específica de IA: orquestração de agentes e workflows, integração de LLMs, base de conhecimento, embeddings, RAG e avaliações.

A lista é grande, mas o que tem sido mais interessante é acompanhar como essas partes se encontram. Uma decisão na recuperação de contexto chega à resposta que o cliente lê. O tempo de uma ferramenta aparece como espera na interface. O que a pessoa faz depois da resposta ajuda a entender se aquilo resolveu alguma coisa.

Voltar a cuidar do produto inteiro

Em um projeto assim, fica difícil encerrar o raciocínio na entrega de uma funcionalidade. Depois de colocar algo em produção, ainda preciso entender como está funcionando, quanto custa e como as pessoas estão usando.

Esse acompanhamento aproxima decisões que, no dia a dia, podem acabar em conversas separadas. A discussão sobre infraestrutura encontra a de experiência do usuário. A análise de uma resposta ruim pode levar ao contrato de uma ferramenta ou à forma como o contexto foi recuperado. Uma dúvida recorrente do cliente pode indicar que a interface precisa explicar melhor o que o agente consegue fazer.

Ter esse contexto por perto muda o jeito de avaliar uma implementação. Consigo olhar para uma escolha técnica considerando o que ela provoca no restante do produto. Também fica mais fácil perceber quando estou tentando resolver no código um problema que começa antes, na expectativa criada para quem vai usar.

Esse olhar costuma ser compartilhado com PMs, UI/UX e outras pessoas do time. Poder acompanhá-lo nesse nível de detalhe tem sido uma das partes mais gratificantes do trabalho.

As decisões de arquitetura chegam à experiência

Cache, filas e processamento assíncrono parecem assuntos distantes de uma conversa com um agente. Mas eles ajudam a definir quanto a pessoa espera, o que vê enquanto espera e se pode confiar na informação que recebeu.

Uma resposta em cache, por exemplo, exige pensar no contexto em que ela continua válida. Em uma aplicação com dados que mudam, economizar uma execução só faz sentido se a resposta ainda representar o que o usuário perguntou. Processar algo em segundo plano também pede uma decisão de interface: como a pessoa sabe que a tarefa começou e como encontra o resultado depois?

Na parte de IA, aumentar o contexto enviado ao modelo pode ajudar em uma pergunta e acrescentar ruído em outra. Uma etapa extra de verificação pode melhorar a resposta, mas também aumenta o tempo de execução e o custo. São escolhas que precisam ser avaliadas no fluxo em que vão existir.

Esses exemplos mostram por que me interessa acompanhar a arquitetura junto com o produto. Quando consigo observar a execução e a experiência que ela gerou, tenho mais elementos para decidir onde vale investir esforço.

Acompanhar uma execução até a resposta

Logs, métricas e traces fazem parte desse trabalho desde a operação da infraestrutura. Com agentes, também preciso olhar para o que aconteceu dentro de uma execução: o contexto disponível, as ferramentas chamadas e o resultado que chegou à pessoa.

Latência, consumo de tokens e custo por execução ajudam a entender o comportamento do sistema. A qualidade da resposta acrescenta outra pergunta: a execução que terminou bem do ponto de vista técnico também foi útil para quem perguntou?

Uma resposta pode chegar sem erro e ainda deixar de atender ao pedido. Pode usar uma ferramenta corretamente, mas trabalhar com um período diferente do solicitado. Pode trazer uma explicação bem escrita que não ajuda o cliente a decidir o próximo passo. Por isso, acompanhar qualidade exige olhar para a pergunta e para o contexto da conversa, além dos sinais técnicos.

As avaliações entram nesse acompanhamento como uma forma de verificar comportamentos esperados e observar mudanças. O uso em produção traz situações que precisam voltar para essa análise. É um trabalho contínuo de entender o que aconteceu e melhorar a próxima execução.

Já escrevi com mais detalhe sobre observabilidade para agentes de IA e sobre como medir qualidade em produção. O que esse projeto reforçou para mim foi a importância de conseguir relacionar essas informações ao produto que a pessoa está usando.

Olhar o uso também é trabalho de engenharia

Junto das métricas técnicas, tenho acompanhado adoção e engajamento. Quero entender como os clientes usam a plataforma, onde encontram dificuldade e o que faz com que voltem.

Essas perguntas mudam a leitura dos números. Um volume maior de mensagens pode indicar interesse, mas também pode significar que a pessoa precisou insistir para conseguir uma resposta. Uma conversa curta pode ter sido abandonada ou ter resolvido rapidamente uma dúvida. O número sozinho não conta o que aconteceu.

Olhar para esse contexto ajuda a escolher o próximo trabalho. Se a dificuldade está em descobrir o que perguntar, talvez a melhoria esteja na entrada da experiência. Se a pessoa entende a resposta, mas não consegue usá-la no fluxo de trabalho, vale investigar como o resultado é apresentado. E, quando há um problema de qualidade, preciso entender em qual etapa ele começou.

Gosto dessa proximidade porque ela dá uma referência concreta para as decisões. Depois de passar tempo construindo uma capacidade, consigo acompanhar se ela fez sentido para quem precisava usá-la.

A sensação de começar um projeto no fim de semana

Em vários momentos, esse trabalho me trouxe aquela sensação de começar um projeto do zero em um fim de semana. A vontade de montar as partes, testar uma ideia e cuidar de um detalhe porque sei como ele se encaixa no que estou construindo.

Aqui, essa sensação vem junto da responsabilidade de ter clientes usando o produto em produção. Preciso acompanhar a operação, entender as limitações e voltar às decisões quando o uso mostra algo que eu ainda não tinha considerado.

Na Cobli, tive liberdade para assumir esse trabalho de ponta a ponta. Sou grato ao Parker Treacy, ao Fernando Freitas Alves e às pessoas que participaram dessa construção. Ter espaço para propor e construir, com a responsabilidade de acompanhar o resultado, tem feito essa experiência valer muito para mim.

O case publicado pela Mastra e compartilhado pelo Parker foi uma oportunidade de olhar para o que já foi construído. Meu relato no LinkedIn nasceu desse momento.

No dia a dia, o que mais me anima continua sendo poder acompanhar uma ideia desde a decisão de arquitetura até alguém usando aquilo para resolver uma necessidade. Fazia tempo que eu não tinha essa sensação de estar tão perto do produto inteiro.