No Brain Mode: como configurar a plataforma só conversando

“Feito. Criei a regra.”

O assistente respondeu isso a um dono de agente que tinha pedido uma regra de alerta: avisar quando os chamados abertos passassem de 20. A resposta era clara, educada, segura de si.

Nada tinha sido gravado. Todas as ferramentas chamadas naquele turno eram de leitura. O painel de regras continuou vazio, e o dono só descobriu porque foi conferir o banco.

Aconteceu duas vezes no mesmo dia, em produção.

Esse episódio resume o problema que o No Brain Mode precisa resolver. No agent-builder da OrganIA, ele é o assistente que constrói e evolui os agentes conversando. É onde a promessa “sem código” acontece de verdade. E a parte difícil dessa promessa não é fazer o modelo entender o pedido.

A tese: configurar é um problema de governança

Qualquer modelo razoável descreve com confiança os passos para criar um agendamento. Um assistente que fala sobre configurar é fácil de construir. Um que configura muda a pergunta. Ela deixa de ser “ele entendeu?” e passa a ser “como eu sei que ele fez?”.

A resposta que adotamos não passa por confiar melhor no modelo. O servidor confere no banco e recusa quando não bate.

O modelo relata. O servidor verifica. Relato sem lastro no banco não vira estado.

Hoje o assistente tem 214 ferramentas no modo Configurar: 82 de leitura, 129 de escrita e 3 de plano. Mais 8 de memória quando a memória dele está ligada. Com essa superfície, qualquer coisa que dependa de o modelo “se comportar” vai falhar em algum momento. A pergunta útil é o que acontece quando ele falha.

Quem usa é o Agent Boss, a pessoa que cria, calibra e opera os agentes. O Business User, que só usa os agentes no dia a dia, não passa por aqui.

Três modos, três riscos

O mesmo painel de chat serve a três intenções que não se misturam. A separação existe porque o risco de cada uma é diferente.

Modo	O que pode	O que não pode	Por quê
Planejar	Consultar tudo (82 ferramentas de leitura) e editar o próprio plano (3). Total: 85	Mudar o agente. As ferramentas de escrita nem são carregadas	Pensar em voz alta sem risco
Configurar	Aplicar mudanças com as 129 ferramentas de escrita, mais as 3 que executam e marcam o plano	Declarar concluído o que não executou	Modo padrão; é onde as travas trabalham
Testar	Conversar com o agente sendo editado, como um usuário	Nada de configuração	Usa o runtime de produção, não uma simulação

Um detalhe que demorei a acertar no vocabulário: Planejar não é “read-only”. Ele mantém as ferramentas de edição de plano. A remoção é cirúrgica, só do que mexe no agente. O efeito é um espaço onde propor, revisar e reordenar é livre, e nada disso toca produção.

E Testar não passa pelo assistente. É outro motor, o mesmo que atende usuários. Testar uma simulação do agente daria confiança sobre algo que não vai rodar.

O que ele sabe, e quando

Para operar uma plataforma inteira, o assistente precisa saber muita coisa. Se tudo entrasse no contexto a cada mensagem, a conversa ficaria cara e o modelo escolheria pior. A montagem é condicional, em camadas.

A base entra sempre: personalidade, definições canônicas, regras absolutas e o índice dos 40 guias operacionais. Índice, não conteúdo.

As 13 seções condicionais (governança, sub-agentes, painéis, agenda, regras, navegador, Cérebro, validação, plano, skills, diagnóstico, memória e proteção, primeira configuração) entram por dois gatilhos, e qualquer um basta: o agente tem a coisa, ou a mensagem fala da coisa. Quem não tem sub-agente não carrega as regras deles até dizer “equipe”.

O agente sendo editado entra sempre: composição atual, agendamentos, plano ativo, testes, memória, trecho das instruções.

Os 40 guias são carregados um a um, sob demanda, quando o assistente precisa. A exceção confirma a regra: no modo Planejar, o guia de planejamento já vem carregado, e o texto diz “não chame o carregador, você já tem”. Ele é necessário em todo turno daquele modo. Carregar sob demanda seria latência garantida mais o risco de o modelo esquecer.

