DATTA Captain — peça em português, aprove o plano

Preview — funcionalidade em desenvolvimento. Comportamento, telas e contratos podem mudar sem aviso entre versões.

O DATTA Captain é a outra porta da plataforma. Em vez de procurar a tela certa, você escreve o que quer — "criar um usuário analista para a Maria", "montar um painel dos dossiês com CNPJ e razão social", "agendar um backup diário" — e ele monta o caminho usando o que a plataforma já faz.

Ele fica a um clique de qualquer tela, no botão flutuante do canto, e tem uma tela própria no menu.

O que o torna diferente de um assistente que "tenta fazer"

Ele consulta à vontade; para alterar, pergunta antes.

O Captain trabalha como alguém que conhece a plataforma: consulta o que precisa saber, olha o que voltou e decide o passo seguinte com essa informação em mãos. Consultar não interrompe você.

Alterar, sim. Quando ele chega a uma operação que muda alguma coisa — criar, editar, apagar, disparar —, ele para e mostra o cartão de plano: o que vai mudar, com quais dados, e qual permissão aquilo exige. Nada acontece até você confirmar.

E o cartão é melhor do que era: como ele já consultou antes de propor, o que você aprova foi montado com os dados reais da plataforma, e não adivinhado antes de olhar.

Se você recusar, nada é executado, e a tela diz isso com todas as letras: quem acabou de ler uma lista de alterações precisa saber que nenhuma delas foi feita.

Ele responde perguntas, não só executa

Pergunte "quais conexões estão sem catalogação?", "quantos processos entraram este mês?", "que workspaces existem e quem é o dono de cada um?" — ele consulta a plataforma e responde com os dados, citando nomes, números e valores concretos.

Embaixo da resposta aparece de quantas consultas ela saiu. Não é enfeite: uma resposta que não se apoia em nenhuma consulta é o Captain falando de memória, e você precisa poder notar isso.

Quando a resposta depende de olhar item por item — "quais dessas estão sem catalogação" exige listar e então conferir cada uma —, ele faz as duas coisas sozinho. É o tipo de pedido que antes recebia "não é possível determinar".

Quando ele não sabe, ele diz — e procura antes de dizer

Se o que você pediu depende de um dado que só você tem (um nome, um e-mail, qual workspace), ele pergunta em vez de inventar um valor plausível.

E antes de dizer que a plataforma não faz algo, ele procura de novo, com outras palavras, e chega a listar tudo o que existe naquele assunto. A lista que ele vê primeiro é a das operações mais parecidas com o seu pedido — não a de todas as mais de mil que existem —, e concluir "não existe" a partir dela seria concluir demais.

Um pedido, várias operações

Um pedido em português costuma conter mais de uma operação — "criar o usuário e dar o papel de analista" são duas. O Captain separa o pedido nas operações que ele contém antes de procurar como fazer cada uma, e devolve um plano só, com os passos na ordem em que fazem sentido.

Isso importa porque procurar pelo pedido inteiro encontra a operação principal e perde as outras — e um agente que só encontrou metade tende a preencher o resto por conta própria. Aqui ele não preenche: se falta uma operação para realizar o pedido, ele diz o que falta.

Texto longo, com muitas instruções

Você pode escrever um texto com dez instruções de uma vez. O Captain trata cada uma como um pedido próprio: o plano vem dividido em blocos, um por instrução, com o texto dela no cabeçalho — em vez de uma lista corrida de trinta passos em que ninguém consegue dizer qual passo atende a qual pedido.

Três coisas valem a pena saber:

• Instruções sem relação entre si não esperam umas pelas outras. Só quando uma precisa do resultado da anterior (o identificador que ela vai criar, por exemplo) é que as duas ficam ligadas — e aí elas aparecem no mesmo bloco.
• Se uma parte não puder ser planejada, as outras continuam. O bloco dela aparece dizendo "não planejei esta parte", e o motivo fica na nota do plano. Nenhuma instrução some sem explicação.
• Há um limite de instruções por mensagem (dez, por padrão). Quando ele é atingido, o plano diz quais instruções ficaram de fora, com o texto de cada uma, para você enviá-las na mensagem seguinte.

Um bloco pode citar algo da plataforma pelo nome (ver a seção seguinte): "rode o pacote CNPJ e depois liste as conexões" são duas instruções, e a primeira continua usando o identificador real do pacote.

