An agent with access to your systems is useful exactly to the degree that what it may do is bounded. We build agents with explicit permissions, a traceable chain of decisions and a human in the loop wherever the stakes are high, and we say upfront when your process needs ordinary automation instead.
The difference isn’t the model, it’s the consequences. When a chatbot is wrong, the user gets a bad answer and is annoyed. When an agent is wrong, the invoice is already paid, the email already sent, the record already deleted. The same technology, an entirely different risk profile — which is why the most important part of an agent is what it is not allowed to do.
So building one starts from permissions and boundaries rather than from the model. Which tools it can reach, what value or volume it may decide on by itself, when a human has to approve, and what happens when it gets something wrong — whether the step can be undone. With those answered, choosing a model is a fairly ordinary technical decision. Without them, what you have isn’t an agent but an automated risk.
Six services. Most projects begin with the first and some stop there — often the right outcome, because not every process needs an agent.
We work through your processes and assess which suit an agent at all: whether the step is reversible, whether success is measurable, whether the data exists, and which risk class the use case falls into under the EU AI Act. Then we choose the agent type and the model and give you an architecture and a cost. Most good candidates are boring — repetitive, rule-shaped and well documented — and some processes need no agent at all, which we will also say.
One agent, one clearly bounded task: customer support, knowledge management, billing, data processing. For conversational use cases the same agent can run as a chatbot or virtual assistant wired into your systems. Each is tuned on your domain’s data and connected to the systems the task requires. A narrow agent you can test beats a broad one you can’t — and reaches production in months rather than a year.
Multi-step processes with several decisions, several data sources and several integrations. Agents divide responsibility, hand work on, supervise one another’s output, and can use different models and tools depending on the task. Useful when the steps are genuinely separate — not as a way to make a simple thing more complicated, which is this pattern’s most common misuse.
An agent is useful exactly to the extent of what it can see and do. We connect it to your CRM, ERP, databases and APIs and tie the steps into multi-stage workflows where each tool has its own permissions and its own log. The orchestration layer decides which agent acts when, what happens on failure and where the approval point sits — and it is where agent systems most often break.
The model is chosen for the task, the latency and the price rather than for a leaderboard position — often the right answer is a smaller, cheaper model for a narrow job. Fine-tuning comes up only once better context has stopped helping: we prepare the training set, tune the model on your domain and test the result for bias as well as accuracy. Most projects never reach this step, which is good news, because a fine-tuned model has to be maintained afterwards too.
An evaluation set built from real cases, and regression tests that run on every change. Models shift even when your code doesn’t — a provider updates a version and the behaviour moves, and without tests you find out in production. We also track cost, latency and which cases the agent gives up on most often, because that list is what shows you where to improve next.
Most projects are one of these seven, or a combination of two. Which one depends on how many steps the process has and how expensive a mistake is — not on which sounds the most capable.
One autonomous agent with one clearly bounded responsibility: resolving a ticket, handling an invoice, retrieving an answer from a knowledge base. Even a single agent lifts productivity noticeably and is cheap to build and to maintain — which is why it is almost always the right place to start.
For more complex processes with several decisions, several data sources and several integrations. Agents divide responsibility, hand work on, check one another’s output, and can use different models and tools depending on the task.
An agent automating one well-defined job: processing documents, classifying requests, retrieving and reconciling data, internal routines. It integrates with your systems and carries the workflow through on its own, with nobody stepping in halfway.
An agent with a conversational interface, differing from an ordinary chatbot in one important respect: it doesn’t only answer, it acts. It books, amends an order, initiates a refund — a conversation from the user’s side, your systems on the other, with permissions and approval points in between.
An agent that carries a business process end to end without constant supervision: fetching data, validating it, triggering actions in external systems. Most useful where the volume is high and the work is document-shaped — finance, supply chain, compliance.
An agent that works through a large volume of data, weighs the possible actions and either recommends or decides. Used where accuracy and speed both matter — risk assessment, fraud detection, predictive maintenance, operational planning. Here a human approval step is nearly always required.
An agent tuned to your domain’s vocabulary, rules and requirements. A general model doesn’t know your product codes, your contract terms, or what a given abbreviation means inside your company — and that is exactly where the most convincing wrong answers come from.
Eight capabilities that separate an agent from scripted automation. None of them is an end in itself — they are means, and we use only the ones your task actually calls for.
The agent weighs data, draws conclusions and decides without a person confirming every step. That earns its keep where a decision depends on context and won’t fit in a decision tree — and that is exactly where it matters most that the reasoning is readable afterwards.
The agent interprets the request, plans the steps and uses tools — APIs, databases, other agents — until the task is finished. You give it the goal rather than a list of steps.
Short- and long-term memory that holds context within a conversation and between them: what was agreed before, the previous decision, the customer’s history. In a multi-agent system that context is shared, so the next agent doesn’t start from nothing.
The agent improves through feedback loops: human corrections, new data sources and evaluation results flow back into the system. One important nuance — we don’t let an agent retrain itself unattended, because then nobody knows why the behaviour changed.
Text, documents, images, audio, video and code. In a real business the information never arrives in one format: the invoice is a PDF, the proof is a photo, the instruction is a video, and half the knowledge is in somebody’s email.
The agent works inside your CRM, ERP, data platforms and third-party services rather than alongside them. The workflow isn’t rebuilt around the agent; the agent is built into the workflow you have.
Several agents collaborating in real time, dividing tasks and holding performance as volume grows. The bottleneck here is rarely the model — it is usually queues, rate limits, and what happens when one step slows down.
Data protection, access control and explainability are built in rather than added. In a regulated environment the important question isn’t whether the agent can do it, but whether you can later show why it did what it did.
Five stages. The first three decide whether the project is viable at all — and not one of them involves building the agent.
We analyse the workflows, the decision points and the automation opportunities, and establish where an agent delivers measurable value. We agree the use cases, user roles, compliance constraints and success metrics — and decide whether this calls for a conversational agent, an agentic workflow, multi-agent orchestration, or ordinary automation instead.
An agent is only as good as its data layer. We design secure pipelines for documents, databases, APIs and enterprise systems, agree the retrieval and indexing strategy, and build the memory and context handling. This is also where the rules for data quality, access control and compliance are set.
The architecture follows the complexity and the risk level: single agent, several agents, or a hybrid. We weigh foundation models, open-source models and commercial APIs against quality, latency, privacy, scalability and cost — and use agent frameworks only where they give a measurable gain.
The agent is engineered to behave predictably. We put in place the evaluation pipelines, the grounding of answers in sources, the guardrails, the fallback logic and the human approval points. Performance is measured on task success rate, answer quality, consistency and policy adherence — not on a demo.
The agent goes into your environment: CRM, ERP, data platforms, internal applications and APIs. The deployment architecture is designed for security, scalability and observability, and aligned with the cloud and platform standards you already run, so the agent is production-ready from day one.
Agent frameworks are young and turn over fast. We build so that the framework and the model are replaceable parts — your business logic and permission model must not depend on which library is popular this year.
An agent doing things in your name needs the same constraints as an employee — only written down and enforceable. These four are agreed before the first line of code.
The agent gets exactly the permissions the task requires — and no more, even where more would be simpler.
The question isn’t whether a person approves, it’s when. That is agreed beforehand rather than after the first incident.
For every action it has to be possible to answer “why did it do that” afterwards — a month later included.
The two things that most often surprise people about agents: how well it actually works, and what it costs per month.
Five stages. First, bounding it: which process, what the measure of success is, and whether the step can be undone. Second, data and context — an agent is only as good as what it can see, and this is usually where it emerges that some of the necessary knowledge isn’t written down anywhere. Third, architecture and model selection. Fourth, the guardrails: permissions, approval points, fallback logic and an evaluation set. And only fifth, integration and deployment.
An agent never goes into production deciding things straight away. First it runs in shadow mode: it proposes, a person decides, and we compare the two. Only once the agreement rate is high enough and the failure modes are known do we give it authority to act — and even then within narrow bounds at first, on small amounts or low-risk cases.
When choosing a partner, ask what happens when the agent is wrong. If the answer doesn’t contain the words “log”, “approval” and “rollback”, no guardrails have been designed. And ask how it will be measured — without an evaluation set, every claim about an agent’s quality is an opinion.
Most processes people want an agent for are really rule-based automation. That is cheaper, faster and predictable — and we’ll recommend it.
The agent proposes and a person decides until the agreement rate has been measured. Only then does it get to act, and at first within narrow bounds.
Every tool gets its own permissions and its own log. An agent must not reach anything its task doesn’t require, even where that would be convenient.
Quality is measured against a set of real cases that runs after every change and every model swap. A demo shows the best case; a test shows the average.
The business logic and the permission model don’t live inside an agent framework. This field moves fast and today’s library may not exist in a year.
We work out which risk class your use case falls into under the EU AI Act, and what that requires in documentation and human oversight. Hosting can stay entirely inside the EU.
Less than people usually assume — for many tasks a few thousand well-labelled examples is enough. Data quality and labelling consistency affect the result more than volume does.
Often not. For classification, forecasting and anomaly detection a smaller, purpose-built model is cheaper, faster and more accurate. We recommend a language model when the task genuinely involves free text.
Evaluation suites before release, confidence thresholds, routing uncertain cases to a person, and continuous monitoring in production. None of these is sufficient alone; only the combination works.
Ordinary automation follows a fixed sequence of steps. An agent decides the sequence itself, based on the situation. That’s useful when cases vary too much to encode as rules — and unnecessary when they don’t.
Tools are explicitly scoped, write permissions are assessed separately, and irreversible actions — payments, deletions, customer communication — are confirmed by a person. Every decision is logged so you can see afterwards why something happened.
For narrowly scoped tasks, yes; for broadly defined ones, no. Our recommendation is to start with one clearly bounded workflow, measure the result, and widen only when the numbers support it.
Software that uses a language model to carry out a task rather than to talk about it. It can break a task into steps, use tools such as search, APIs or a database, and decide the next step from the result of the last.
The practical difference from a chatbot is in the consequences. A chatbot gives you an answer and you decide. An agent decides itself and acts: sends the email, changes the record, initiates the payment. The same technology, an entirely different risk profile — which is why the most important part of an agent is what it is not allowed to do.
Boring ones. Repetitive, rule-shaped, well-documented processes where success is measurable and the step can be undone — processing documents, classifying requests, reconciling data, a first pass before a person looks.
Poor fits are where an error is expensive and irreversible, where the rules aren’t written down anywhere, or where the right answer depends on context the agent can’t see. And a good share of what people want an agent for is really ordinary rule-based automation — cheaper, faster and predictable. We say so upfront, including when it means a smaller project for us.
In two stages. First an evaluation set: we collect real cases with known correct answers and measure how often the agent gets them right. That set runs after every change and every model swap — models shift even when your code doesn’t, and without tests you find out in production.
Then shadow mode. The agent runs on real data and makes its proposal, but a person makes the decision — and we compare the two. That shows the real agreement rate and surfaces the failure modes before they have consequences. Only then does the agent get authority to act, and at first within narrow bounds: small amounts, low-risk cases.
It depends what the agent is used for. The Act sorts use cases into risk classes, and most internal business agents — document processing, internal support, data reconciliation — sit in the lighter part, where the main obligation is transparency: a person has to know they are dealing with AI.
Stricter requirements arise where an agent affects decisions about people — hiring, credit, access to services. There you need a documented risk assessment, human oversight and traceability. Our job is to establish that class at the start and build so the requirements are met, rather than discovering later that the system needs reworking. We don’t give legal advice, but we’ll tell you when it’s worth asking for.
Describe your situation in a couple of sentences. We reply within one working day.