DATTA Captain — ask in plain language, approve the plan

Preview — feature under development. Behavior, screens and contracts may change without notice between releases.

DATTA Captain is the platform's other door. Instead of hunting for the right screen, you write what you want — "create an analyst account for Maria", "build a panel of dossiers with company ID and legal name", "schedule a daily backup" — and it assembles the path from what the platform already does.

It sits one click away on every screen, in the floating button at the corner, and has a screen of its own in the menu.

What sets it apart from an assistant that "just tries"

It queries freely; to change anything, it asks first.

Captain works like someone who knows the platform: it queries what it needs to know, looks at what came back, and decides the next step with that information in hand. Querying does not interrupt you.

Changing does. When it reaches an operation that alters something — create, edit, delete, trigger — it stops and shows the plan card: what will change, with which data, and which permission that requires. Nothing happens until you confirm.

And the card is better than it used to be: because it queried before proposing, what you approve was built from the platform's real data, not guessed before looking.

If you decline, nothing runs, and the screen says so plainly: someone who has just read a list of changes needs to know that none of them happened.

It answers questions, not just executes

Ask "which connections lack cataloging?", "how many cases came in this month?", "which workspaces exist and who owns each one?" — it queries the platform and answers with the data, naming names, counts and concrete values.

Below the answer you see how many queries it came from. That is not decoration: an answer resting on no queries is Captain speaking from memory, and you need to be able to notice that.

When the answer depends on looking item by item — "which of these lack cataloging" requires listing and then checking each one — it does both on its own. That is the kind of request that used to get "it is not possible to determine".

When it does not know, it says so — and it searches before saying so

If what you asked depends on a datum only you have (a name, an email, which workspace), it asks instead of inventing a plausible value. What the platform already knows — which context a case is in, the identifier of something you cited by name — it looks up, not asks.

And before saying the platform does not do something, it searches again, with different words, and even lists everything that exists on that subject. The list it sees first is of the operations most similar to your request — not all thousand-plus that exist — and concluding "it does not exist" from that would be concluding too much.

When the question is for the chat

Not every question is a platform operation. When the Captain finds no operation at all that fulfils the request — "which companies at this address share a partner?", "what does article 479 of the CLT say?" — it asks the platform chat and shows, in its own panel, the full answer, exactly like the Chat screen:

• the text of the answer;
• the graph, when the question is about links;
• the table, when the question asks for a list — with paging, export and the Map button, which plots the rows on Google Maps;
• all three together, when the answer has all three;
• the Map of the text, which locates the addresses mentioned in the answer;
• the "Answered from N sources" line and, when the answer used graph algorithms or statistical analysis, "Advanced search using GDS + R".

With a table or a graph, the panel widens to fit. Open in chat continues the same conversation on the Chat screen — it is already in your history.

For the question that calls for the whole picture — several contexts, the links in the graph, the timeline and the evidence — use DATTA Investigation, in the side menu: it is the Chat in deep-research mode, with the same contexts and workspaces bar.

One request, several operations

A request in plain language usually contains more than one operation — "create the user and grant the analyst role" is two. Captain splits the request into the operations it contains before looking up how to do each one, and returns a single plan, with the steps in the order that makes sense.

This matters because searching for the whole request finds the main operation and misses the others — and an agent that only found half of it tends to fill in the rest on its own. Here it does not fill in: if an operation is missing to fulfill the request, it says what is missing.

Long text, with many instructions

You can write a text with ten instructions at once. Captain treats each one as a request of its own: the plan comes split into blocks, one per instruction, with its text in the header — instead of a running list of thirty steps in which nobody can tell which step serves which request.

Three things are worth knowing:

• Unrelated instructions do not wait for each other. Only when one needs the previous one's result (the identifier it will create, for example) do the two get linked — and then they appear in the same block.
• If one part cannot be planned, the others go on. Its block shows up saying "I did not plan this part", and the reason stays in the plan's note. No instruction disappears without an explanation.
• There is a limit of instructions per message (ten, by default). When it is reached, the plan says which instructions were left out, with the text of each one, so you can send them in the next message.

A block may cite something on the platform by name (see the next section): "rode o pacote CNPJ e depois liste as conexoes" is two instructions, and the first one still uses the package's real identifier.

Call things by their name

You can refer to what exists on the platform by name, the way you would with a colleague: "executar o pacote CNPJ", "open the Vendas 2026 dashboard", "create a panel in the Fiscal workspace". The Captain recognizes Datta Extract packages, workspaces, contexts and dashboards — and uses each one's real identifier instead of trying to guess it.

