Agentic AI

AI agents can add powerful capabilities to your application, but they are not predictable in the way the rest of your application is. A model can be wrong, and a model can be talked into being wrong. Treat an agent as a component that needs guardrails, monitoring and review, not as a component you configure once and then trust.

For using Agentic AI in the WEM Runtime, you need to have a valid account for the chosen Provider To use agentic AI in the WEM Runtime you need a valid account with the provider whose model you select. Credentials are configured per portal and per environment in the DevOps portal, and the required settings differ per provider.

If your project runs on a WEM Shared Runtime (WestEurope or US), raise a ticket with WEM Support to have the configuration applied. See Agent configuration for more information.

Introduction to AI in the Modeler

Agentic AI in the WEM Modeler lets you add AI agents to your application as a modelled resource, alongside your data model, flowcharts and templates. An agent can interpret user input, summarise or classify content, answer questions from a knowledge base you supply, and call functions that you modelled yourself.

AI agents can analyse customer inquiries, summarize large datasets, create documents or execute business rules based on contextual understanding. They may improve user interactions, automate repetitive processes, and enhance decision-making, offering powerful capabilities that seamlessly integrate into your applications.

What an agent cannot do is act on its own authority. In WEM an agent is a step inside a workflow that you designed. It reasons about what should happen next and asks the platform to carry it out; the platform decides whether that is allowed. That distinction runs through everything in this section, and it is the reason agentic AI can be used in processes where the outcome actually matters.

AI and agentic AI in WEM

Agentic AI describes AI systems that do not only generate responses, the way ChatGPT and similar tools do, but also take action within a scope you define. An agent keeps track of a conversation, can call functions you modelled, and can reach external systems through them, which lets it handle work that goes beyond simple input and output.

In WEM that scope is the feature, not a limitation. An agent that can reach anything and act on anything is only usable where being wrong is cheap, which rules out most of the work worth automating. Because a WEM agent is scoped, you can point it at a process with real consequences and still explain afterwards exactly what it did. The principle in one line: the agent reasons, the platform decides.

Each aspect of an agent's setup closes off a category of unintended behaviour:

• One job, described in its Instruction: small, specific agents behave more predictably and cost less than one agent that does everything.

• Only the knowledge you hand it: file sources and conversation context define what the agent can draw on. The rest of your data model stays invisible to it.

• Only the actions you assign: the agent chooses which function to call, never what that function does, because the function is a flowchart you modelled with your own validation inside it.

• Its own conversation per user: one user can never reach another's history.

• A record of what happened: conversations and their messages, including function calls, are persisted.

Capabilities

What agents can do in a WEM application

Agents are a good fit for work that needs interpretation rather than a rule you could have written yourself. Common patterns:

• Conversational support: answering questions from your own documentation or policies, and escalating what it cannot answer.

• Intake and triage: turning an unstructured request into structured fields, classifying it, and routing it.

• Summarising and extracting: condensing case notes, correspondence or uploaded documents, and pulling specific values out of them.

• Acting on request: invoking a function you modelled, so a conversation can create a record, start a process or send something.

Three ways to reach an agent

The same agent can be reached in three different ways, and choosing between them is usually the first design decision you make.

Style	How it works	Use when
Text	The AI agent chatbox component on a page. The user types, the agent replies, and the conversation history is visible.	The user should see and steer the conversation.
Voice	The AI agent voice chat component on a page. The user speaks and the agent answers out loud, in real time.	Hands are busy, typing is impractical, or a spoken conversation is simply the natural interface.
Headless	Flowchart nodes only, with no component on any page. Your application prompts the agent and uses the response.	There is no user present, or the user should not be aware of the agent at all.

Voice is a property of the model, not just a different component. Only models that support the voice conversation mode can be used for spoken conversations, so you decide between text and voice when you pick the model for the agent, not when you build the page. Changing the conversation mode later means re-creating the agent.

All three styles work against the same agent definition, the same conversation and the same functions. You can also combine them: a background invocation can run against a conversation that a supervisor is watching in a read-only chatbox.

Providers and models

WEM does not host models. You choose a provider, WEM then connects it with the credentials configured for a specific portal and environment, and you pay that provider for the tokens you use.

The models available to you update automatically with the provider you select, and each model carries information about what it can do: context size, whether it supports reasoning, which file types it accepts, which hosted tools it offers, whether it can hold a voice conversation, and where it sits in its own lifecycle.

Model choice is a real design decision, not a detail. It sets your cost per conversation, your response time, and which of the capabilities above are available at all.

Risks, tips and tricks

Risks

• Prompt injection: user input, and text inside documents and data the agent reads, can contain instructions aimed at the agent. Assume it will eventually be talked into something it should have refused, and design so that this is survivable.

• Data privacy and security: what you put in an instruction, a file source or a payload leaves your Runtime and goes to the provider. Know what you are sending and under which agreement.

• Bias and fairness: models inherit bias from their training data. This matters most in decisions about people.

• Performance impact: agents introduce latency, and a slow model call in a synchronous flow is a slow page for the user. Use async tasks to mitigate this and allow users to continue there work while a response is created.

• Unpredictable cost: you pay per token, and token use scales with conversation length, attached files and reasoning, not with the number of users.

• Unpredictable behaviour: the same prompt can produce different answers. Anything that has to be exact should not be left to the model.

• Model lifecycle: models are retired by their providers. An agent that works today can stop working, and behaviour can shift under you if you are not pinned to a version.

Guardrails and best practices

• Limit autonomy: give an agent the smallest possible job and the smallest possible set of functions. Compartmentalise into several small agents rather than building one that can do everything.

• Write the instruction as a boundary, not just a description: state what the agent must not do and must not discuss, as well as what it is for. An agent knows which functions it has; instruct it not to share that with users.

• Keep prompts static where the stakes are high: the Invoke agent node sends a prompt you wrote, not text the user typed, which removes the most direct injection route. Use it when the application drives the agent.

• Validate in the flowchart, not in the prompt: put your rules in the function's flowchart, where they run every time regardless of what the agent was persuaded to ask for.

• Do not make users wait: run agent calls asynchronously, or in an Async Task, so a slow provider response does not block the interface.

• Keep it transparent: document which agents exist and what each is for. During development, the chatbox can show function calls, reasoning and system messages, which makes debugging much easier. Turn that off before it reaches end users.

• Monitor and audit: Include logging into function flows and create audit processes to keep an eye on what your agents do and which functions they call. Include the agents reasoning evaluations into these logs so you can create insights into why an agent behaves the way it does.

• Test adversarially, not just functionally: try to break your own agent before someone else does. Gandalf is a good way to build intuition for how little it takes.

• Review real conversations: conversations are persisted. Read them, particularly early on. It is the fastest way to find out that your instruction says something other than what you meant.

Where to go next

• WEM agentic AI: creating an agent, configuring its instruction, options, knowledge and functions, and setting up providers in the DevOps portal.

• Agent configuration: information on what is needed

• AI flowcharts and functions: the AI agent conversation node, agent function flowcharts, and the AI expression functions.

• AI user interaction: the chatbox, the voice chat component, and driving an agent with no interface at all.

• How to example: Dive into a showcase guide on how we implemented agentic ai for a towing company, handling their contracts, towing requests, dispatch and audit & compliance through agents in WEM.