An assistant that finds knowledge is half the job. An agent creates the ticket, starts the workflow and writes the result back into the system - with clear limits, logging and approvals where it matters.
Tickets, scheduling, data queries, workflow triggers - the agent uses your existing APIs and systems (Zammad, n8n, ERP, CRM).
Allowed actions are explicitly defined, critical steps require human approval, and every action is logged - traceable by ID.
Built on the open stack (LiteLLM, Langfuse, your APIs), operated by us, in an EU cloud or on your hardware. The agent belongs to you.
The common pattern: requests arrive unstructured, a human sorts them, and the actual task is the same repeated action in another system.
Trigger: An email describes a problem in the sender's own words.
Agent: The agent classifies it, creates the ticket in Zammad with the right category and priority, attaches known solution articles and acknowledges receipt.
Trigger: An enquiry names requirements across several services.
Agent: The agent pulls the matching building blocks from your catalogue, drafts a quote and submits it for approval - nothing is ever sent without a human.
Trigger: A new employee or customer needs access.
Agent: The agent triggers provisioning through existing automation (n8n, Ansible, API), checks the status and reports deviations instead of glossing over them.
Trigger: Information sits in one system and is missing in another.
Agent: The agent reconciles, fills missing fields by defined rules and flags conflicts for clarification instead of overwriting blindly.
Trigger: Someone wants a conversation but only gives rough time windows.
Agent: The agent checks calendars, proposes slots and books after confirmation - including the context of what it is about.
Trigger: The same question against the same data every week.
Agent: The agent pulls the numbers via API, sanity-checks them and files the report - flagging values that fall outside the expected range.
Not a model roaming freely through your systems - a controlled chain with defined tools.
The agent reads the request and maps it to a known task. If nothing fits, it asks or hands over to a human - it does not improvise.
Via RAG or direct queries it pulls what it needs to decide: customer data, history, rules. Permissions apply as with the internal assistant.
From a fixed list of allowed actions it picks the right one and fills the parameters. What is not on the list does not exist for the agent.
For critical steps - money, external effect, deletions - the agent stops and puts the proposal to a human. You define the threshold.
The action runs through your API. Request, context, chosen tool, parameters and result land in the log with a trace ID.
The agent reports the result - including failures. Silent errors are the most expensive failure mode, so they surface.
The concern about agents is legitimate. It can be answered with architecture, not with optimism.
| Risk | Countermeasure |
|---|---|
| The agent performs an action nobody wanted | It only knows explicitly defined tools. What is not implemented cannot be called - there is no generic system access. |
| Wrong parameters, right action | Parameters are validated against a schema before the API sees them. Invalid values trigger a question, not an attempt. |
| Excessive permissions | The agent gets its own technical account with minimal rights - not the user's rights and no admin rights. |
| Nobody notices what happened | Every action is logged with trace ID, timestamp, trigger and result. The log lives in your system and is part of the handover. |
| An error repeats endlessly | Retries are capped, loops break, and the case lands with a human instead of in an infinite loop. |
| Prompt injection via incoming content | Content from emails or documents is treated as data, not as instructions. Tool selection and approval logic never depend on the sender's text. |
Anything with an API. These systems we integrate in projects or operate ourselves:
Zammad, Chatwoot, mail inboxes
n8n, Node-RED, webhooks, custom scripts
ERP and CRM via REST, ERPNext, Odoo
PostgreSQL, APIs, file storage, Nextcloud
CalDAV, Cal.eu, Mattermost, SMTP
Proxmox, Ansible, monitoring APIs
Marketing conflates the three. The difference is not the technology but who determines the path - and what happens when something goes wrong.
| What it does | Who determines the path | What a mistake costs | |
|---|---|---|---|
| Chatbot | Answers from existing content. Changes nothing. | Nobody - there is no path, only an answer. | A wrong answer. Annoying, but reversible. |
| Workflow | Runs a chain of steps: open a ticket, send mail, write a record. | You, in advance. The sequence is hard-wired; at most the model fills in fields. | The sequence breaks or runs through with wrong values. Reproducible and therefore fixable. |
| Agent | Decides for itself, within set boundaries, which tools to use and in which order. | The model, at runtime. You set the boundaries, not the route. | A wrong action in the target system - and it was not predicted. That is why approval belongs here. |
Most projects that come in asking for an agent are workflows. That is not bad news: a workflow is cheaper, finished sooner and easier to audit. We tell you that in the first conversation rather than selling the more expensive build.
This is the question missing from tender documents and the first one that hurts in production. An agent that acts needs an identity in the target system - and that determines what a single user can trigger through it.
The easy route: the agent gets a technical account holding every permission it might ever need. The problem is the union - through the agent, any user can indirectly trigger anything the service account is entitled to, including things they would not be entitled to themselves.
Only defensible if the agent does nothing that everyone may trigger anyway.
The agent acts on behalf of the user who started it and inherits their rights in the target system. Someone who may not open a ticket in that queue cannot do it through the agent either. This costs more, because the target system has to support delegated identities - and it is the normal case we build.
The default. Rights stay where they are maintained.
For actions nobody should trigger personally - nightly runs, system maintenance - the agent gets its own narrowly scoped account per task instead of one all-powerful account.
For unattended runs. One account per task, not one for all.
Either way, both are logged: who triggered the action and under which identity it was carried out. Without those two facts, there is no way afterwards to establish who is answerable for what.
As orientation, not legal advice - and reflecting the position after the Digital Omnibus, in force since 27 July 2026.
Since 2 August 2026 the transparency duties apply: anyone interacting with an AI system has to be able to tell. For an agent that means not only a note in the chat but also that an action it triggers stays recognisable as such - an email that looks as though a person wrote it is the mistake.
The Digital Omnibus moved the high-risk duties under Annex III to 2 December 2027 and those under Annex I to 2 August 2028. Anyone planning an agent in HR, lending or similarly classified areas gains time - not a reprieve.
Oversight cannot be retrofitted. It comes from critical steps requiring approval and from a named person who grants it. That belongs in the architecture, not in a policy document.
What was not recorded cannot be evidenced later. We log every action with trigger, identity, tool and outcome - on your infrastructure, not with a provider who mines it for their own purposes.
Most business agents fall not under high risk but under transparency and documentation. Which class applies to your case is for your legal advisers - we supply the technical description their assessment rests on.
An agent without tools is a chatbot. The question is how the tools are connected - and whether you keep that connection when you change the model.
MCP is an open standard through which a model addresses tools and data sources uniformly. The benefit to you is not the technology but the decoupling: an MCP server built once for your ticket system keeps working when you swap the model underneath - as long as the new environment speaks MCP, which the common assistants and editors now do.
Where an interface already exists - Zammad, n8n, ERP, CRM - we use it. We do not build a parallel world and do not require you to rebuild your systems so an agent can talk to them.
The agent gets a named list of permitted tools with defined parameters - not a database login and the hope that it behaves. What is not in the catalogue does not exist for it.
Every run is recorded as a trace: which tools in which order, with which parameters, with which result. That is the basis for reconstructing an incident rather than guessing at it.
We would rather build a smaller system that holds than a large one nobody switches on.
Then a classic workflow (n8n, script) is cheaper, faster and easier to debug. An agent pays off once the intake is unstructured.
Where only a UI exists, any automation stays fragile. The honest order is: interface first, then agent.
Ten cases a year do not justify automation with maintenance overhead - the human wins there.
If nobody can say which system holds the truth, an agent only automates the confusion. Clean up first, then automate.
Honestly upfront: not every process needs an agent. If a form or a fixed workflow is enough, we will say so - an agent pays off where requests arrive unstructured and a human currently sorts them.
Further use cases on the same stack cost considerably less than the first - tools, permissions and logging are already in place.
Runs where you want
Answers to the most important questions
A chatbot answers questions. An agent executes actions: it creates the ticket, books the appointment, queries the database or triggers the n8n workflow - and reports the result back. Defined tools draw the line, not the model.
Through architecture instead of hope: the agent can only execute explicitly approved actions with validated parameters, critical steps require human confirmation, and every action is logged with a trace ID. What is not defined cannot be done.
Anything with an API: ticket systems like Zammad, workflows via n8n, ERP and CRM systems, databases, email and calendars. Integration runs through defined tools with clear permissions per agent.
Incoming content is treated as data, not as instructions. The agent selects tools based on the defined task, not on text inside a document - and critical actions require approval anyway. On top of that, such an attempt is visible in the log.
Yes. The stack runs on European infrastructure or your hardware, with a European model (Mistral) or local models. Action logs stay in your system and are part of the handover.
We quote after the intro call, because effort and scope depend heavily on the use case. You receive a written effort estimate before you commit. Further use cases on the same stack cost considerably less, because tools, permission concept and logging already exist.
Yes, that is the recommended path. Internal assistant and agent share the same stack (LiteLLM, Langfuse, knowledge base) - tools and approvals are added as a layer, without a rebuild.
After the analysis, typically three to six weeks to the first production use case - depending on how accessible the target systems are. The bottleneck is almost never the model, it is the interface.
No risk: worst case, you leave with a clearer understanding of your project than before.


“WZ-IT's advice on our Azure migration was technically sound and completely non-binding right from the intro call - we took away a great deal.”
ml&s speaks about integrating a local AI solution. The other voices cover architecture, data sovereignty and operations - exactly the maturity an AI project needs to reach production.
Whether a specific IT challenge or just an idea - we look forward to the exchange. In a brief conversation, we'll evaluate together if and how your project fits with WZ-IT.
Timo Wevelsiep & Robin Zins
Managing Directors of WZ-IT
