Preparing quotes
Read the enquiry, fetch items and prices from the inventory management system, create the quote as a draft. A person signs it – the agent saves the gathering of information, not the decision.
AI agents & MCP servers
Agents that process tasks – with a log and human approval
A chat answers questions. An agent gets tasks done: it reads an enquiry, looks things up in your inventory management system, prepares the draft and submits it to a person for approval. The difference between the two is not the model, but the architecture.
Approval for every write action Complete log Separate account per agent Kill switch with a named person
The architecture
The MCP server is the only point at which the AI reaches your systems
MCP stands for Model Context Protocol – an open specification of how an AI model calls tools and data sources. In practice it is a service on your server that offers the AI exactly the calls you have approved: “read a customer's open items”, “create a draft quote”. Nothing more.
Because everything runs through this one point, there is exactly one place where permissions are set, approvals are enforced and calls are logged. If you connect each application individually instead, these three things are spread across the whole organisation – and afterwards you can no longer find where something was triggered.
The second advantage is independence: the same tools can be used with different models. If the model changes, the integration stays.
Use cases
Where an agent pays off
The question is never the number of employees, but the number of repetitions. A process that occurs twenty times a day justifies the setup. Twice a month does not.
Sorting incoming mail
Invoices, job applications, complaints, advertising: classify, assign, forward. Uncertain cases end up on a review list instead of in the wrong mailbox.
Maintaining master data
Find duplicates, reconcile addresses, suggest missing fields. Changes are made after confirmation – with master data, a faulty automation costs more than doing it by hand.
First-level ticket handling
Log the request, ask follow-up questions, close standard cases, escalate everything else – with the history so far, so that your colleague does not have to start from scratch.
Compiling reports
Figures from several systems combined into the monthly report, always in the same format, always by the same date. Otherwise the effort lies exactly where nobody wants to see it.
Preparing for audits
Gather the documents for a tax audit or certification and check them for completeness. Whatever is missing appears on a list instead of being discovered on the day of the audit.
Our build rules
Six rules we follow when building agents
These rules are here because they make the difference between a tool and a risk. They are not negotiable – not even when a client is in a hurry.
- Reading is free, writing needs approval. Anything that moves money, affects contracts or goes outside the company goes through a person.
- A separate account for each agent. No agent works under an administrator account, and none under a person's account.
- Permissions as narrow as possible. What gets approved is what the task needs – not what is convenient.
- Every call in the log. Who, when, which tool, which result: analysable, not just recorded.
- A kill switch. A switch that shuts the agent down immediately, and a named person who is authorised to use it.
- Acceptance against a metric. Agreed beforehand, checked afterwards.
What we do not build
Agents that trigger payments on their own. Agents that prepare HR decisions or assess people – that falls into the high-risk category of the EU AI Act and does not belong in an automation project. Agents with administrator rights “for emergencies”. And chains of several agents before a single one has been shown to work.
Why we advise against multi-agent systems as a starting point
Several agents working for one another are currently the most heavily promoted offering on the market. The catch is arithmetic: errors add up at every stage, and when five agents are involved, a wrong result can hardly be traced back to any one point. A single task, properly measured, achieves more – and the architecture remains open: once the first one works, the second can follow.
Process
One task, six weeks, one number
An agent project does not start with the technology, but with the question of how the process really runs today – including the exceptions nobody has written down.
Describe the task
We go through the process with the people who do it. This brings to light the special cases that later decide between success and failure.
Define the tools
Which calls does the agent need, and which of them read and which write? This is what the MCP server is built from – along with the list of what the agent cannot do.
Test in a dry run
The agent processes real tasks but writes nothing: every step is presented and assessed. This produces the metric without anything being able to go wrong.
Put into operation
Activate the approvals, analyse the log, refine the edge cases. After that, a decision is made on whether a second task follows.
Frequently asked questions
Questions about AI agents and MCP
What exactly is an MCP server?
MCP stands for Model Context Protocol – an open specification of how an AI model calls tools and data sources. In practice it is a service that runs on your server and offers the AI exactly the calls you have approved, such as “read a customer's open items” or “create a draft quote”. The advantage over individual integrations: the same tools can be used with different models, and there is only one place for permissions and logging.
Do we need several agents straight away?
No, and we advise against it. A single task, properly measured, achieves more than five agents working for one another whose errors nobody can trace any more. The architecture remains open – once the first one works, the second can follow.
What if the agent makes a mistake?
It will make mistakes. That is why every write step requires approval and every call is logged. If in doubt, every task can be traced back and undone. An agent without these two properties is not a product, but a risk.
Does this work with our industry software?
If it has an interface or an accessible database, as a rule yes. Whether and how well, we clarify in the initial consultation – we look at the application rather than simply promising it will work. Where a vendor does not provide an interface, we tell you so, rather than building a workaround that breaks with the next update.
Does the agent run on our premises or in the cloud?
Both are possible. The MCP server as a rule runs on your premises, because it maintains the connection to your systems. The model can run alongside it on the same server or with a provider – that depends on how confidential the processed content is. We tell you beforehand which data goes where.
Does an agent replace a job?
In practice it shifts work rather than replacing it: away from gathering information, towards checking and deciding. Anyone who introduces an agent with the aim of cutting a position usually ends up measuring the wrong thing – and also gets no support for it within the company.
Further reading
Related services and articles
-
Service
Artificial intelligence
An overview of all four AI building blocks.
Read -
Service
Software development
Interfaces, custom software and apps developed in-house.
Read -
Service
AI in existing software
Read documents and assign them to transactions – in the application you already use.
Read -
Service
IT infrastructure
Servers, virtualisation and network – where the MCP server runs.
Read
Free initial consultation
Tell us which process takes up the most time
We look at it and tell you whether an agent can take it over, where the approvals would need to sit and what the dry run costs. If the effort does not pay off, we tell you that too.
+49 221 984300-0Switchboard and support hotline
[email protected]Reply within 4 hours on working days
Robert-Perthel-Straße 7250739 Köln – Bilderstöckchen
Mon–Fri 9 am–6 pmEmergency support outside these hours by arrangement