Two practical consequences:

• It no longer confuses "extract" with "extraction". Before, "executar o pacote extract CNPJ" landed on text entity extraction, because the word is the same. Now what decides is the cited package, not word similarity.
• It does not invent an identifier. If the name you cited does not exist, it says so — instead of assembling a call with a plausible, wrong code.

When the name is ambiguous (seven packages start with "Base Negativa"), it does not choose for you: it shows the options or asks which one.

Cases, by number. Write the number as it appears in the documents — "faça a triagem do processo 0000853-37.2021.5.10.0012" — and the Captain finds out on its own which context the case is in and which rules its screening applies, before building the plan: the confirmation card already shows where the screening will run. You do not need to say the context. If the number is in more than one context, it asks which; if it is in none, it tells you to check the number; if the case only appears cited in another case's documents, it says there are no documents of its own to screen.

The plan card

The card is a summary, not an execution plan: the numbered list of what will happen, in plain language and from the point of view of whoever asked, one line saying how many steps there are and how many change data, and the question — Yes, run or No.

Each line states the effect of the step, with the concrete data — "Creates the user ana@empresa.com with the analyst role" — never the name of an API. When Captain does not describe the step, the line uses the operation's own description, written by whoever built it; the technical verb and path only exist behind Show details.

When Captain assumed something or needs to flag a caveat (the workspace it picked for you, a part of the request that got no plan), that shows up in a note above the steps. The note is for caveats only: when there is nothing to say, it does not appear, and Captain's internal reasoning — why it chose that path — does not go there.

The technical detail of each step sits behind Show details, in the corner of the card:

If a step writes and is not covered by an automatic check, the summary warns you even with the details closed — not to alarm, but because in that case your confirmation is the only barrier, and you need to know that before saying yes.

When the plan creates a screen

If the plan will create a panel, the card shows the screen, not a description of it: title, where the data comes from, which columns, which filters, and the first real rows.

The reason is simple: "create the dossier panel" describes the action, not the result. Approving that sentence is approving blind — and the wrong panel sits in everyone's workspace until someone notices.

If the data sample cannot be loaded right then, the screen still appears with its layout plus a note explaining why. You decide on the design.

Permission: it does what you can do

Captain acts as you, never with elevated rights. What you cannot do through the screens, you cannot do through it either.

And the plan tells you beforehand: if a step requires a permission you lack, the card names it and offers no confirm button. You find out at planning time, not after half the changes have already landed.

It does not write code

This is a design choice, not a temporary limitation.

Captain uses the operations the platform already has. It discovers them on its own from DATTA's own code, so a new capability shows up for it at the next release without anyone teaching it.

What that means in practice:

• It creates panels, because a panel in DATTA is an artifact — something the platform knows how to create.
• It does not create hand-built screens. A bespoke screen comes from someone writing code, and that is outside what it does.

To write code inside a notebook, the right assistant is the notebook's own — it remains where it has always been.

After you confirm, it keeps working

Confirming a change does not end the request. Captain executes, reads the result and carries on: if something is still missing it continues; if another change comes up it shows a new card; when it is done it answers.

That holds when things go wrong too. An error from the destination service — "field tipo is required" — stopped ending the conversation: it reads the reason and tries another way, or explains what blocked it. Before, you were left with the error and nothing else.

When it finishes: request fulfilled, and where to check

Once the request is done, the card stops being called "Plan" and becomes Completed, with a ✓ on every step that ran. If any change was made, the Request fulfilled card appears below it, saying how many changes happened, and the How to check block: for each platform screen where the result lives, the menu path — System › Security › Users —, the clicks to get there and what to look for in the list ("Look for 'ana@empresa.com' in the list"). The Open screen button takes you straight there.

The path is derived from what the operation declares about itself, not guessed: an operation that does not say which screen it belongs to gets no "where to check" — better than a wrong path.

When the request was a question and nothing changed, the outcome is the answer itself, with no "fulfilled" card.

The conversation continues

When the Captain asks something ("which rule context should I use?", "what is the user's e-mail?"), just answer in the text box.

• The answer continues the same conversation. The Captain reads what you asked before, the plan it proposed and what it asked. There is no need to repeat the process number or the rest of the request.
• Previous exchanges stay visible above the current request, dimmed.
• A new message while a plan awaits confirmation replaces the plan: it is declined and the Captain builds another one from what you just said.
• While steps are running, wait for them to finish before sending another message.

