Autonomous AI Agents (RAG)
Required Access Level
Admin or Super Admin
How far an agent may call
An agent that uses the HTTP call tool should declare its allowed hosts in the agent form, one per line:
erp.customer.com
*.partner.com*.partner.com reaches api.partner.com and does not reach partner.com. The port is ignored in the comparison.
Why this exists: the agent uses a credential without seeing it (see Tenant Variables), but with no list it could send that credential to any external address it composed. Agents read supplier documents, CMS records and knowledge bases — content from outside — and a model steered by that content can compose the wrong request. The list bounds the reach.
New installation: AI_HTTP_TOOL_DEFAULT_POLICY=deny
With allow (the default, for compatibility) an agent with no list calls any external address. With deny, an agent with no list makes no outbound call at all, and each agent that needs the network says where. Internal network addresses stay blocked either way.
The other half of the same control belongs to Webhooks: there the list is the tenant's and not the webhook's, because the webhook is the destination. Same host format, same wildcard, same refusal.
What are AI Agents?
An AI Agent is a record holding what the platform needs in order to call a language model inside a step: which model from the catalogue, at what temperature, under which system prompt, and with which tools by default. A classic Robot runs a JAR with programmed logic; the agent takes text in — the attached document, whatever earlier steps wrote, the passages retrieved from the knowledge bases — and gives text back, which the platform writes into the step's result variable.
Three limits worth knowing before you model anything:
- The diagram decides the path, not the agent. It writes the variable; the gateway (in a process) or the entry condition (in a case) is what reads that variable and picks the next step.
- When it fails, the step fails. An empty answer, a tool that could not run, or a blocking issue raised by the agent all stop the step with the cause written down — the platform does not leave the variable blank and carry on.
- Every call is billed, including the one that got you nothing. The provider charges for the prompt it processed. Empty answers, provider errors and blocking issues all land in the tenant's consumption in AI Governance like any successful call.
Typical uses: auditing an invoice, reviewing a legal filing, triaging a support ticket, classifying an attached document.
BYOK (Bring Your Own Key) Strategy
Flowi Agentic is self-hosted software: the platform charges no markup on token consumption. The model provider (OpenAI, Google, Anthropic) invoices whoever registered the credential, directly.
The key belongs to the installation, not to each tenant. The Super Admin registers it once, in the model catalogue — there is no screen where a tenant administrator supplies a key of their own. In practice the organisation running the installation receives the provider's invoice and uses AI Governance to see how much each tenant consumed and to charge it back.
Where the model and the key are registered
Provider and API key are not on the agent. They live in the model catalogue, under Global (Super Admin) → AI Settings, where each model is registered once with its provider, credential and base URL. The agent only picks a model from that catalogue.
The separation is deliberate: the credential belongs to the platform and to whoever answers for it, and creating an agent should not ask someone to paste an API key again — nor multiply the number of places where it exists.
Editing a model does not ask for the key again. On edit the API Key field comes back empty and whatever is stored is kept; fill it in only when the intention is to replace the credential.
A model in use is neither deleted nor deactivated
If any agent points at the model, the platform refuses both the removal and the deactivation, saying how many agents depend on it. It guards against silent damage: deleting the model unbinds it in the database, and every one of those agents starts failing on every call with nothing on the agent screen saying what changed. Point those agents at another model first.
Gemini reasoning models
Gemini models take a thinking budget of their own, set on the catalogue entry:
| Value | What happens |
|---|---|
| empty | uses the platform default (AI_GOOGLE_THINKING_BUDGET, today 0) |
-1 | the field is not sent and the model decides — what the pro family requires |
0 | reasoning off, which is how the flash models already run |
> 0 | an explicit ceiling of reasoning tokens |
The field exists because 0 is valid for flash and invalid for pro: registered with the platform default, a gemini-pro-latest answers 400 on every call. Leave -1 on those models and touch nothing else — the default stays exactly what the flash models were already getting.
Reasoning is billed tokens
Reasoning tokens count towards the tenant's consumption like any other. A high budget shows up in AI Governance as a higher cost per call.
Configuring the Agent
Agents belong to a process. There is no global agents screen: you register them inside the definition, under Process Catalog → the process → AI Agents tab. This is structural rather than menu organisation — every agent carries the key of the process it serves, which is what lets one process have several agents, each with its own system prompt, model and temperature.
In the form:
- Agent Name and Description — the description is optional and serves whoever maintains the process later.
- AI Model — chosen from the catalogue described above.
- Temperature (0 to 2.0) — how much freedom the answers have. For a process,
0.0or0.1, because what you want is the same input producing the same output. - AI Tools (System Tools) — read an attachment, search the knowledge base, query a CMS collection, and so on. This list is the default for steps that declare none of their own: every step of the process can pick its own tools, and that is where the decision usually belongs — see What belongs to the agent and what belongs to the step.
- System Prompt — who the agent is and the rules it applies. E.g., "You are a senior financial analyst, always reject proposals submitted on weekends."
A step points at its agent through the aiAgentId field on the Service Task, so different steps of the same process — or of the same case — can use different agents.
RAG Integration (Knowledge Bases)
Artificial Intelligence is much more powerful when paired with RAG (Retrieval-Augmented Generation). In Flowi Agentic, this is managed through the Knowledge Bases module:
- Base Management: Go to Content → Knowledge Bases in the sidebar. You can create global bases (available system-wide) or tenant-specific bases.
- Workflow Linking: Knowledge base content (rules, policy manuals, guides) is not blindly injected. When designing a process (Workflow), go to the RAG tab and explicitly select which Knowledge Bases the process is permitted to access.
- Rule Injection (System Prompt): The moment an AI step fires, in a process or in a case, the engine fetches the descriptions of the linked Knowledge Bases and automatically injects the rules into the System Prompt. The process link says which bases are within reach; each step can narrow that set — see Knowledge bases for this step.
- Documents (Vector Search): Attached files (PDF manuals, text sheets) are chunked and converted into vector embeddings using
pgvector. During execution, the semantic content most similar to the current task variables is passed as supplementary context. This data never trains the public LLM.
Retrieval returns three passages, not the whole base
Each query against the vector store returns three passages, however many bases are within the step's reach and however many documents they hold. There is no per-base quota: the three slots go to whichever passages are closest to the question, wherever they live.
That changes what to expect from loading more content. Loading more does not increase how much context reaches the model — it increases the chance the three passages are the right ones. A question spanning three subjects will not get them in one search; the agent has to ask once per subject, and it only does that if the System Prompt says so.
Two instructions worth giving any agent that reads a large base: one question per subject, since three narrow queries return nine pertinent passages where one broad query returns three generic ones; and the distinguishing term inside the question, because retrieval is text similarity and does not filter on metadata.
Using AI Agents in Workflows
Once your Agent is configured (e.g., "Auditing Agent"), process architects (SUPER_ADMIN users) can use this agent by creating a Service Task and choosing ✨ AI agent as its implementation. This works on both engines: in a BPMN process and, now, inside a CMMN case as well.
The Delegate will automatically gather dynamic variables from previous user form steps, concatenate them with linked Knowledge Bases rules, and send the request to the cognitive agent in real time.
Inside a case the agent writes a variable — the model decides
A case has no arrows. An AI step inside a case does not open the next step: it writes the result variable, and what opens is decided by the entry condition (sentry) that reads it. That is what keeps the reason a task opened visible in the diagram, instead of buried in a call nobody reviews afterwards.
A condition that reads the AI's answer must tolerate its absence
The result variable does not exist until the agent finishes, and the engine evaluates the condition before that. Writing ${documentosConformes == 'false'} brings the case down with Unknown property used in expression. The form that works uses Flowable's variable function: ${var:equals(documentosConformes, 'false')}.
This holds for every AI-driven condition, without exception — it is not an optimisation, it is the only form that runs.
Before an AI step existed inside a case, the only way out was for the case to call a one-step BPMN sub-process (Process Task). That still works and was not deprecated: it is the right shape when the AI part is a whole flow rather than a single call.
The fields of the Service Task
The task carries five fields, declared in the modeler — the same ones on both engines:
| Field | What it is |
|---|---|
aiAgentId | Which agent runs the task |
aiInstruction | What it must do at this step |
aiResultVariable | Which variable receives the answer (default: aiResponse) |
aiTools | Which tools this step offers the agent |
aiKnowledgeBases | Which knowledge bases this step leaves within reach |
The agent can ask what the process already decided
Among the available tools there is Learned Pattern Lookup (consultarPadroesTool). Enabled on a step, it lets the agent ask what this process historically decided there — and the answer carries the exact frequency: "tipoDocumento = NFS-e in 692 of 692 cases, when tipoDoc=NFSE".
The platform tells the agent the step has patterns, but does not inject them: whether it is worth asking is the agent's call. That is deliberate — pushing the majority value into the prompt would bias the agent precisely on the cases where the document is the exception, which in an audit are the ones that matter.
Where there has been enough exposure, the answer also carries how often people accepted that suggestion — the same figure as the Learning health table, on the same threshold. It is what lets the agent discount a frequent pattern users have been refusing.
The tool is read-only and honours the same exclusions as learning: a personal field, or one on the process's exclusion list, never appears — even if the agent asks for it by name. It is capped too: five queries per run of the step, and at most ten patterns per answer — past the cap the tool refuses instead of answering on, so that an agent in a loop does not turn into cost.
The first three are enough for a task to run. The last two are the step's scope, covered in What belongs to the agent and what belongs to the step — left blank, the step inherits the default.
Each field can be written in two ways, and the choice changes the outcome:
- Text (
string) — the value reaches the agent exactly as written. Use it when the instruction does not depend on anything that happened earlier in the process. - Expression (
expression) — the value is computed at execution time. This is how an instruction receives data that only exists during the instance:Analyse invoice ${execution.getVariable('arquivoNota')}.
If the instruction has to quote something filled in at an earlier step, it must be an expression. Written as text, the agent would receive the literal ${...} and answer about a placeholder — the call is billed, an answer comes back, and it is not about your document.
The five fields can also come from process variables of the same name. A variable takes precedence over what the diagram declares, and it applies to the whole instance — if the process has two AI tasks, both start using the same instruction, and the same goes for the tool and knowledge scope. It works for a one-off; it does not work as a design. The rule is the same inside a case: what differs between the two engines is where the field is written, never how it is read.
Do not mark the agent's step as asynchronous
Leave Run in the background unchecked, on both engines.
The box buys nothing: since 2026-09-09 (processes) and 2026-09-10 (cases), the AI step already steps out of the execution queue on its own as soon as it starts. It reserves the work, gives the turn back, and the platform resumes it when the model answers — whoever started the process is not left waiting on the provider, and no database connection is held during that gap.
Checking the box only adds one more queued item per step, to move a wait that is no longer there. In a process it also pushes the step into the same short queue that serves timers and resumptions — which is precisely what this change exists to free up.
A process published before this version keeps the old behaviour, calling the provider on the spot and making whoever started it wait. To move it: open the task in the modeller, pick ✨ AI Agent again in the implementation field, and republish. In a case there is nothing to do — the change applies to everyone as soon as the version is up.
When the agent does not answer
If the model returns an empty response, the task fails and the instance moves to the With error status. It does not carry on with a blank result variable.
This is deliberate. Were the empty value written and the process allowed to carry on, the next human task would open with a blank field, and there would be no way to tell "the agent analysed it and found nothing to report" from "the agent never answered". In a process that audits fiscal documents, the defect would reach the reviewer looking like a result.
By failing, the instance shows up in the failed-instance list with a message naming the variable that was left unanswered and the finish reason reported by the AI provider — which is what separates a content block, a quota overrun and a genuinely empty answer.
There is one case where the empty answer never becomes an answer at all: the provider returns the call with no candidate, and the conversion fails first. The message now says exactly that, naming provider and model. It is the same empty-response defect seen from the other side — it does not mean a stale catalogue, and it does not call for restarting the application.
An infrastructure administrator can invert this behaviour with the AI_FAIL_ON_EMPTY_RESPONSE=false environment variable, leaving the result variable blank instead of failing the task. The default is to fail.
How many times the step insists with the provider
Not every failure deserves a second call, because the second call is billed just like the first. The platform separates the two halves of the step:
- Before the answer — the provider returned nothing. Repeating means calling the model again and paying again. This is where the step's attempt limit applies, and it is 2 unless the step says otherwise.
- After the answer — the model answered and the failure happened while writing the result. The answer is already stored as a process variable, so finishing the step costs nothing and has no limit: the platform repeats only the completion, never touching the provider.
Within the paid half, the limit is spent only on failures that could plausibly succeed next time:
| Provider failure | Retried |
|---|---|
| Timeout | yes |
| Provider error (5xx) | yes |
| Connection lost / network | yes |
| 401 / 403 — rejected credentials | no |
| Quota exhausted at the provider | no |
| Refused content | no |
| Malformed request | no |
A failure from the no column ends the step on the first attempt even with the limit untouched, and the reason — with the code the provider returned — reaches the Failed instance list. Insisting there would mean paying again to fail identically.
The limit belongs to the step, not to the process. Two AI steps in the same process do not deserve the same number: a short classification against a cheap model can afford to insist, a long generation against an expensive model may deserve no retry at all. Because the value lives in the process design, changing it means republishing — it is a design decision, not an on-call switch.
Where it is configured. In the modeler, select the Service Task that uses ✨ AI agent and look for the Attempts with the provider field, right below the Return Variable, in the same block where you pick the agent and write the instruction. Leaving it blank is the normal case: the step uses the default of 2. Type a number only when this particular step deserves different treatment, and republish the process for the new value to take effect — an instance already running keeps the limit it was born with.
In a case the field is the same. In the CMMN modeler, select the task that uses ✨ AI agent and the Attempts with the provider field sits in the same place, right below the Return variable, with the same range and the same default. What differs is what happens once the limit runs out: in a process the step becomes a dead-letter item with a retry button; in a case the plan item stays active and the failure shows up only in the With errors list — the case stays open and nobody has to reopen it.
The field accepts 1 to 10. 1 means one call and no insisting — that is what you write for a long generation against an expensive model. Type a number outside that range and the screen brings it back to the nearest allowed one as soon as you leave the field; text that is not a number simply disappears, leaving the step on the default. Whatever stays written there is what will run.
The ceiling of 10 belongs to the installation and applies to every step: even if a hand-published XML asks for more, the platform never calls the provider more than ten times in one step.
Reading process attachments
When the agent has the attachment-reading tool enabled, it can read the instance's file without knowing its identifier. If the process has a single attachment, the tool reads it and tells the agent which file it read. If there are several, it returns the list of names for the agent to choose from — it never guesses on the agent's behalf.
Images and PDFs are attached to the message; everything else the agent reads through the tool. Models accept images and PDFs directly, so those two travel as files. Any other format — XML, JSON, CSV, text — is not sent as a file: the message carries its name and identifier, and the agent uses the tool to read the content. Write the System Prompt accordingly, because an agent told not to call the tool simply never sees the document.
Text formats arrive as they are, with their structure intact. XML and JSON do not go through text extraction — if they did, field names and attributes would disappear and the agent would receive a column of values with nothing saying what each one is. PDF, DOCX and images still go through the extractor, which is what it is for.
A document is capped at 100,000 characters, configurable through AI_ATTACHMENT_MAX_CHARS. Beyond that the tool truncates and says so in the text it returns, giving the document's length and how much arrived. Instruct the agent to repeat that notice in its answer: analysis of a partial document is partial analysis, and whoever reads the result needs to know the difference.
When a tool fails, the task fails
A tool can return two very different things, and the platform treats each one differently.
Answers go to the agent as text, because it can act on them: the collection does not exist, no record matched the filter, the process has no attachment, the process has several attachments and here is the list, the filter you sent is malformed.
Failures do not. If the tool could not run — database down, storage unavailable, extraction broken — the AI task fails, no result is written to any variable, and the instance appears in the With error list of instances, with its cause. The call already sent to the provider lands in the consumption report as a zero-token call: the spend happened and could not be measured, which is how AI Governance records it.
The difference matters because the agent cannot tell a broken tool from an empty result. Hand it the failure as text and it writes something plausible — "the document did not arrive" — and that text becomes the step's result, is read by the next step, and reaches a human looking exactly like any successful task. A fluent audit about nothing is worse than a failed task, because a failed task is something someone fixes.
The rule is about whose problem it is, not how severe it is: a badly written filter is the agent's mistake and goes back for it to correct; a database outage is the platform's and stops the process.
When the input never arrived: three options, and how to choose
A broken tool is one case. The other, far more common, is the input never arriving: the invoice nobody attached, the period the previous step failed to fill in. With nothing checking, the agent honestly answers "the file was not received", that sentence is stored as if it were the transcription, and the next step audits the sentence. The reviewer opens a task identical to every successful one.
There are three ways to prevent this, and they do not compete — they cover different things.
| Option | What it catches | What it costs |
|---|---|---|
| Gateway before the step | the variable is empty, and there is a business path for that | edit the diagram; nothing else |
| Required-variables listener | the variable is empty or points at a missing attachment, and that is a modelling error | one line in the step's listener panel |
| Blocking-issue tool | the file arrived and is unusable — unreadable, wrong type, contradictory | grant the tool to the agent; optionally an error boundary event |
Use the gateway when a missing document is normal and someone can fix it. An exclusive gateway before the AI step, testing ${empty arquivoNota}, routes to a human task that asks for the file. The check lives in the drawing — anyone who opens the process sees that the case was considered.
Use the listener when the variable should always be there. In the step's listener panel, add an execution listener on the start event, of type Expression, with:
${requiredVariables.check(execution, 'arquivoNota,competencia')}It stops the activity before any call to the model — so it spends no tokens at all — when any of the variables is absent, blank, or an attachment id that no longer resolves. That last case is the deceptive one: the variable is populated, with a perfectly shaped UUID, and it is the file behind it that is gone.
The listener is not an AI capability. It works the same on a robot task, an HTTP call or a DMN decision — it is an ordinary BPMN extension point, which is why it exists instead of a field of its own on the AI step.
It stops the instance rather than routing it: absence here means the process was modelled or integrated wrongly, and there is no sensible path for "the previous step did not produce what it promised". If there is a path, the gateway is the right instrument.
Use the blocking-issue tool for what only the model can judge. The file is there and it is unreadable; it is a service invoice where a goods invoice was expected; two attachments contradict each other. No gateway and no listener see any of that, because both only know whether the variable exists.
Turn on Let this agent stop the process with a blocking issue on the agent form. It is off by default: an agent that must never abort a process simply does not receive the tool, like every other capability.
The agent's switch is the default, not a ceiling. Like any tool, a step that declares its own list under Tools for this step may include the blocking issue even with the switch off — and a step that declares its own list without it takes the blocking issue away from an agent that has it. Whoever edits the diagram owns that decision.
Once granted, the agent ends the step reporting a short, stable code (DOCUMENTO_AUSENTE, DOCUMENTO_ILEGIVEL, TIPO_NAO_SUPORTADO) and a one-sentence reason. Then:
- the result variable is not written — no prose takes the place of the data;
- the process receives a business error carrying that code. Attach an error boundary event with the same code to the Service Task and route to a human task, a compensation or a notification;
- the failure record keeps the code where an exception name would be. It does not show on the AI Governance screen, which only reports quota and consumption: today the rate of each code is read from the AI failure list through the API (
GET /a/ai-task-failures), or asked of the execution copilot; - with no boundary event, the instance stops with a named cause. Handling every code is not required.
Three consequences are worth saying out loud.
With a boundary event, the engine does not retry the blocking issue. A business error is a control-flow signal, not a fault: re-analysing an absent document three times changes nothing and bills three times. A transient failure — provider outage, broken tool — stays an ordinary failure, which the engine does retry.
With no boundary event and the step made asynchronous, the engine retries — and bills again
This is the combination to avoid. With nobody catching the code, the engine treats the blocking issue as any other fault; if the step is ticked Run in the background, it retries until the dead letter queue, and every attempt is a fresh call to the provider. The shortcut that keeps a step from being paid for twice relies on the result variable being filled in — and a blocking issue is precisely the case where it is not.
Two defences, and the first is already this page's general advice: leave Run in the background unticked; and, for every code the agent can raise, either have a boundary event or accept that the instance stops there.
A blocking issue consumes quota. The model was called, read the document and concluded it cannot be done: the token was burned at the provider and appears in the tenant's usage report, even though the step ended in error. Quota measures spend at the provider, not results you got to keep.
In a case (CMMN) a blocking issue does not route. The AI step of a case records the same code and likewise does not write the result variable — the entry condition that depended on it never opens — but CMMN has no error boundary event: to the engine that is an ordinary fault, with the retry and the re-billing described above. Until that changes, a blocking issue with a designed detour is a BPMN-process feature.
One agent per domain
Nothing forces a process to use a single agent. The agent is a field of the Service Task (aiAgentId), read on every execution — each step of the flow can point to a different agent, with its own system prompt, model and temperature. A process that uses the same agent from start to finish does so because it was designed that way, not because the platform requires it.
The difference shows when you measure the prompt. An agent that serves every step has to cover every step, and its prompt grows by addition: the shared discipline, plus each domain's vocabulary, plus the catalogue of what is available to consult.
Split that text by subject and the pattern appears. The part that serves any step — who the agent is, how it reasons, what counts as a result — is usually the smallest. The rest is tied to one domain or one corpus, and in a flow with separate tracks an instance walks only one of them: the other domain's vocabulary crosses every call without ever being used.
And that text is not sent once. It travels with every call the process makes — four calls, four copies, byte for byte identical.
The grouping is by domain, not by step
The immediate reaction to that number is usually to push the specific text down into each step's instruction (aiInstruction) and keep the agent lean. It does not hold: the NF-e block serves three NF-e steps, and pushing it down means writing the same text in three places. On the first rate change someone updates two and forgets the third — and the three steps start auditing under different rules, with nothing in the platform flagging the divergence, because to it they are three unrelated free-text fields.
The cut that holds is by domain: an "NF-e Auditor" agent and an "NFS-e Auditor" agent, each carrying the common discipline plus its own tax block, and each Service Task pointing at the agent of its track. The ICMS text keeps existing in exactly one place, and the NFS-e step stops receiving it. Agents are registered per process and coexist inside the same process: creating the second one is the same work as creating the first, and which one runs is decided step by step.
What belongs in the agent prompt and what belongs in the step instruction
The split is this: the agent prompt holds what is common to the domain — vocabulary, hierarchy of norms, how to query the base, what the base does not cover, how firmly to assert something. The step instruction holds what is specific to that activity — what to analyse now, in what format to answer, what the next step expects to receive.
A step instruction that repeats a domain rule is duplication waiting to diverge. An agent prompt that describes one specific activity travels along to every other step of the domain, taking up room and competing with the instruction that actually applies to that call.
Tools and knowledge bases follow the same split, by field rather than by text: both are declared on the step, and they are what the rest of this section is about.
An available tool is a used tool
The model decides whether to call a tool, call by call. The design does not control whether it gets used; it controls only whether it exists on that call — and that is what turns the tool list into a cost decision, not only a quality one.
The typical case is a consolidation step: everything the earlier steps produced already reaches it as process variables, and all it has to do is put them together. Leave attachment reading available and some fraction of runs will re-read the whole document — the model has two sources for the same value and no reason to prefer one. A call that re-reads costs several times one that does not, and nobody decided the difference.
Asking in the instruction not to re-read helps, but it remains a request. Leaving the tool out of the step is what makes re-reading impossible.
An available base is a used base
The same holds for the corpus, and there the price is not tokens.
A step that consolidates opinions with the legislation within reach can raise a finding no earlier step raised — and support it, because the norm is at hand. The result looks rigorous: it cites an article, concludes, closes. Except the step was not designed to audit; it was designed to assemble what had already been audited.
Both are the same mechanic: the model helps itself to whatever is within reach, and reach is decided before the call goes out. That is why a step's scope is enforced rather than requested — the platform assembles the call with the tools and bases the step declared, and what was left out is not there to be used.
What belongs to the agent and what belongs to the step
The agent is who it is: the role it plays, the discipline it reasons with, the model it runs and the temperature. The step is what it does: the action of that activity, the tools it needs and the bases it consults.
The distinction is practical. While tools and bases lived on the agent, the agent's prompt had to anticipate every possible action of every step that might use it, and the only way to take a tool away from one step was to create a whole agent for that — an agent existing for a reason that has nothing to do with the role it plays.
Tools for this step (aiTools)
In the modeller, select the Service Task (or the listener), pick the agent, and use Tools for this step.
The agent's list is the default, not a ceiling: a step that declares nothing runs with the agent's tools, and a step that declares goes by its own list instead. The selector shows the agent's tools as the ready choices, but the step is not limited to them: any valid platform tool can be declared. Whoever designs the process knows what the step needs in order to work, and whoever edits a diagram is already a tenant administrator — separating those two decisions would separate what belongs to the same person.
For the final opinion, simply leave attachment reading out of that step. Re-reading becomes impossible rather than merely discouraged.
What the step does not decide is reach into confidential data. The CMS confidentiality level stays with the agent (see Large tables and AI agent lookups), and that is deliberate: a tool is an action, confidentiality is reach. Should a modeller role that is not an administrator ever exist, whoever draws the diagram still will not be able to grant the agent access to content they cannot read themselves.
A tool name that does not exist on the platform is refused before the call goes out, with a message naming what failed to resolve. A broken tool sitting in the agent's default but not used by the step does not bring the step down — only the step that asks for it is refused.
Knowledge bases for this step (aiKnowledgeBases)
Same syntax, different reach: the step chooses among the bases the process links. Declaring nothing inherits every base of the process; a list leaves exactly the ones listed; none leaves the step with no base at all — neither the descriptions injected into the System Prompt nor the passages those bases would contribute to vector search.
A base declared that the process does not link is refused, not ignored, and the error message lists the bases the process reaches. Silently dropping it would run the step with less context than its designer asked for, and the output would come out looking like a normal result.
The none marker
It works on both fields and means the same thing on both: none at this step. It exists because an empty field and an absent field reach the engine identically, and not configured has to be distinguishable from configured to nothing.
The marker tolerates case and surrounding spaces (NONE, none), and is refused when it comes alongside a real item — none, searchKnowledgeBaseTool does not say whether the step wanted everything or nothing, and guessing would be choosing on the designer's behalf.
In the properties panel both fields appear as soon as an agent is selected: a multiple selector and, below it, a No tools in this step / No knowledge base in this step checkbox, kept separate from an empty selection precisely so the difference shows on screen.
Injected context and tools are not the same thing
They are two ways for the agent to reach information, and they fail differently.
Injected context is material that enters the prompt before the model thinks: the descriptions of the linked bases, the passages retrieved by vector search, the attached document. The model helps itself to all of it, and nothing in the text separates "this is reference" from "this is the case under analysis". In one measured batch, an opinion quoted the municipality from a reference table as if it were the invoice's municipality: the value was in the prompt, it was plausible, and the model used it.
A tool is a question and an answer. The model asks, receives what it asked for, and what comes back arrives identified as the result of a query. It costs one extra round trip and brings less text back.
For design the consequence is practical: large reference material — code tables, registries, rate lists — is safer behind a tool than injected next to the document. And the more the injected material resembles the document under analysis (same fields, same formats, same numbers), the higher the chance one becomes the other in the answer.
Self-learning
Self-learning is configured per process, not per agent: a process running several agents has one configuration shared by all of them, and the agent form carries no learning field at all. The tab lives under Modeling → Process Catalog, and is documented in Process Catalog → Self-learning.
The patterns that counting produces feed two places, with the same number in both: the form's autofill and the execution copilot, which answers what is usually filled in on a step by quoting "in 641 of 645 comparable cases". Switching self-learning off for a process removes both: the copilot keeps answering about the process and the instance, but starts saying it has no history for that field — never estimating one. What the copilot receives is described in Tasks → What the copilot knows about the open task.