AI · Agents
AI agents for automating business tasks.
AI that doesn't just answer - within defined rules it checks the data, uses your systems and carries out the next step.
When clients usually bring us in
- staff hunt for information across documents
- documents are reviewed by hand
- support answers the same questions repeatedly
- you need classification or data extraction
- you want AI inside the business process, not beside it
AI isn't always the right answer
If plain automation solves the process, we don't add AI because it's fashionable. We'll tell you where AI pays off and where it doesn't.
What this means for you
- Less time spent looking for information.
- Less manual retyping of data.
- Faster processing of documents and requests.
- More consistent answers from your team.
- A clear trail of where each answer came from.
Problem → solution
What has to be in place
Permissions
An agent can only reach what it is explicitly allowed to - per system and per role.
Human in the loop
Actions with real consequences are approved by a person. We set those boundaries with you.
Logging
Every step is logged: what the agent saw, what it did and on what basis.
Integrations
The agent uses existing systems through their APIs; it doesn't bypass your rules.
Data security
Data separation, encryption and control over what reaches the model.
Monitoring
Tracking success rate, failures and cost per task.
How an agent works
Use cases
Request handling
The agent classifies the request, gathers data and drafts a resolution.
Document preparation
It collects data from several sources and fills a template for review.
Internal assistant
It answers staff questions and performs routine tasks.
What an agent is made of
An agent is not a model with a longer prompt. It is a system around the model: it has a task, access to sources, a set of permitted actions, rules about when it must ask a person, and a record of everything it did.
Goal
What the agent should achieve and when the task is done. Without it, an agent keeps trying indefinitely.
Context
What data it can see and what it cannot - including the permissions of the user it acts for.
Tools
Concrete operations in your systems: find, read, create, update, submit for approval.
Rules
The business rules that apply, exactly as they would to a person doing the same work.
Guardrails
What the agent must not do, even when it looks like the fastest route to the goal.
Audit trail
What it read, what it did, on what basis, and who approved it.
Permissions: what an agent may do
We split actions into classes and decide for each who may trigger it and whether approval is needed. An agent must never see or change more than the user it acts for.
| Action class | Example | Rule |
|---|---|---|
| Read | find a request, read a contract, fetch a status | within the user's permissions |
| Draft | draft a reply, a summary or a calculation | the result is visible before it is used |
| Write | create a record, update a status, attach a document | only for precisely defined operations |
| Approval required | send a message to a customer, approve an amount, close a case | executes only after a named person approves |
| Not permitted | deletion, changing permissions, access outside the scope | not among the agent's tools |
What an agent does when something fails
An agent that guesses when it hits a problem is worse than one that stops. So we define in advance how it responds to the usual failures.
A silent failure is the expensive one
An agent that marks a task done when it was not causes more damage than one that clearly says it could not finish.
| Failure | Response |
|---|---|
| a source is unavailable | retry, then stop and notify |
| required data is missing | ask the user instead of guessing |
| the request is ambiguous | summarise the interpretation and ask for confirmation |
| the output does not match the expected format | reject the output and process again |
| a tool returns an error | it is logged and the task is not marked complete |
| the action exceeds permissions | stop and hand over to a person |
A typical use case
The example illustrates the type of task; it is not a reference.
The agent receives a request by email, identifies the customer in the CRM, pulls contract data from the ERP, finds the latest amendment in the document system, prepares a draft reply with references to the sources and sends it to the responsible person for approval. Once approved, it sends the reply and records the case.
How we roll an agent out
Task inventory
what a person does today, in which systems and under which rules
Boundaries and permissions
what the agent may read, may change and must send for approval
Tools
operations in your systems, each with input and permission checks
Trial on real cases
the agent prepares, a person approves everything; we compare against the manual result
Gradual rollout
automatic execution is allowed first for the lowest-impact actions
Monitoring
logging, alerts and regular review of the results
How we design the AI
Use case
We start by defining which decision or step the AI takes over, and where it must stop.
Data
We map sources, quality and access. Without organised data, AI cannot produce a dependable result.
Architecture
We choose the model, the retrieval approach and the point where AI plugs into the existing process.
RAG, agents, tools
The agent uses your systems through their APIs, within the permissions you define.
Keeping AI in control
Guardrails
What the AI may and may not do, when it must ask a person and when it stops the process.
Human in the loop
A person approves the sensitive steps. Each approval is logged together with the reason.
Evaluation
Regular checks on sample sets, so we notice when answer quality drifts.
Monitoring and cost
Tracking success rate, failures and cost per task, with alerts when something deviates.
Related work
FAQ
Can an agent break something?
The agent has limited permissions and checkpoints. What isn't explicitly allowed isn't possible, and high-impact actions require approval.
Related solutions
Sounds like your project?
Send us the project description, your existing system, the tender documents or the event date.