Chame as coisas pelo nome

Você pode citar o que existe na plataforma pelo nome, como falaria com um colega: "executar o pacote CNPJ", "abrir o dashboard Vendas 2026", "criar um painel no workspace Fiscal". O Captain reconhece pacotes do Datta Extract, workspaces, contextos e dashboards — e usa o identificador real de cada um, em vez de tentar adivinhar.

Duas consequências práticas:

• Ele não confunde mais "extract" com "extração". Antes, "executar o pacote extract CNPJ" caía na extração de entidades de texto, porque a palavra é a mesma. Agora o que decide é o pacote citado, não a semelhança das palavras.
• Ele não inventa identificador. Se o nome que você citou não existe, ele diz isso — em vez de montar uma chamada com um código plausível e errado.

Quando o nome é ambíguo (há sete pacotes começando por "Base Negativa"), ele não escolhe por você: mostra as opções ou pergunta qual delas.

O cartão de plano

Cada passo aparece com três informações:

Passos que alteram alguma coisa vêm marcados. Se algum deles for de escrita e não estiver protegido por uma verificação automática, o cartão o destaca — não para assustar, mas porque uma alteração sem guarda merece uma segunda olhada antes do "confirmar".

Quando o plano cria uma tela

Se o plano vai criar um painel, o cartão mostra a tela, não a descrição dela: título, de onde vêm os dados, quais colunas, quais filtros e as primeiras linhas reais.

A razão é simples: "criar o painel de dossiês" descreve a ação, não o resultado. Aprovar essa frase é aprovar no escuro — e um painel errado fica no espaço de trabalho de todo mundo até alguém reparar.

Se a amostra de dados não puder ser carregada na hora, a tela ainda aparece com o formato e um aviso explicando por quê. Você decide pelo desenho.

Permissão: ele faz o que você pode fazer

O Captain age com a sua identidade, nunca com uma elevada. O que você não consegue fazer pelas telas, também não consegue por ele.

E o plano avisa antes: se algum passo exige uma permissão que você não tem, o cartão diz qual é e não oferece o botão de confirmar. Você descobre no planejamento, não depois de metade das alterações terem acontecido.

Ele não escreve código

Essa é uma escolha de projeto, não uma limitação temporária.

O Captain usa as operações que a plataforma já tem. Ele as descobre sozinho a partir do próprio código do DATTA, então uma funcionalidade nova aparece para ele na publicação seguinte, sem que ninguém precise ensiná-lo.

O que isso significa na prática:

• Ele cria painéis, porque painel no DATTA é um artefato — algo que a plataforma sabe criar.
• Ele não cria telas programadas à mão. Uma tela feita sob medida nasce de alguém escrevendo código, e isso está fora do que ele faz.

Para escrever código dentro de um notebook, o assistente certo é o do próprio notebook — ele continua onde sempre esteve.

Depois de confirmar, ele continua trabalhando

Confirmar uma alteração não encerra o pedido. O Captain executa, lê o resultado e segue: se ainda falta algo, ele continua; se aparece outra alteração, mostra um novo cartão; quando termina, responde.

Isso vale também quando dá errado. Um erro do serviço de destino — "campo tipo obrigatório" — deixou de encerrar a conversa: ele lê o motivo e tenta de outro jeito, ou explica o que impediu. Antes, você ficava com o erro e mais nada.

O que acontece durante a execução

Depois do "confirmar", cada passo reporta o resultado assim que termina: concluído, ou com a explicação do que deu errado.

Um passo que falha interrompe o plano. Os seguintes não rodam, e isso é deliberado: o próximo passo normalmente depende do que o anterior produziria, e executá-lo geraria um segundo erro que esconderia o primeiro. O diário mostra o que ficou feito até ali — depois de uma falha, essa é a informação que mais importa.

Se a conexão cair no meio, o diário sobrevive: reabra a sessão e ele mostra tudo que já aconteceu.

O diário

Toda sessão fica registrada: o que foi pedido, o plano proposto, se foi confirmado ou recusado, cada passo com o tempo que levou, e o desfecho.

