AI agents · inside your system · data stays with you
AI agents that workinside your system.On their own, and alongside your team.
Each agent works only on its own patch. The refunds agent cannot touch prices, and the support agent cannot change partner contracts. Agents run processes in the background, on a schedule or when something happens. When someone on your team needs an answer, the agent finds the data and pulls it together, so people spend their time on decisions instead of clicking through screens.
We bring agents in step by step, on a platform you can trust with the system your business runs on.
Its own patch only
The agent gets access to specific actions and data. Everything else does not exist for it.
Rolled out under control
Until the AI has proven its decisions in your process, a person sees each one before it runs. A wrong decision never reaches the system.
Guaranteed by the platform
Every change is checked before it is sent and logged with the values it replaced, so a wrong edit can be undone.
What agents do
They work in the background, and answer when you need to understand something fast.
Two modes on one platform, with the same guarantees. Agents run processes on a schedule and when events happen. And anyone on your team can ask an agent to find and pull together data from the system, email and customer requests. Instead of filters, lists and a dozen screens, they get an answer they can decide on, and they keep the tools they know.
In the background
Agents run processes themselves
Incoming documents
Claims, complaints and refund requests that arrive by email. The agent reads the messages and attachments, updates the records and asks the sender for missing documents.
Customer requests
Routine questions get an answer from your knowledge base and reply templates. A second model scores every reply on its own.
Work with partners
Suppliers, contractors and agents. Terms, price lists, availability and contacts are updated from their emails and notices, and each change is logged.
On request
The agent finds, a person decides
Search without the legwork
“Which partners in this country changed their terms last month?” The agent goes through the lists and records and pulls the answer together. Half an hour of filters becomes a minute, and the person works on the conclusions.
One case in one answer
An order, the customer’s request, the emails with the partner and the settings that affected them, in one answer with links to the records in your system.
From finding to fixing
What the agent found can become a set of changes straight away. The agent puts it together within its patch, and the platform checks it and runs it.
An agent’s patch
Each agent works only on its own patch.
An agent that handles one kind of task cannot change the data of another. Its patch is set by a grant: the list of actions and types of data it may work with. You do not need a separate API for agents. The agent works through the same API as your system’s own screens.
Data outside the patch is off limits.
A set of changes that touches data outside the grant does not run. The grant is checked in the same step that starts the run, so nobody can change it in between.
Its own account, if you want one.
The agent can get its own user in your system, like a new employee. Then your system checks its rights as well, and your system’s log names the agent as the author.
You see who did what.
The platform log shows who gave the agent its grant, when, and what the agent ran with it.
Revoked at once.
A grant is changed or revoked with one button. The next run follows the new rules, and a revoked grant cannot come back.
| Agent | Refund requests | Customer requests | Partner terms | Prices | Payments |
|---|---|---|---|---|---|
| Refunds agent | Allowed | replies only | No access | No access | No access |
| Support agent | No access | Allowed | No access | No access | No access |
| Partner agent | No access | No access | Allowed | discounts only | No access |
A sample grant matrix. You draw it up with the people who own each process, and it changes without any programming.
Why pilots stall
Pilots stall on what surrounds the model.
The model handles the work well enough. While the agent only reads and advises, everything works. Once it has to write to the system you run on, and with no one beside it, your business has questions that a demo does not answer.
What may the agent do?
Access to an API usually means the whole API, and a shared service account sees all the data at once.
Who answers for a change?
If every agent uses one account, your system’s log cannot show who changed what.
What if the network drops halfway through?
Half the changes are applied and half are not, and a retry creates duplicates.
How do you fix a mistake?
If nobody kept the values from before the change, there is nothing to roll back to.
Where does the data go?
Customers’ personal data in the chat window of an outside AI service is a question for your lawyers.
How do you stop the AI from making wrong decisions?
Until it is proven on real cases, you cannot trust an agent with your live system. Approving every step forever costs too much.
How it works
Each of these risks is closed in code and in the database.
These are the decisions that let agents into a live system. None of them depends on people agreeing to be careful.
The agent does something it should not
A catalogue of operations instead of open API access.
The agent picks an action from a list described in advance and fills in the parameters. If an action is not in the catalogue, the agent cannot do it.
Each operation knows its fields, allowed values and rules. An unknown operation can be neither checked nor rolled back, so it is left out.
The agent strays outside its patch
A grant for actions and data.
Each agent has its own list of what it may do. An agent for one kind of task cannot change the data of another.
The platform checks the grant at the moment of the run. If the agent has its own account, your system checks its rights as well.
An error that only the system would catch
Checked before it is sent.
A set of changes is checked while it is being built: formats, reference lists, links to existing records, duplicates, rules between fields. A change that would change nothing is never created.
A refusal halfway through a bulk change costs more than an extra read while building it.
A failure in the middle of a bulk change
Runs survive crashes.
A run of hundreds of operations can be cut off by a server restart, an update of your system or a dropped connection. It carries on from the same place.
Each step is saved together with its log entry. The one step in doubt is checked against the system before it is repeated.
A retry creates duplicates
Nothing is written twice.
If the system did not answer, the platform reads it again first and repeats only what did not arrive. An email to a customer with an unknown outcome is not sent again. It goes to a person.
Creating, changing and deleting each have their own rules. Where there is no clear answer, the step stops and does not guess.
A mistake can no longer be fixed
A log, and rollback of edits.
For every step the platform keeps the request, the system’s answer and the values before the change, so a wrong edit can be undone. The rollback is built from the log as a new set of changes and goes through the same checks. Cancelling an order with a partner or sending an email to a customer cannot be rolled back. The review stage exists for actions like these.
The log shows what changed a given record, which agent did it and in which run.
The AI makes a wrong decision
Review before the run, while rolling out.
Until the process has proven reliable, a person sees each of the agent’s decisions as “before → after” and can reject the whole set. Actions that cannot be undone, such as cancelling an order with a partner, are confirmed record by record.
Exactly the reviewed version runs. If the agent changed it, or the record changed in the system, the review starts again.
The AI confidently writes nonsense to a customer
A second model checks the first.
A different model scores replies to customers against a rubric and shows its confidence and the passages worth rereading.
An agent never scores itself. The scores build up per process and become one of the grounds for letting the agent run on its own.
An attacker’s email steers the agent
Email is data, never instructions.
The agent reads the connected mailboxes, but nothing in an email counts as a command. The agent flags suspicious activity, such as a bulk export of reference lists, for audit.
Every agent call and every request to the system is recorded. Flags go to the people responsible.
Rollout
The AI proves itself first, then acts on its own.
The biggest risk in rolling out AI is a run of wrong decisions, more than any crash. So a new process starts with review: a person sees each decision before it runs, and a wrong one never reaches the system. Review is a rollout step. It ends once the agent’s decisions go through without corrections, and from then on the agent works on its own.
- Stage 1
Search and analysis
The agent finds and pulls together data from the system, email and customer requests for your team. It changes nothing itself. Useful from the first day, with no risk.
- Stage 2
Reviewed decisions
The agent prepares changes. A person sees “before → after” and runs or rejects them. Only checked decisions reach the system.
- Stage 3
On its own, within its patch
Where practice has confirmed the agent’s decisions, the agent runs the process itself, within its grant. The grant is revoked with one button.
- Goal
Agents in the background, the team working with them
Proven processes move to triggers. Agents run them on a schedule and on events, each within its own patch. Your people use the agent to understand the data and to start new work. New processes still start with review.
The log, rollback, checks before sending and the audit are the same at every stage. What changes is who starts the run, and within which limits.
Case · European online car rental aggregator
An agent platform for an operations team
Our client, a car rental aggregator, runs a large in-house system: partners with their terms and price lists, sales rules, refunds, claims and customer requests. The operations team spent hours making the same edits across dozens of screens and sorting through email.
The goal is agents that run operational processes themselves, and quick access to the system’s data for the team through an agent. For this we built an MCP platform through which agents work with the system. Its web portal is for the rollout stage, where every change the agent proposes is visible, for access and integration settings, and for analytics. The agent finds and pulls together data from the system, email and customer requests, so nobody has to search through screens. When changes are needed, the agent puts them together, and the platform checks them and runs them within the agent’s grant.
What the agents work on
- Partner terms and price lists
- Discounts and sales limits
- Catalogue and reference data
- Refunds
- Claims
- Customer requests
- Emails to customers
- Order operations
- Texts and translations
- ≈90screens of the business system open to agents through one catalogue of operations
- ≈50agent tools: business system, customer requests, email, documents, skills
- 2 monthsfrom the first commit to daily use by the team, with 219 releases
- Hundredsof operations in one run, resuming after a failure
Today the team works through the agent and reviews each decision before it runs. Agents in the background, on a schedule, are the next stage.
One change, from start to finish
- 01 · Agent
Reads
Records in the system, emails, customer requests, attachments. Every call goes into the audit log.
- 02 · Agent
Puts the changes together
Only operations from the catalogue, and only within its grant.
- 03 · Platform
Checks
Before sending, it catches everything the system would reject: formats, reference lists, duplicates, links.
- 04 · Person, during rollout
Reviews
“Before → after” in plain words. A wrong decision is rejected before it runs.
- 05 · Platform
Runs
Step by step, logging the values from before each change.
The difference
How this differs from plugging a chatbot into an API.
How it works
A chatbot answers from the documentation
Agents run processes in the background and find live data in the system for your team to decide on
What the agent may do
The whole API, under a shared service account
Its own patch only: a grant for specific actions and data, and its own account where needed
Role of people
At every step forever, or never
Review of every decision until the AI has proven itself in the process, then the process runs by itself
A failure mid-operation
Someone works out by hand what got applied
It carries on from where it stopped, and the step in doubt is checked against the system
A mistake
Found in the logs and fixed by hand
Values from before the change in the log, and the edit rolled back as a new run
Replies to customers
The model checks itself, or nobody does
Scored independently by a second model
Audit
The model’s logs, if there are any
Every agent call, every request to the system, and which agent ran what under which grant
Know-how about the process
In one person’s prompt
Skills with versions and variants, shared by the team and the agents
Data and GDPR
Sensitive data stays in your infrastructure.
The platform is deployed in your infrastructure: Kubernetes, Azure, AWS or your own servers. Runs, logs and the audit are kept by you, outside the chat window of an outside AI service, and your rules decide who can see them.
- The model is chosen for the task and the jurisdiction. In the case, Claude is the agent and a different model does the independent check. You can change the model without rebuilding the platform.
- Only one service can reach your business system. Its address and keys never reach the agent or the browser.
- The portal opens only from your internal network. Sign-in goes through your business system’s accounts, and only company domains are allowed.
- Software dependencies are installed no sooner than a week after a version is published, which protects against compromised packages.
- We write down access rights and how long each kind of data is kept, and prepare the technical part of a DPIA when one is needed.
Running the model on Azure? Where prompts and answers are processed depends on the deployment type more than on the region of the resource. Deployment types and GDPR on Azure
How we start
One process. Measured before and after. Autonomy once it is proven.
- 01
Pick a process
With the people who do the work, we count the hours and define the future agent’s patch: which actions and data it will need.
1 week
- 02
Search and analysis through the agent
We connect the system, email and customer requests. Your team starts asking the agent for searches and summaries straight away, and we see the real questions.
1–2 weeks
- 03
Reviewed AI decisions
A catalogue of operations for the process, checks, a log and rollback. A person sees each of the agent’s decisions before it runs, and wrong ones are rejected before they reach the system.
3–4 weeks
- 04
On its own
We compare hours, errors and response times, and count how many of the agent’s decisions went through without corrections. Once the process has proven reliable, it moves to triggers and the agent runs it. If it does not pay back, we tell you.
Then one process per round
Questions
What people usually ask
Do we need to build a separate API for agents?
No. The agent works through the same API your system’s own screens use. If needed, it gets its own account, like an employee, and your system checks its rights. If the API lacks something a process needs, we tell you which methods are missing, and we can build them.
How do you make sure an agent stays on its patch?
The platform gives each agent a grant: a list of actions and types of data. An agent for one kind of task cannot change the data of another, because such a run will not start. The grant is checked when the run starts, as well as when the changes are put together. If the agent has its own account, your system checks its rights too.
What does a background agent do when it cannot decide?
It stops and hands the case to a person, with the data already gathered. The same happens when the outcome of an operation is unknown: if the system did not confirm an email to a customer, the email is not sent again and goes to a person to check. Where a mistake cannot be undone, the platform does not guess.
Why not let the agent do everything from the start?
Because nobody knows in advance how well the AI will decide in your particular process. The review stage removes that risk: a person sees every decision, and a wrong one is rejected before it runs. Once practice shows that the agent’s decisions go through without corrections, review ends.
Why not build this in Copilot Studio or n8n?
For simple chains such as “read an email, create a task” they are a good choice, and we will suggest them. When agents in the background change money, prices and orders in volume, you need a catalogue of operations, grants, resuming after a failure, checks on steps in doubt, and rollback. Builders like these do not have them.
What’s next
Tell us which process takes the most time.
In 30 minutes we will tell you which parts an agent can run on its own, where it will help your team find answers faster, what its patch would be and what the first stage would cost. We will show you the platform on a live example.
Describe one process
Prefer to talk?
Book 30 minutes with our CEO. Bring the process, we will bring the questions.
Book a 30-minute callRiga · Daugavpils, Latvia