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. O que a plataforma já sabe — em qual contexto está um processo, o identificador de algo que você citou pelo nome — ele consulta, não pergunta.

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.

Quando a pergunta é para o chat

Nem toda pergunta é uma operação da plataforma. Quando o Captain não encontra operação nenhuma que atenda o pedido — "quais empresas deste endereço têm sócio em comum?", "o que diz o artigo 479 da CLT?" —, ele pergunta ao chat da plataforma e mostra, no próprio painel, a resposta inteira, do mesmo jeito que a tela do Chat:

• o texto da resposta;
• o grafo, quando a pergunta é sobre vínculos;
• a tabela, quando a pergunta pede uma lista — com a paginação, a exportação e o botão Mapa, que plota as linhas no Google Maps;
• os três juntos, quando a resposta tem os três;
• o Mapa do texto, que localiza os endereços citados na resposta;
• a linha "Respondido a partir de N fontes" e, quando a resposta usou algoritmos de grafo ou análise estatística, "Busca avançada usando GDS + R".

Com tabela ou grafo, o painel alarga para caber. Abrir no chat continua a mesma conversa na tela do Chat — ela já está no seu histórico.

Para a pergunta que pede o quadro inteiro — vários contextos, as ligações no grafo, a linha do tempo e as evidências —, use o DATTA Investigation, no menu lateral: é o Chat no modo da pesquisa profunda, com a mesma barra de contextos e workspaces.

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.

Processos, pelo número. Escreva o número como ele aparece nas peças — "faça a triagem do processo 0000853-37.2021.5.10.0012" — e o Captain descobre sozinho em qual contexto o processo está e quais regras a triagem dele aplica, antes de montar o plano: o cartão de confirmação já mostra onde a triagem vai rodar. Você não precisa dizer o contexto. Se o número estiver em mais de um contexto, ele pergunta em qual; se não estiver em nenhum, ele avisa para conferir o número; se o processo só aparece citado em documentos de outro, ele diz que não há peças dele para triar.

O cartão de plano

O cartão é um resumo, não um plano de execução: a lista numerada do que vai acontecer, em português e do ponto de vista de quem pediu, uma linha dizendo quantos passos há e quantos alteram dados, e a pergunta — Sim, executar ou Não.

Cada linha diz o efeito do passo, com os dados concretos — "Cria o usuário ana@empresa.com com o papel de analista" —, nunca o nome de uma API. Quando o Captain não descreve o passo, a linha usa a descrição da própria operação, escrita por quem a construiu; o verbo e o caminho técnico só existem atrás de Ver detalhes.

Quando o Captain assumiu algo ou precisa ressalvar alguma coisa (o espaço de trabalho que ele escolheu por você, uma parte do pedido que ficou sem plano), isso aparece numa nota acima dos passos. A nota é só para ressalva: quando não há nada a dizer, ela não aparece, e o raciocínio interno do Captain — por que escolheu aquele caminho — não entra nela.

O detalhe técnico de cada passo fica atrás de Ver detalhes, no canto do cartão:

Se algum passo for de escrita e não estiver protegido por uma verificação automática, o resumo avisa mesmo com os detalhes fechados — não para assustar, mas porque nesse caso a sua confirmação é a única barreira, e isso você precisa saber antes do "sim".

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.

Quando termina: pedido atendido, e onde conferir

Terminado o pedido, o cartão deixa de se chamar "Plano" e passa a Concluído, com o ✓ de cada passo que rodou. Se alguma alteração foi feita, aparece abaixo o cartão Pedido atendido, dizendo quantas alterações aconteceram, e o bloco Como conferir: para cada tela da plataforma onde o resultado está, o caminho do menu — Sistema › Segurança › Usuários —, os passos a clicar e o que procurar na lista ("Procure 'ana@empresa.com' na lista"). O botão Abrir tela leva direto para lá.

O caminho é derivado do que a operação declara sobre si mesma, não adivinhado: uma operação que não diz de que tela é fica sem "onde conferir" — melhor do que um caminho errado.

Quando o pedido era uma pergunta e nada foi alterado, o desfecho é a resposta mesma, sem cartão de "atendido".

A conversa continua

Quando o Captain pergunta algo ("qual contexto de regras devo usar?", "qual o e-mail do usuário?"), basta responder na caixa de texto.

• A resposta segue a mesma conversa. O Captain lê o que você pediu antes, o plano que ele propôs e o que ele perguntou. Não é preciso repetir o número do processo nem o resto do pedido.
• As trocas anteriores ficam visíveis acima do pedido atual, em tom mais apagado.
• Mensagem nova com um plano aguardando confirmação substitui o plano: ele é recusado e o Captain monta outro com o que você acabou de dizer.
• Com passos em execução, espere terminar antes de mandar outra mensagem.

Em todo fim de linha (pedido atendido, pergunta respondida, plano recusado ou erro) há o botão Nova conversa. Ele limpa a tela, volta às sugestões e faz o Captain esquecer o que foi dito.

• No widget flutuante, o botão fica também no cabeçalho, ao lado do fechar, enquanto houver conversa.
• Recomeçar com um plano ainda aguardando confirmação equivale a recusá-lo: nada é executado.
• A conversa dura até 24 horas. Depois disso o Captain abre uma nova sozinho, sem erro na tela, e não lembra mais das mensagens anteriores.

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. O Google Gemini enxerga imagem e PDF. Um modelo de visão servido pelo vLLM ou pelo Runpod (por exemplo, um Qwen-VL) recebe a imagem; do PDF, ele recebe só o texto.

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 modelo do Captain é escolhido em Sistema → DATTA Captain → Modelo, e vale para a plataforma inteira. A lista traz os modelos configurados em Sistema → IA, em grupos: Google Gemini, vLLM (GPU), vLLM CPU e Runpod — este por endpoint, com o modelo que cada endpoint serve.

• A primeira opção, "Usar o modelo do chat", faz o Captain seguir o modelo do chat de Sistema → IA. É o que vale enquanto ninguém escolhe outro.
• Modelos que não servem para o Captain aparecem desabilitados, com o motivo: modelo de embedding ou de rerank, janela de contexto menor que o mínimo da plataforma, ou servidor desligado. Modelo com janela desconhecida pode ser escolhido, com uma ressalva.
• Abaixo da lista, a tela diz o modelo em uso agora e de onde ele vem (escolha do Captain ou modelo do chat). A aba Sistema → IA mostra o mesmo.

Trocar o modelo vale em até um minuto — não é preciso reiniciar nada. Se não houver modelo nenhum (nem escolha do Captain nem modelo do chat), o Captain responde que não há modelo configurado em Sistema → IA, em vez de usar um modelo que ninguém escolheu.

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? Responda "Não" e peça de novo com mais detalhe. O pedido mais específico produz um plano mais específico.