AI Agents

Many processes run through several systems. A request is read, details are looked up in the ERP and CRM, a decision is prepared, data is entered and a reply is written. Fixed automation hits its limits when the inputs look different every time.

We build AI agents for clearly bounded tasks. The agent works with only the permissions it needs, every step is logged, and where a mistake would be expensive, a person decides.

Most of the time a fixed workflow is enough

An AI agent pursues a goal and decides for itself which steps it takes. A language model plans, calls tools (a database query, an email, a posting in the ERP), evaluates the result and decides on the next step until the task is done. A chatbot, by contrast, only answers questions. Typical tasks for an agent are handling a customer request, including contract, order history, reply draft and ticket; researching a proposal from several sources; or reconciling master data between systems and suggesting corrections.

Even so, not every automation needs an agent, and we start with the simplest approach that solves the task. A fixed workflow always runs the same steps, is faster and cheaper, and is easier to test. It is enough when the steps can be written down as rules in advance, the inputs are structured and the result has to be the same every time. An agent is worth it only when the order depends on the content, the inputs are free text and there are many exceptions. A mix is often best: a fixed process as the frame, an AI step at the hard part, such as classifying or summarizing, and an agent only where freedom of decision is really needed.

Tools, MCP and other agents

An agent can only do what it has tools for. A tool is usually a function with a name, a description and parameters, with an API behind it, such as “look up order” or “create ticket”. The model uses the description to decide when to call which one. The more tools it can choose from, the more often it picks the wrong one.

The Model Context Protocol (MCP) is an open standard for this connection. Anthropic introduced it and handed it over to the Linux Foundation’s Agentic AI Foundation at the end of 2025. An MCP server provides tools and data, and any MCP-capable application can use them. The specification itself points out that tools can execute arbitrary code and that their descriptions should only be trusted if the server is. We therefore connect only vetted servers, keep read and write tools apart, and route write access through dedicated functions with validation.

The Agent2Agent protocol (A2A) is meant for agents from different teams or vendors. Google introduced it in 2025, it is now maintained by the Linux Foundation, and a stable version is available. Agents describe their capabilities in an Agent Card and accept tasks from other agents. So MCP connects an agent to tools, and A2A connects agents to each other. You need multiple agents less often than it sounds, because each additional one brings cost and sources of error. One agent with well-scoped tools is often enough.

For the platform, what matters is the existing cloud, identity management, data location and the team’s skills. Managed platforms from the large cloud providers take over some of the work, such as separate identities for agents, tracing and protection filters. Frameworks for custom code, such as LangGraph, give more control over the flow. The offerings change quickly, so we do not tie ourselves to one vendor.

What an agent must not decide alone

An agent acts in systems. It therefore needs rules that do not depend on the language model. We sort actions by risk: reading runs automatically, reversible changes run with spot checks. Payments, messages to customers and deletions are approved by a person who sees the draft, the reasoning and the sources.

The agent gets its own identity instead of a shared account and only the permissions its task requires. If it acts on behalf of a person, that person’s permissions are the upper limit. Input, tool calls, results and approvals are logged, which helps with troubleshooting and audits. A maximum number of steps, a time limit and a cost limit, plus an abort on uncertainty with handover to a person, keep an agent from wandering off.

Prompt injection, testing and cost

The biggest risk is prompt injection. Text in emails, documents or web pages can contain instructions that the agent takes for a task. It gets especially delicate when the agent may read internal data, process external content and act at the same time. This cannot be ruled out completely. We therefore treat inputs as untrusted, separate permissions and require approval for actions with external effect. Protection filters on the platforms help but do not replace these measures.

Testing happens before launch, on real cases including edge cases, with a definition of a good result agreed in advance. We check not only the answer but also whether the agent chose the right tools in a sensible order. Because language models do not answer the same way every time, the tests run again after every change to instructions, model or tools.

A task usually involves several model and tool calls, and the context grows with every step. We therefore measure cost per completed task and the share of cases a person has to rework, and compare both with today’s effort. Which obligations arise from the EU AI Act depends on the purpose; more on that in the topic of the same name.

Introducing it in stages

At first the agent only makes suggestions, and a person carries them out. In the second stage it carries out steps itself after approval. Only for low-risk cases does it work on its own, with spot checks. The stage changes only when the measured results support it.

Most projects never get that far. “Support sales” is not a process; an agent needs a narrowly defined task with a result that can be checked. If nobody can describe the process, no agent can run it reliably. An agent with an administrator account makes every mistake and every prompt injection more expensive. And a demo with three examples is convincing, while operation with real inputs often is not.