𝗔 𝗙𝗼𝗿𝗺𝗮 𝗖𝗼𝗿𝗿𝗲𝘁𝗮 𝗱𝗲 𝗖𝗼𝗻𝘀𝘁𝗿𝘂𝗶𝗿 𝘂𝗺𝗮 𝗔𝗿𝗾𝘂𝗶𝘁𝗲𝘁𝘂𝗿𝗮 𝗱𝗲 𝗜𝗔 Eu costumava pensar que tornar meu assistente de IA mais inteligente significava adicionar mais ferramentas ao mesmo loop. Isso funcionou por um tempo. Mas então meu assistente precisou realizar tarefas normais de usuário, como continuar uma tarefa a partir do chat, responder a uma pergunta de status ou lembrar de um fluxo de trabalho.
O problema não era quantas ferramentas meu assistente conseguia chamar, mas sim sua arquitetura. A arquitetura antiga era simples: mensagem do usuário -> loop do assistente -> ferramentas -> resposta. Isso é aceitável para uma demonstração, mas não para um assistente residente.
Um assistente residente precisa saber se uma mensagem é uma nova tarefa, um acompanhamento ou um cancelamento. Ele precisa evitar roubar a área de trabalho de outra tarefa e lembrar de procedimentos sem usar transcrições antigas.
Então, parei de pensar no meu assistente como um único agente e passei a tratá-lo como um plano de controle local. Agora, minha arquitetura é assim:
- Plano de Experiência: detém o controle de onde o usuário está falando
- Plano de Controle do Assistente: decide que tipo de trabalho se trata
- Plano de Execução de Runtime: onde o trabalho de codificação acontece
- Plano de Proxy / Acesso ao Modelo: lida com o trabalho do provedor
Eu também tenho um Plano de Observação e um Plano de Memória / Política. Esses planos ajudam meu assistente a manter a sanidade e o foco em suas tarefas.
A maior melhoria veio ao fazer meu assistente consumir observações em vez de logs brutos. Isso ajuda meu assistente a visualizar fatos compactos como "A tarefa X está aguardando aprovação" em vez de ler uma transcrição gigante.
Aprendi que "lembrar" não é o mesmo que entupir um prompt com mais histórico de chat. Para o meu assistente, a memória é baseada em arquivos e possui escopo. Ele pode armazenar um workflow, um fato ou uma referência e recuperá-los quando necessário.
Se você