Serve para duas coisas. Para você, é a memória do que foi feito e por quem. Para quem cuida da plataforma, é o material que mostra onde o Captain tropeça com frequência — e isso vira melhoria da própria plataforma, não do agente.

Esse histórico é preservado quando o mecanismo de busca por significado da plataforma é trocado: os registros antigos são reescritos com o novo mecanismo, em vez de descartados. Sem isso, "isto já foi pedido antes?" passaria a responder apenas sobre o que aconteceu depois da troca.

Quem administra a plataforma tem também um resumo por operação: quantas vezes cada uma foi executada, com que taxa de sucesso e quanto tempo levou. Nesse resumo, o pedido que o Captain recusou aparece separado da falha — recusa é operação que a plataforma ainda não sabe fazer, e uma recusa que se repete é um pedido de funcionalidade com demanda medida.

Anexos: o que ele lê

O texto do anexo é extraído e vai para o modelo sempre, em qualquer modelo.

Quando o modelo escolhido enxerga imagem, o arquivo original vai junto — e aí um PDF que é sobretudo desenho (um diagrama de modelo de dados, um print de tela) passa a ser lido de fato, em vez de virar as poucas linhas de texto que dava para extrair dele. Hoje quem enxerga é o Google Gemini.

Modelo que não enxerga recebe só o texto, como antes — nada quebra, e nada é perdido além do que a imagem mostrava.

Imagem solta (print de tela)

Além de documentos, você pode anexar imagem direto: .png, .jpg, .jpeg, .webp e .gif. Ela segue um caminho próprio — não há texto para extrair de um print, então o que vai ao modelo é a imagem em si.

Duas consequências práticas:

• A extensão precisa bater com o arquivo. Um .png que na verdade é um JPEG é recusado na hora, com a mensagem dizendo o que fazer. Isso não é burocracia: o formato anunciado viaja junto da imagem, e quando os dois divergem o provedor rejeita o turno inteiro — levando junto o texto do pedido, que teria funcionado sozinho.
• Se o modelo em uso não lê imagem, o Captain avisa no próprio plano, antes de você confirmar. É a diferença que importa em relação ao documento: de um PDF sobra o texto, de um print não sobra nada. Sem o aviso você confirmaria um plano achando que ele considerou o que você mostrou.

Dois limites, e os dois degradam sem derrubar o pedido:

• arquivo acima de 8 MB não vai como imagem (o texto dele vai);
• formato fora de PDF, PNG, JPEG, WebP e GIF não vai como imagem (o texto vai).

Qual modelo ele usa

O Captain usa um modelo próprio, escolhido em Configurações → IA → Modelo do DATTA Captain — separado do modelo de chat de propósito. O chat conversa; o Captain lê contrato de API e monta a chamada, e um erro ali é uma requisição errada, não uma frase ruim. Trocar um não troca o outro.

O combo lista os modelos do Google Gemini e, quando há um endpoint Runpod ativo, os modelos que ele serve. Modelos de embedding e de rerank não aparecem: eles não respondem a um pedido de plano, e escolher um deixaria o Captain mudo.

Sem nenhuma escolha, vale o Gemini 2.5 Pro. Trocar o modelo vale na próxima solicitação — não é preciso reiniciar nada.

Se você quiser que ele rode num modelo do Runpod — por exemplo um modelo com visão, mais forte para ler diagramas —, o caminho é Configurações → IA → Runpod → Endpoint dedicado ao DATTA Captain. Ali dá para escolher um endpoint que já existe ou criar um novo só para ele: o formulário de criação pergunta quem vai usar o endpoint, e escolhendo o Captain ele fica dedicado — não entra no chat.

O botão "Desfazer dedicação" devolve o Captain ao Gemini a qualquer momento.

Perguntas comuns

Ele pode apagar alguma coisa sem eu ver? Não. Toda alteração está no plano, e o plano espera a sua confirmação.

E se eu pedir algo que a plataforma não faz? Ele diz isso, em vez de inventar um caminho. Um plano com um passo imaginado seria pior que nenhum plano.

E se faltar um dado que só eu tenho? Ele pergunta. O Captain não preenche um e-mail, um nome ou um espaço de trabalho com um valor plausível — dado inventado é o tipo de erro que só aparece depois.

Posso ajustar o plano? Recuse e peça de novo com mais detalhe. O pedido mais específico produz um plano mais específico.