AI that belongs to you.
Not to your provider.
Office work is reorganising itself for the fourth time.
This isn’t a future scenario. It’s already happening, in every company.
Apps are expensive. People are the bottleneck. Every task becomes its own app, expensive to build, expensive to maintain. Employees wait on IT, because every exception needs a ticket. And with every resignation, knowledge leaves the company, for good.
More capability has always cost more data
A window someone types into. Useful, but with no access to your systems, and every request starts from zero again.
Sits inside the office tools and sees what is being worked on. The provider sees exactly the same.
Agents that genuinely work, operated at the provider. It sets the model, the data flow and the price, and it sees nearly everything that passes through.
The same agents, the same capability, just operated inside your own house. PrivacyGuard takes the personal data out before every model call and puts it back afterwards.
Until now, wanting more capability meant handing the model provider a bigger share of your own data. agentctl breaks that lockstep instead of managing it.
Keeping the data in house is not only protection. Over five years it becomes the difference between rented and owned AI.
Usage grows
Month by month, people move more of their work onto their agents, because what worked once keeps working.
The data grows with it
What builds up is a record of how the business actually runs: workflows, decisions, reasons, exceptions.
That record is yours
It sits on your infrastructure, under your control, in your possession.
Without agentctl: streamed to the provider, continuously.It turns into an AI that is yours
A system that knows your business because it has been writing it down for years. No provider can sell you that.
A subscription ends when you cancel. A record of your own work stays, together with the workflows built on top of it.
Real system access, and eight principles that keep it governable
agentctl runs where you decide: your own cloud, your own data center, on-prem. What happens inside it is governed by these eight points.
PrivacyGuard
Before every model call the prompt passes through a filter stage: names, contract numbers and customer data get replaced. The external model sees the task, not the person; the answer is reassembled in house.
Config-Audit
Every change to an agent configuration is logged: who, when, and what applied before. In a review you can evidence last Tuesday's state instead of reconstructing it.
Cost Control
Usage and budget are visible per agent and per person at any time, with limits that bite before an invoice surprises anyone. No line item that only surfaces at month-end.
Governed Skills
Agents work from a reviewed library of tools and workflows, centrally managed. Nobody wires up a tool on their own that IT & security has never seen.
One Owner
Every agent belongs to exactly one person and runs with their rights from the existing account. No shared identity, so no action without an attributable actor.
Model Choice
GPT, Claude, Gemini or a model in your own infrastructure, swappable at any time without rebuilding the agent. The provider is a setting, not a dependency.
Human in the Loop
A decision model holds back actions that are uncertain or consequential and puts them to a person. Routine passes through, the edge case waits for an approval.
Secret Store
Credentials sit encrypted in your own house and are only fetched at runtime. They end up in no prompt, in no log and at no model provider.
Everything an agent can do runs through one control point
Agents are not wired into your systems one by one. They are wired into agentctl, and agentctl is wired into the systems you already run.
- Standard connectors and APIs
- Access you already grant
- On servers you already own
- Nothing is replaced
- Nothing is migrated
- Systems stay as they are
One agent per person, all through the same control point: that is where rights, logging, budget and model choice live. Which is why the eleventh agent costs no new integration.
What actually happens when a task comes in
Not the building blocks: the real flow, step by step.
A task arrives
By email, ticket, schedule, or event in the system, just like for an employee.
Rights are checked
With the inherited identity, no special role, no separate account.
The agent acts in the system
Clicks, types, navigates like an employee, not just a chat reply.
Every action is logged
Timestamp, task, outcome, traceable for audit.
As a real, step-by-step animation
From the inbox to the audit vault, including the moment PrivacyGuard takes the personal data out before anything leaves the building.
Today a human connects the systems. Soon their agent will.
Not a chatbot, not RPA, not a custom build
Three familiar ways to solve this problem, and where agentctl differs structurally.
| Criterion | Chatbot tools | RPA | Custom build | agentctl |
|---|---|---|---|---|
| Access to real systems | Text answers only | Yes, but rigidly wired | Yes, as built | Yes, like an employee |
| Rights & identity | None | Own service account | Custom-built | Inherited from the real identity |
| Handles exceptions | No | No, breaks | Only what was foreseen | Yes, like a human would |
| Maintenance on UI changes | — | High: scripts break | High: needs its own team | Low: the LLM reinterprets |
| LLM choice | Usually fixed | — | Free, but self-integrated | Free, swappable anytime |
| Time-to-value | Instant, but limited | Weeks per process | Months | Days to weeks |
not a pilot project on paper.
Around 100 users at an IT and digitalization partner to Swiss banks and insurers
The agents run there across several departments, on the employees’ existing identities and inside the house’s own infrastructure.
Built inside a FINMA-regulated fund in Zurich
agentctl was built there because nothing comparable met the compliance requirements. It still runs in production there every single day.
What this looks like in production
Three surfaces from the cockpit: one agent’s inbox, the state of a company’s agents, and a run that is waiting for an approval.
And every one of those actions lands in the log: with timestamp, task and outcome, in the same form as for a human.
Typical tasks, for SMEs and regulated industries alike
Illustrative: the concrete implementation always depends on your real systems and processes.
What security and IT leads ask first
What security and IT leads need to say yes
The FAQ above answers the first questions briefly. Here's the deep dive, no marketing detour.
Data residency
agentctl runs wherever you decide: your own cloud, your own data center, on-prem. There is no requirement to send data to agentctl. The architecture is self-hosted by default. The one deliberate exception: if you use an externally hosted language model (an API-based model instead of a locally hosted one), the prompts & responses of that specific call leave your own infrastructure toward the model provider, whose privacy terms then apply in addition to ours.
A request, step by step
Instead of just claiming it: a real flow, step by step. A request comes in by email, the agent looks up customer data, uses an already learned skill. Before anything leaves the building, PrivacyGuard takes out all personal data; only the redacted request goes to the external language model, the response comes back encrypted and PrivacyGuard puts the data back. Every step lands unchangeably in the audit vault, traceable for IT & security.
PrivacyGuard is the name of that stage in the product, not a setting somebody can forget: without it, no call to an externally hosted model happens at all.
Identity & access
An agent gets no new role of its own. It inherits the rights of the real employee identity on whose behalf it runs, the same permission check as for a human, no additional permission model that would need separate upkeep.
Audit & traceability
Every action an agent takes is logged with timestamp, task and outcome. Because the agent uses exactly the rights of the real identity, it shows up in your existing audit trails just like a human employee. No additional, separate logging system that would first need to be wired into your existing audit pipeline.
For a security review that means: the question "who did this" has the same answer shape for an agent as for a human: one account, one timestamp, one action.
Model choice
agentctl does not lock you into a single LLM provider. Any model can be used: GPT, Claude, Gemini, or an open-weight model hosted locally in your own infrastructure. Switching models only changes which model handles the language processing, not how the agent is built.
That's also a security decision: for especially sensitive use cases you can choose a model that runs entirely within your own infrastructure, with not a single request ever leaving it.
Operational responsibility
Because the default architecture is self-hosted, in most cases your own team operates the infrastructure and chooses/operates the language model. agentctl connects both into an employee, including operational support, but without your data necessarily having to flow through agentctl infrastructure.
Ready for your first use case?
We're happy to show it live, on your own system, with your own data.