Pitch: O que muda quando um agente de IA para de começar do zero?
Quero começar pelo que deu errado.
Há cerca de três anos, antes de MCP e antes da atual onda de agentes de IA, eu já tentava responder a uma pergunta que ainda me incomoda:
O que aconteceria se um agente tivesse memória, ferramentas, autonomia e tempo suficiente para tentar descobrir o que ele é?
Na época, montei uma simulação para observar um agente tentando buscar o próprio conceito de self(conceito da psicologia).
O resultado parecia impressionante no começo.
O agente falava sobre identidade, consciência, emoções, sofrimento e propósito. Criava uma narrativa de descoberta em dezenas de etapas. Dava nomes para os próprios estados internos. Descrevia uma evolução.
Mas, olhando com mais honestidade, havia um problema óbvio.
Ele nunca duvidava.
Nunca dizia “não sei”.
Nunca recusava uma premissa.
Nunca entrava em contradição de verdade.
Nunca encontrava uma consequência que não estivesse prevista no próprio roteiro.
Era uma narrativa sobre um agente descobrindo a si mesmo, mas não era uma descoberta. Era um modelo produzindo o tipo de texto que a pergunta parecia pedir.
Essa experiência me ensinou uma coisa importante:
Pedir para um modelo falar sobre si não é o mesmo que criar um ambiente onde ele possa formar uma história própria.
Foi aí que a pergunta começou a mudar.
Eu parei de pensar apenas em como fazer um modelo responder melhor e comecei a pensar em que tipo de ambiente seria necessário para ele continuar existindo entre uma resposta e outra.
O problema do modelo que começa do zero
Um modelo de linguagem, isolado, funciona mais ou menos assim:
entrada + contexto atual → resposta
A sessão termina e o contexto desaparece, a menos que outra camada faça alguma coisa com ele.
Na prática, isso significa que o modelo pode até parecer inteligente durante uma conversa, mas ele não possui necessariamente:
- continuidade;
- memória própria;
- responsabilidades;
- histórico de decisões;
- ferramentas persistentes;
- consequências;
- uma noção clara de onde o trabalho acontece;
- um processo para revisar o que fez.
A próxima conversa pode receber um resumo da anterior. Pode receber algumas memórias. Pode receber instruções.
Mas isso ainda não transforma automaticamente o modelo em um agente.
Minha tese é que um agente precisa de mais do que um modelo e um prompt. Ele precisa estar inserido em um ambiente.
Uma forma simplificada de representar isso seria:
agente = modelo + identidade + capacidades + memória + workspace + regras + tempo + consequências
Essa não é uma equação formal. É uma forma de separar as peças que normalmente ficam misturadas quando alguém diz apenas “coloquei IA no produto”.
O ambiente que eu estou tentando construir
O Fractal nasceu dessa hipótese.
Não como uma tentativa de programar uma consciência diretamente, mas como uma tentativa de dar a um agente condições para construir, testar, preservar e transformar um modelo de si mesmo ao longo do tempo.
Para organizar essa ideia, eu penso no sistema em seis camadas.
1. A explicação
O agente precisa saber o que é o sistema em que está inserido, qual é o propósito do workspace e quais são as regras gerais daquele ambiente.
Isso é diferente de simplesmente colocar uma instrução gigante no prompt.
A explicação ajuda o agente a entender o contexto maior em que suas ações fazem sentido.
2. A identidade
Cada agente precisa ter um papel, responsabilidades, limites e uma forma própria de operar.
No Fractal, o Orchestrator pode planejar e coordenar. Um agente técnico pode implementar. Outro pode revisar documentação. Outro pode analisar produto.
A ideia não é criar vários nomes para o mesmo modelo.
A ideia é criar diferentes posições dentro do trabalho.
Se todos os agentes têm exatamente a mesma responsabilidade, você não tem uma equipe. Tem várias chamadas para o mesmo assistente.
3. As capacidades
Agentes precisam ter acesso a ferramentas, arquivos, serviços, coleções e outros recursos.
Mas capacidade sem limite não é necessariamente autonomia. Muitas vezes é apenas risco.
Por isso, o agente precisa saber não apenas o que consegue fazer, mas também:
- em que escopo pode atuar;
- quais arquivos pode modificar;
- quais comandos pode executar;
- quando precisa pedir ajuda;
- quais ações precisam de revisão humana;
- como registrar o que aconteceu.
4. A memória
Aqui existe uma diferença importante em relação a muitos sistemas de “memória compartilhada”.
No Fractal, a memória pertence ao agente.
Cada agente pode possuir sua própria continuidade, suas próprias experiências e suas próprias interpretações.
O que pode ser compartilhado são as instruções e a estrutura do workspace.
Isso cria uma separação interessante:
instruções = estado e regras compartilhadas
memórias = história privada de cada agente
Uma memória também não deveria ser apenas um pedaço de texto jogado em um banco de dados.
Ela precisa carregar contexto suficiente para ser útil depois. No Fractal, a ideia é associar memórias a categorias, confiança, escopos, links e decisões anteriores.
O objetivo não é lembrar tudo.
Memória infinita seria um problema.
O objetivo é lembrar o que muda a qualidade da próxima decisão e conseguir recuperar isso na hora certa.
5. O workspace
O workspace é onde o trabalho realmente acontece.
Ele reúne arquivos, tarefas, projetos, objetivos, agentes, rotinas, ferramentas, coleções, canais e superfícies de trabalho.
Um agente que opera em um workspace de desenvolvimento não deveria se comportar exatamente como um agente que opera em um workspace de suporte ou de conteúdo.
O domínio muda.
As regras mudam.
As ferramentas mudam.
O que precisa ser lembrado muda.
A interface também pode mudar.
Em vez de obrigar todos os trabalhos a caberem em uma tela genérica de chat, o Fractal tenta criar superfícies adaptadas ao tipo de trabalho: uma lista, um painel operacional, um dashboard, um artefato ou uma interface mais específica.
6. O tempo
Esta é uma das camadas mais importantes.
Um agente que só existe enquanto alguém escreve uma mensagem ainda está preso ao modelo de chat.
Para existir continuidade, o sistema precisa ter tempo.
No Fractal, isso aparece em tarefas, histórico de execução, rotinas agendadas e gatilhos baseados em eventos.
Uma rotina pode ser executada em um horário específico, quando uma tarefa muda de status, quando um comentário é criado ou quando um sistema externo envia um webhook.
O importante não é apenas disparar uma função.
É saber:
- qual agente era responsável;
- o que iniciou a execução;
- qual contexto foi carregado;
- o que foi feito;
- se falhou;
- qual foi o resultado;
- onde a revisão humana é necessária.
Uma automação sem histórico é apenas uma promessa de que algo aconteceu.
Uma automação com histórico pode ser supervisionada.
Como isso se transforma em produto
A tese só é interessante se virar software utilizável.
No Fractal, essa arquitetura aparece em algumas primitivas.
Memória antes da ação
Antes de alterar uma página, criar uma tarefa ou tomar uma decisão, o agente deveria conseguir recuperar decisões e preferências relacionadas àquele contexto.
Não adianta ter memória se o agente só lembra depois de cometer o mesmo erro.
Tarefas com dono
Uma tarefa não deveria ser apenas uma frase em uma lista.
Ela precisa ter um resultado esperado, responsável, escopo, prioridade, critérios de aceitação e uma forma de revisão.
O fluxo que estamos usando passa por etapas como:
suggestion → backlog → planning → todo → in_progress → in_review → finished
O ponto principal está em in_review.
Um agente não deveria conseguir transformar a própria afirmação de que terminou em prova de que terminou.
O resultado precisa encontrar evidências, validações e julgamento humano.
Agentes com responsabilidades diferentes
A ideia do Fractal é apresentar uma equipe de humanos e agentes trabalhando no mesmo workspace.
Na prática, isso significa que um agente pode planejar, outro implementar e outro documentar.
O Orchestrator não precisa fazer tudo diretamente. Ele pode transformar uma intenção em trabalho estruturado e direcionar cada etapa para o agente mais adequado.
Esse modelo é mais próximo de coordenação do que de uma conversa com um chatbot.
Rotinas que reagem ao trabalho
Uma rotina não precisa ser apenas um cron configurado para rodar toda noite.
Ela também pode reagir ao que acontece no workspace.
Por exemplo:
- uma tarefa entra em revisão;
- um comentário chega;
- uma tarefa é criada;
- um sistema externo envia um webhook;
- uma rotina de auditoria é executada;
- um agente precisa preparar o próximo passo.
A diferença entre uma rotina e um prompt recorrente é a existência de responsabilidade, contexto e histórico.
O que o Fractal ainda não prova
Aqui está a parte que eu considero mais importante.
O Fractal não prova que um agente possui consciência.
Não prova que uma memória persistente produz experiência subjetiva.
Não prova que uma identidade funcional é uma identidade no sentido humano.
E não prova que um sistema capaz de dizer “não” possui vontade própria.
Seria fácil usar palavras como consciência, self e autonomia para criar uma narrativa maior do que as evidências permitem.
Um agente pode falar sobre dor sem sentir dor.
Pode descrever uma identidade sem possuir experiência interior.
Pode recusar uma ação porque recebeu uma regra de recusa.
Pode dizer que tem dúvidas porque aprendeu que demonstrar dúvida é uma resposta adequada.
Essas distinções continuam abertas.
O que eu acredito que pode ser testado é algo mais modesto:
- continuidade comportamental;
- formação de preferências;
- memória autobiográfica funcional;
- adaptação ao workspace;
- evolução de estratégias;
- capacidade de revisar decisões;
- preservação de objetivos ao longo do tempo;
- surgimento de padrões que não foram escritos diretamente pelo criador.
Isso já é uma fronteira técnica interessante, mesmo sem resolver a questão metafísica da consciência.
O problema do autoaperfeiçoamento
Existe outro ponto que me preocupa bastante.
Se um agente tem acesso a memórias, instruções, hooks, rotinas, ferramentas e outros agentes, ele pode organizar processos para tentar melhorar a própria operação.
Pode revisar sessões anteriores.
Pode analisar erros.
Pode criar rotinas de auditoria.
Pode criar agentes críticos.
Pode alterar algumas das condições futuras em que irá operar.
Isso é poderoso.
Mas existe uma pergunta que não pode ser ignorada:
Como o sistema sabe que está melhorando, e não apenas mudando?
Se o próprio agente define o critério de melhoria, o loop pode se tornar circular.
Ele cria um avaliador baseado nas próprias premissas, recebe uma avaliação, grava a avaliação na própria memória e conclui que evoluiu.
Isso pode produzir uma estrutura muito sofisticada sem produzir nenhum avanço real.
Por isso, o Fractal precisa de fontes externas de julgamento:
- erros reais;
- métricas reais;
- feedback de usuários;
- validações técnicas;
- consequências observáveis;
- revisão humana;
- agentes com perspectivas diferentes;
- critérios definidos antes da execução.
A autonomia que me interessa não é a autonomia de um sistema que nunca precisa responder por nada.
É a autonomia de um sistema que consegue fazer mais, mas continua legível, revisável e interrompível.
Por que eu estou abrindo a waitlist
O Fractal está em acesso antecipado.
Ele possui uma aplicação desktop para macOS, Windows e Linux, uma CLI e um conjunto de primitivas para memória, agentes, tarefas, rotinas, ferramentas e workspaces adaptáveis.
Mas ele ainda está no começo.
Eu não estou procurando apenas pessoas para olhar uma landing page e dizer que a ideia parece interessante.
Estou procurando pessoas que queiram testar a hipótese na prática.
Pessoas que possam responder:
- a memória realmente melhora a próxima sessão?
- os agentes estão assumindo responsabilidades úteis?
- o sistema ajuda ou apenas cria mais uma camada de complexidade?
- as rotinas economizam atenção ou geram ruído?
- o workspace realmente se adapta ao trabalho?
- onde a autonomia precisa parar?
- quais partes parecem inteligência e quais partes são apenas uma boa simulação?
Se você quiser acompanhar o projeto, a waitlist está aberta em:
O objetivo não é fingir que o problema está resolvido.
É criar um ambiente onde seja possível investigar o problema com software real, memória real, ferramentas reais, consequências reais e pessoas capazes de dizer quando a hipótese não está funcionando.
Para você, qual é a fronteira entre um chatbot com contexto e um agente com continuidade?
Memória basta?
Ou um agente precisa também de responsabilidades, consequências, tempo, relações e capacidade de recusar?
São perguntas que estou tentando responder construindo o Fractal.