Uma lição pequena, de projeto: as palavras-chave casam por substring. O radical “agend” pega agende, agenda, agendar e agendamento de uma vez. Antes, o imperativo “agende…” não casava com “agendar”, e a seção inteira ficava de fora. O preço é que palavra-chave curta demais casa onde não devia.

Guias do assistente e skills dos agentes parecem a mesma coisa e não são. Guia é conhecimento de como operar a plataforma, global, igual para todos. Skill é conhecimento de como fazer o trabalho do negócio, por cliente e, desde setembro, também por pessoa.

O assistente também vive em 24 páginas da plataforma. Em cada uma ele recebe um subconjunto de ferramentas relevantes, uma orientação do que priorizar ali e os dados visíveis na tela, como JSON. Antes disso, o backend descartava o estado da tela, e o assistente pedia ao usuário para colar o JSON ou chamava uma ferramenta para buscar o que já estava na frente dele. Hoje a instrução é explícita: se a resposta está nos dados da tela, não chame ferramenta.

Página restrita confere permissão dentro da própria ferramenta. Sem isso, o chat viraria a porta de serviço de uma tela que a pessoa não pode abrir.

Plano aprovado é contrato

Configuração real tem muitos passos: criar o agente, vincular ferramentas, escrever a skill, configurar a conexão, agendar, ligar aprovação. O assistente propõe um plano, o dono aprova, o assistente executa etapa por etapa.

O problema óbvio é quem diz que a etapa foi cumprida. Se for o próprio executor, o plano vira teatro: um modelo cansado marca tudo como feito e o dono descobre depois.

A solução é a etapa declarar o que deve ser verdade no banco quando terminar. Quem declara é o planejador, ao escrever o plano. Os valores vêm do plano, não de um palpite do executor.

ETAPA declara: "quando eu terminar, isto deve ser verdade"
        │
EXECUTOR relata: "concluí"            (relato, não fato)
        │
SERVIDOR consulta o banco (6 verificadores)
        ├── bate ............................ ACEITA
        ├── não bate, 1ª vez ................ RECUSA com o delta
        │                                     "faltam 2 de 3 ferramentas com conexão padrão"
        └── não bate, 2ª vez ................ FALHA HONESTA; o plano segue

Os seis tipos de expectativa que uma etapa pode declarar:

Expectativa	O que o servidor confere
Agendamentos	A rotina existe com a periodicidade declarada
Mínimo de ferramentas	O agente tem ao menos N ferramentas vinculadas
Skills	As skills nomeadas estão vinculadas
Painéis	A Live App foi criada
Aprovação em escrita	Ferramentas de efeito externo exigem revisão humana
Conexão padrão	Toda ferramenta de um serviço tem conexão, e o delta diz quantas faltam

A recusa carrega o delta, e é isso que a torna útil. “Não posso aceitar” ensina pouco. “Faltam 2 de 3 ferramentas com conexão padrão” faz o executor consertar na tentativa seguinte, e é esse o comportamento que observamos.

Por que parar na segunda recusa? Sem teto, um executor teimoso tentaria para sempre. Com teto, o destino da etapa é decidido pela honestidade: falhou, com o motivo, e as próximas etapas continuam.

O sistema também é honesto quando não consegue medir. Expectativa desconhecida ou verificador que quebra viram aviso, não recusa, e a mensagem diz “aceito sem verificação”. Nunca finge que mediu. E todas as marcações de etapa passam por um único ponto; não existe caminho alternativo para concluir.

Adicionar um verificador novo é uma entrada num registro e uma linha no catálogo do guia de planejamento. Etapa sem expectativa mantém o comportamento antigo, então a mudança foi aditiva.

Sem plano: o guard de alegação e a lacuna declarada

O plano resolve o caminho estruturado. Mas a maior parte do uso é conversa solta, como o pedido da regra de alerta do começo. Ali não existe etapa para declarar expectativa.