At every end of the line (request fulfilled, question answered, plan declined or error) there is a New conversation button. It clears the screen, returns to the suggestions and makes the Captain forget what was said.

• In the floating widget, the button also sits in the header, next to close, while there is a conversation.
• Restarting with a plan still awaiting confirmation is the same as declining it: nothing runs.
• A conversation lasts up to 24 hours. After that the Captain opens a new one by itself, with no error on screen, and no longer remembers the previous messages.

What happens during execution

After you confirm, each step reports its outcome as soon as it finishes: done, or an explanation of what went wrong.

A failing step halts the plan. The remaining ones do not run, and that is deliberate: the next step usually depends on what the previous one would have produced, and running it would raise a second error that hides the first. The log shows what was completed up to that point — after a failure, that is the information that matters most.

If the connection drops midway, the log survives: reopen the session and it shows everything that already happened.

The log

Every session is recorded: what was asked, the plan proposed, whether it was confirmed or declined, each step with how long it took, and the outcome.

It serves two purposes. For you, it is the memory of what was done and by whom. For whoever looks after the platform, it is the evidence of where Captain stumbles often — and that turns into improvements to the platform itself, not to the agent.

That history is preserved when the platform's meaning-based search engine is replaced: older records are rewritten with the new engine instead of discarded. Without that, "has this been asked before?" would only answer about what happened after the change.

Platform administrators also get a per-operation summary: how many times each one ran, with what success rate and how long it took. In that summary, a request Captain declined is shown apart from a failure — a decline is an operation the platform does not know how to do yet, and a decline that repeats is a feature request with measured demand.

Attachments: what it reads

The attachment's extracted text goes to the model always, whatever the model.

When the chosen model sees images, the original file goes along with it — so a PDF that is mostly drawing (a data-model diagram, a screenshot) is actually read, instead of collapsing into the few lines of text extractable from it. Google Gemini sees images and PDFs. A vision model served by vLLM or Runpod (a Qwen-VL, for example) receives the image; of a PDF, it receives only the text.

A model that does not see gets the text only, as before — nothing breaks, and nothing is lost beyond what the picture showed.

A bare image (screenshot)

Besides documents, you can attach an image directly: .png, .jpg, .jpeg, .webp and .gif. It takes its own path — there is no text to extract from a screenshot, so what reaches the model is the image itself.

Two practical consequences:

• The extension must match the file. A .png that is really a JPEG is refused right away, with a message saying what to do. This is not red tape: the declared format travels with the image, and when the two disagree the provider rejects the whole turn — taking with it the text of your request, which would have worked on its own.
• If the model in use does not read images, the Captain says so in the plan itself, before you confirm. That is the difference from a document: a PDF still leaves its text behind, a screenshot leaves nothing. Without the warning you would confirm a plan believing it had considered what you showed.

Two limits, both degrading without failing the request:

• a file over 8 MB does not go as an image (its text still does);
• a format other than PDF, PNG, JPEG, WebP and GIF does not go as an image (its text still does).

Which model it uses

The Captain's model is chosen under System → DATTA Captain → Model, and applies to the whole platform. The list shows the models configured under System → AI, in groups: Google Gemini, vLLM (GPU), vLLM CPU and Runpod — the latter per endpoint, with the model each endpoint serves.

• The first option, "Use the chat model", makes the Captain follow the chat model of System → AI. It is what applies while nobody chooses another one.
• Models that do not suit the Captain show up disabled, with the reason: an embedding or rerank model, a context window below the platform minimum, or a server that is off. A model with an unknown window can be chosen, with a caveat.
• Below the list, the screen shows the model in use now and where it comes from (the Captain's own choice or the chat model). The System → AI tab shows the same.

Switching models takes effect within a minute — nothing needs restarting. If there is no model at all (neither a Captain choice nor a chat model), the Captain answers that no model is configured under System → AI, instead of using a model nobody chose.

Common questions

Can it delete something without my seeing it? No. Every change is in the plan, and the plan waits for your confirmation.

What if I ask for something the platform does not do? It says so, rather than inventing a path. A plan with an imagined step would be worse than no plan.

What if a detail is missing that only I know? It asks. Captain does not fill in an email, a name or a workspace with a plausible value — invented data is the kind of mistake that only surfaces later.

Can I adjust the plan? Answer "No" and ask again with more detail. A more specific request produces a more specific plan.