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.

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.

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.

The plan card

Each step carries three pieces of information:

Steps that modify something are marked. If one of them writes and is not covered by an automatic check, the card highlights it — not to alarm, but because an unguarded change deserves a second look before you hit confirm.

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.

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. Today the one that sees is Google Gemini.

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 uses its own model, chosen under Settings → AI → DATTA Captain model — deliberately separate from the chat model. The chat converses; the Captain reads API contracts and assembles the call, and a mistake there is a wrong request, not a poor sentence. Changing one does not change the other.

The combo lists Google Gemini models and, when a Runpod endpoint is active, the models it serves. Embedding and rerank models do not appear: they do not answer a planning request, and picking one would leave the Captain silent.

With nothing chosen, Gemini 2.5 Pro applies. Switching models takes effect on the next request — nothing needs restarting.

To run it on a Runpod model instead — a vision model, say, which is better at reading diagrams — go to Settings → AI → Runpod → Endpoint dedicated to the DATTA Captain. There you can pick an existing endpoint or create one just for it: the creation form asks who will use the endpoint, and choosing the Captain makes it dedicated — it does not appear in chat.

"Undo dedication" returns the Captain to Gemini at any time.

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? Decline and ask again with more detail. A more specific request produces a more specific plan.