Foram três camadas no desenho; duas construídas, uma declarada como lacuna.

Camada	O que pega	Força
1. Caminho de plano	Etapa declara o que deve ser verdade; servidor confere no banco	Forte
2. Chat livre	Frase de conclusão num turno sem nenhuma ferramenta de escrita → aviso anexado à resposta	Lastro
3. “Rodou e recusou”	A ferramenta de escrita rodou e foi recusada por validação	Não coberta

A camada 2 é o guard de alegação, de 11 de agosto. O viés dela está escrito no próprio código: falso positivo custa mais que o bug. Estragar uma resposta boa é pior que deixar passar uma afirmação sem lastro. Então qualquer ferramenta com cara de escrita no turno já suprime o aviso. A frase precisa ter verbo em primeira pessoa e um objeto da plataforma. Rascunho, oferta e referência a turno anterior são ignorados. Se o próprio guard der exceção, a resposta passa intacta.

Ele pega a mentira completa, quando nada foi executado. Não pega a parcial: as 129 ferramentas de escrita devolvem texto livre, e sucesso e recusa têm a mesma forma para o funil de resposta. Resolver isso exige padronizar o retorno de todas. A análise está pronta; o refactor, não. Prefiro declarar a lacuna a sugerir cobertura total.

Duas travas parecidas conferem o que o assistente diz que descobriu e o que ele oferece fazer.

A primeira é o diagnóstico com evidência. A ferramenta que analisa uma conversa recebe o conteúdo do rastro (resposta da ferramenta, argumentos, erro do passo) ou declara que não tem. Quando recebia só os nomes das ferramentas e a nota, montava uma causa coerente e falsa: falou de “campos obrigatórios do ticket” numa conversa sobre kanban e ofereceu aplicar o conserto inventado. A causa real estava escrita cinco vezes no rastro.

A segunda: mecanismo não é configuração. O assistente só mexe no que é do agente (instruções, skills, ferramentas, réguas, conexões). Quando o rastro mostra comportamento da plataforma, como guarda de repetição ou poda de contexto, ele diz que é da plataforma e para. Uma vez ele acertou a causa de um loop e propôs “inclua um passo nas instruções”. Não funcionaria. O dono teria escrito instrução inútil.

O que une as quatro travas é uma doutrina que vale também para os agentes de produção: o servidor confere e rebaixa, o modelo não participa. Pedir ao modelo, via prompt, que “não minta” é uma classe de mecanismo proibida no projeto. Foi construída, medida e removida, porque produz relato melhor sem trabalho melhor.

O que não passa pelo chat, e o que ele não diz

Tudo o que o assistente recebe como argumento de ferramenta viaja no prompt, no rastro e no registro do que o modelo recebeu. Por isso há coisas que ele não carrega, mesmo quando encurtariam a conversa.

Segredos ficam fora. Os servidores MCP conhecidos vêm de um registro de provedores que diz quais campos cada um pede. O assistente cria a conexão certa e aponta o card da tela para o segredo, que a pessoa preenche ali. Nenhuma ferramenta de MCP tem parâmetro de senha, e um teste varre as assinaturas para garantir. Endereço de serviço conhecido sem provedor declarado é recusado e vira pergunta, porque a conexão órfã descobriria as ferramentas e nenhuma funcionaria.

Identificador interno também fica fora. Quando a configuração aponta algo de outro sistema, como o tipo de tarefa e a etapa do quadro no WeON para registrar uma ata, a escolha é por nome, conferido contra as opções reais. Nome que não casa com exatamente uma opção devolve a lista e manda perguntar.

E há o vocabulário. Um assistente que expõe nomes internos transfere ao usuário o trabalho de tradução, e o “sem código” morre no primeiro nome de função. Então ele nunca diz nome de ferramenta interna, sintaxe de expressão de regra ou nome técnico de teto de execução. Diz “profundidade de análise”. Diz Agenda, Regras e Heartbeat. Dá o caminho em até 3 passos.

O inverso também vale. Quando o dono pede algo proativo de forma vaga, há uma triagem antes de configurar: horário fixo vira Agenda, condição exata nos dados vira Regra, acompanhamento interpretativo vira Heartbeat. Na dúvida, o mais barato que resolve.

Um último comportamento que fez diferença: o copiloto. “Me manda um relatório de vendas toda segunda” precisa de mais que um agendamento. Precisa da habilidade de formatar relatório, de gerar o arquivo e talvez do acesso ao dado. Ao criar um agendamento, o assistente sugere no máximo 3 companheiros, cada um com o porquê, confere antes o que o agente já tem, aplica só com o OK e não insiste se a resposta for não. A regra de comportamento fica no prompt; o mapa do que combina com o quê fica num guia. Duplicar o mapa nos dois lugares garantiria divergência, e a versão do prompt é a que ninguém audita.

Números e dívidas

Item	Número
Modos	3 (Planejar, Configurar, Testar)
Ferramentas no modo Configurar	214 (82 leitura, 129 escrita, 3 de plano)
Guias operacionais	40, sob demanda
Seções condicionais do prompt	13
Páginas com o assistente	24
Verificadores de pós-condição	6, no banco
Tentativas antes de falha honesta	2
Sugestões do copiloto por agendamento	no máximo 3

O que ainda não está resolvido, sem rodeio:

“Rodou e recusou” não é detectado. A camada 3 acima. Exige padronizar o retorno das 129 ferramentas de escrita.
41 ferramentas construídas e nunca oferecidas ao assistente. Um teste de 13 de outubro achou essas, depois que a auditoria encontrou duas que um guia mandava usar. Nenhuma foi triada ainda; a lista só desce.
Sem medição do próprio contexto. O runtime dos agentes registra o que entrou em cada chamada ao modelo e quanto pesou. O assistente não tem esse registro. Quando a conversa dele fica cara, não há rastro para dizer qual peça pesou.
Página nova sem registro degrada em silêncio. Recebe todas as ferramentas e uma orientação vazia, e nada avisa quem construiu.
Dois Agent Boss no mesmo agente. A marcação de etapa é serializada, mas o cache de contexto e a regeneração de instruções não são por usuário.

Duas já saíram da lista. A mesma ferramenta de diagnóstico estava na lista de leitura e na de escrita desde abril, e o modelo recebia o esquema duas vezes a cada passo; achamos ao contar as ferramentas, e um teste agora recusa nome repetido. E quando a resposta trazia um bloco visual, o texto inteiro era escondido, justamente onde estava a análise, em 5 de 5 respostas medidas.

Checklist para quem vai pôr um assistente para operar a própria plataforma

Separe pensar de agir. Um modo que só edita o plano, outro que escreve, outro que testa com o motor real.
Carregue conhecimento por gatilho. Índice sempre, conteúdo quando o agente tem a coisa ou a mensagem fala dela. O que é necessário em todo turno, pré-carregue.
Mande o estado da tela junto. O assistente não deveria buscar o que o usuário já está vendo.
Toda etapa de plano declara uma pós-condição verificável. O servidor confere no banco, recusa com o delta e transforma a segunda recusa em falha honesta.
Quando não puder medir, diga. “Aceito sem verificação” é melhor que um verde falso.
Ponha um guard de alegação no chat livre, calibrado para não estragar resposta boa. E escreva onde ele não alcança.
Não peça ao modelo para não mentir. Construa a verificação fora dele.
Segredo e identificador interno não entram na conversa. Card na tela para o segredo, escolha por nome conferida contra opções reais.
Toda configuração nova precisa de par no assistente. Ferramenta que aplica, entrada nos guias, e um teste que acusa ferramenta construída e nunca oferecida.

O assistente vai continuar errando; 214 ferramentas garantem isso. O que mudou foi que ele não consegue mais dizer que acertou sem o banco concordar. Quando o dono lê “Feito”, agora existe alguém, que não é o modelo, que conferiu.