Product
A support engineer that reads first and asks before it acts
Cerberius Agents takes each support ticket, looks into it across the systems you connect, and hands your team the cause, the evidence and a draft reply. It works for a product you run, your clients' systems or your own company's IT. Here's what it does, what it connects to, and where a person decides.
Investigation
Looks where an engineer would look
When a ticket arrives, the agent starts at once. It only reads, with its own read-only tools. It has no shell or web browser, and it can't run your code. If you give it its own machine, it can also run checks there (see below). It usually takes a few minutes.
| Source | What the agent can do | Set up with |
|---|---|---|
| Your code | Search and read files in the repositories you add, downloaded fresh for each run, with their latest 30 changes. With read access to Actions or pipelines, see whether a build passed or failed, and why. | GitHub or GitLab (including your own GitLab server), with a read-only token. |
| Kubernetes | List and read workloads, pods, events and pod logs. If you list namespaces, only those. Never Secrets. | A self-contained, read-only kubeconfig. The help centre has the exact role to apply. |
| Loki logs | Search your logs with LogQL, up to the last 7 days and 1,000 lines per search. | Your Loki address, with a token or username and password. Grafana Cloud works. |
| Databases | Look at tables and run one read-only query at a time, at most 200 rows, inside a read-only transaction (on SQL Server, one that is always rolled back; MongoDB is asked in JSON, and each query is checked to only read). | A read-only login for PostgreSQL, MySQL, MariaDB, Microsoft SQL Server (Azure SQL too) or MongoDB (MongoDB Atlas too). Several servers, of any of these kinds. |
| Microsoft 365 | Read users, sign-ins and why they failed, licences, groups, mailbox settings and Intune devices. It gets a pass that lasts about an hour, never the secret. Sign-in logs need Microsoft Entra ID P1 or P2. | An app registration in the client's Microsoft Entra admin centre, with the read permissions you choose. |
| Google Workspace | Read users, sign-ins, groups, licences and devices, acting as an admin you choose, within the scopes you allow. | A service account with domain-wide delegation. The help centre walks through every click. |
| DNS at GoDaddy | Read the DNS records of the domains you list for the platform. It checks the name servers first, and says where to make a change if the domain's DNS is run elsewhere. | A GoDaddy key, and the list of domains this platform may use. |
| The ticket | Read the ticket, the requester's follow-ups and attachments. For tickets imported from HaloPSA, the whole conversation, including your team's replies and private notes. | One of the ticket systems below, your own through our API, or the log watcher. |
It works like an engineer on call
It lists the likely causes and tests each one, looks at what changed and when, and finds who changed it in the logs it can read. When a tool refuses, it names the permission that's missing.
It learns your system from your notes
Tell it what each repository does, where things run, who the client is, which log labels matter and what your words mean. It reads these notes before every investigation.
It keeps to the requester's account
Name the field that identifies an account, and the agent only looks at, and only talks about, that account. Your database login sets the hard limit.
The ticket page
Everything that needs a person, on one page
Each ticket that needs someone lands in the platform's queue. Open it and it's all on one page: what waits for you, what happened, and a box to write in. You act right there, never in another tab.
Waiting for you
- Now: what to decide now, numbered. Each item says why, and what happens after you act.
- Can wait: what the agent says can wait, with its reason.
- Each thing the agent proposes is decided on its own: the reply, a change to a live system, a code fix or closing the ticket. Approve it, edit it first, or skip it.
- When a live change and a code fix would both work, they sit side by side with their pros and cons, and the one the agent would choose.
- Its questions to answer, and jobs only a person can do, as a list to tick off.
What happened
- The whole story in plain words, from the ticket arriving to the last reply.
- The root cause, how confident the agent is, and the evidence: the exact file, log line or record.
- Every step it took, with times in your platform's time zone.
- What the AI has cost on this ticket, next to the limit you set.
- A vote on whether it found the right root cause. Votes feed the platform's metrics.
Write
- To the agent: answer it, correct it or point it somewhere else. It works again.
- To the requester, through their ticket system: your own reply, or an update while the fix is still being decided.
- Edited replies are kept next to the agent's version in the history.
It looks again after each step. When a change has run, a fix is merged or the requester writes back, the agent checks the ticket again. It says whether what it proposed is still needed, and what's left.
Automatic replies, only if you want them
By default every reply waits for a person. An owner or admin can choose another mode for a platform, and untick one box to stop all automatic replies at once.
| Mode | What happens |
|---|---|
| Off | Every reply waits for approval. This is the default. |
| Acknowledge only | A fixed message you write goes out when a ticket arrives. The real answer still waits. |
| Answer automatically when confident | The reply goes out without approval only when it meets your confidence level and ticket kinds, and passes a fixed content check that doesn't use AI. |
Code fixes
Fixes arrive as pull requests. Nothing merges until you say so.
When the agent finds a bug and knows how to fix it, it adds a proposed fix to its reply: what it would change, in which repository, which files, and how risky it thinks it is.
- 1
An approver reads the proposed fix and approves it.
- 2
The agent edits files in that one repository. It doesn't run the code or its tests.
- 3
The service, not the agent, puts the change on a new branch and opens a pull request on GitHub or a merge request on GitLab. Its description names the ticket and who approved it. A later fix on the same ticket and repository is added to that pull request, never opened as a second one.
- 4
The agent drafts a follow-up reply for the requester, which waits for approval like any other.
- 5
Your team reviews and tests the pull request the usual way. It's merged only when an approver presses Merge on the ticket, or asks for it in the conversation. The service merges it, never the agent. Then the agent looks at the ticket again.
Write access stays with the service
The repository's write token is used only to open and merge the pull request. The agent never receives it.
Pipelines are off limits
A fix can never change CI or git settings, such as
.github,.gitlab-ci.ymlorJenkinsfile.
Changes to systems and accounts
When the fix is a change, it asks first
Sometimes the answer is a wrong row in a database, a stuck service, a blocked sign-in or a missing DNS record, not a bug in the code. The agent can propose the exact change. A person sees exactly what will run, can edit it first, and nothing runs until they approve it.
| Kind | What the agent may propose | How it runs after approval |
|---|---|---|
| Database | Exact INSERT, UPDATE or DELETE statements (on MongoDB, the same as JSON operations), with the most rows they may change. | In one transaction, with a separate change login. If more rows would change than agreed, everything is rolled back. |
| Kubernetes | Restart or scale a deployment, delete a stuck pod, patch or create an ordinary object, or run a scheduled job now. | Tried first as a dry run. If any step fails the trial, none runs. Never Secrets, service accounts, permissions, namespaces, nodes or network policies. |
| Microsoft 365 | Exact requests, such as unblocking a sign-in, adding someone to a group or assigning a licence. | Reads every user or group it touches first. If one can't be read, nothing runs. Then sends the requests in order, and stops at the first refusal. Never apps, admin roles or policies. |
| Google Workspace | Exact requests, such as unsuspending a user or adding them to a group. | The same as Microsoft 365. Never admin roles or privileges, or anything that hands out keys. |
| DNS at GoDaddy | Exact A, AAAA, CNAME, MX or TXT records to add, set or remove, on the platform's own domains. | Reads those records first, then makes each one in order. Never name server records. Any other domain is refused. |
Edit before approving. An approver can change any part of a change, leave a step out or add one. Their edit is checked exactly like the agent's, and what they approve is what runs. New Microsoft 365 and Google accounts get a long random first password that nobody sees.
Nothing made up. Every address, name or ID in a change is looked up by the agent or given by a person. When a requester asks for something a small change would do, the agent proposes it for you to decide, rather than only telling them how to do it themselves.
Three gates before anything runs
- 1
Cerberius makes the kind of change available to your organisation.
- 2
An owner or admin switches it on for the platform, and accepts the terms once for the organisation.
- 3
A person approves each change, one at a time, after reading exactly what will run.
Its own machine
Checks of its own, only if you want them
An owner or admin can give the agent its own machine on a platform: a separate computer for each ticket, where it runs checks such as looking up a domain's mail records, testing a mail server or checking a certificate. It's off until you switch it on.
Holds none of your keys
It can't reach your code, cluster, logs, databases, Microsoft 365 or Google Workspace. Those stay with the agent's read-only tools.
Every command on the record
Each command and what came back shows on the ticket. The machine is removed when the agent finishes, and it's never there while the agent writes a code fix.
Internet only if you allow it
With the internet on, it reaches public websites and servers, never your private network. A ticket written to trick the agent could then get it to send what it read to an outside address. Switch it on only where the checks are worth it.
Log watcher
New errors become tickets on their own
Switch on the log watcher and it checks the platform's Loki logs every 5 minutes. Each new, distinct error becomes one ticket, and the agent investigates it straight away.
One ticket per error
It recognises the same error again even when times, IDs or numbers differ. Repeats add to the count instead of opening new tickets.
A daily limit you set
Choose how many new errors are investigated per day. Errors past the limit still get a ticket, held until someone starts it.
Closes when it goes quiet
A ticket can close by itself after the number of quiet days you choose, and opens again if the error comes back.
It never replies to anyone outside your team. The useful result is the agent's findings and, if you approve one, a fix. You can also write your own LogQL query instead of the built-in error filter.
Chatbots
A help chat for your website and customer portal
Visitors ask a question and get an answer in seconds, written only from help pages you choose. Each platform can have several chatbots, each with its own look and instructions.
What it does
- Reads your help website (up to 400 pages per source) or a Markdown help file, and reads it again every night.
- Shows where each answer came from, and says it doesn't know when your help pages don't cover a question.
- Inside your portal, can talk about the signed-in customer's own account, from a short summary your server signs.
- Installs with one line of code, and only shows on the websites you list.
- Lets you set the title, greeting, colour, corner, logo and suggested questions.
What it won't do
- See your code, databases, logs or any other account.
- Make up features, prices, policies or contact details.
- Change anything, such as bookings, orders or payments.
- Accept passwords or card numbers. It tells visitors not to share them.
Chatbots answer with Claude or OpenAI models, using your own key. You set a daily question limit, and each visitor is rate-limited too. Every conversation is kept so you can see what people ask and where your help pages have gaps.
Ticket systems
Tickets come from the system your team already uses
Each platform connects one ticket system. New tickets and the requester's replies come in with their files, and approved replies go back on the ticket they came from. Eleven systems connect with a key or login from that system, with no code to write. Any other can connect through our API.
Service desks and help desks
There's a requester to answer. You choose, per platform, whether an approved reply goes straight to them or stays as a private note your team sends on.
HaloPSA
Service desk
A client ID and secret from Halo, then one webhook in Halo.
- Comes in
- New tickets and the requester's replies, for the Halo clients you tick. Older tickets too, when you import them.
- Approved replies
- An email from Halo to the requester, or a private note your team sends on.
ConnectWise PSA
Service desk
An API member's keys and a client ID. We then set up ConnectWise to tell us about new tickets.
- Comes in
- Service tickets and the contact's new notes, for the companies and boards you tick.
- Approved replies
- A discussion note ConnectWise emails to the contact, or an internal note.
Autotask PSA
Service desk
An API user. We then set up Autotask to tell us about new tickets.
- Comes in
- Tickets and the contact's replies, for the companies and queues you tick.
- Approved replies
- A note the contact sees in the client portal, or an internal note. One workflow rule in Autotask emails it to them too.
Zendesk
Help desk
An OAuth client from Zendesk, then a webhook and a trigger in Zendesk.
- Comes in
- Tickets and the requester's public replies, for the organisations you tick.
- Approved replies
- A public reply to the requester, or a private note.
Freshdesk
Help desk
An agent's API key, then two automation rules in Freshdesk, which need its Growth plan or above.
- Comes in
- Tickets and the requester's replies, for the companies you tick.
- Approved replies
- A reply Freshdesk emails to the requester, or a private note.
Jira Service Management
Service desk
An Atlassian API token, then a webhook in Jira. Jira Cloud only.
- Comes in
- Requests and the customer's public comments, for the service desk projects you tick.
- Approved replies
- A public comment Jira tells the customer about, or an internal note.
ServiceNow
Service desk
An integration user or OAuth client, then one business rule in ServiceNow. We give you its script to paste.
- Comes in
- Incidents and the caller's additional comments, for the companies you tick.
- Approved replies
- An additional comment the caller sees, or a work note.
Zoho Desk
Help desk
A Self Client from Zoho's API console, then a webhook in Zoho Desk, which needs Professional or Enterprise.
- Comes in
- Tickets and the requester's emails, for the departments you tick.
- Approved replies
- An email from Zoho Desk to the requester, or a private comment.
Issue trackers
Your team's own list of work. Replies and the agent's findings are comments on the issue.
Jira
Issue tracker
An Atlassian API token, then a webhook in Jira. Jira Cloud only.
- Comes in
- Issues and the reporter's comments, for the projects you tick.
- Approved replies
- A comment on the issue. Jira has no private comments, so everyone who can see the issue sees it.
Linear
Issue tracker
A personal API key, then a webhook in Linear.
- Comes in
- New issues and their author's comments, for the teams you tick. If you like, only issues with one label.
- Approved replies
- A comment on the issue, which everyone in your workspace who can see the issue sees.
YouTrack
Issue tracker
A permanent token, then YouTrack's Webhook Triggers app. In the cloud or on your own server.
- Comes in
- New issues and the reporter's comments, for the projects you tick.
- Approved replies
- A comment on the issue, or a note only your team's YouTrack group sees.
With each of these systems
Each platform takes its own share
Tick the clients, companies, organisations, departments, projects or teams whose tickets come to this platform. Two platforms never take the same one, so one service desk can serve a platform per client.
Findings for your team, if you want them
When a reply is ready to approve, the agent's findings can go on the ticket for your team. Off at first. In a service desk they're a private or internal note. In an issue tracker they're a comment that everyone who can see the issue sees, unless you choose a team group in YouTrack.
Kept in step
A requester's reply there reaches the agent as a follow-up. Closing a ticket there stops the work here. Closing it here closes or resolves it there.
Older tickets
Tickets opened from the moment you connect come in by themselves. From HaloPSA you can also import older tickets with their whole conversation. Start the agent on some now, and leave the rest as Not started.
Your own system, through our API
For any other ticket system, or one you built. A developer on your side connects it, with the full guide in the help centre.
Tickets in
Your system sends new tickets, follow-ups and closes with an API key. Sending the same ticket twice is safe: it's matched on your own ticket ID.
Replies out
Approved replies are posted to your webhook, signed to the Standard Webhooks specification. Failed deliveries are retried for about 24 hours.
Status updates
An optional second webhook tells your tools when the agent starts, when a draft is ready, when a reply was sent and more.
Your own approval screen
With the right API key, your own tools can list drafts, approve or reject them and talk to the agent, instead of using our app.
{
"external_id": "T-1234",
"subject": "I can't download my invoice",
"body": "When I click Download nothing happens.",
"requester": { "email": "[email protected]" },
"metadata": { "account_id": "acc_19" }
}No ticket system? A platform can run on the log watcher alone. Then approving records your decision and nothing is sent.
Platforms, people and keys
One organisation, every product or client you look after
Your organisation holds the people, keys, rules and notification channels. Each product you run, or each client you look after, is a platform with its own tickets, queue, connections, chatbots and settings. The agent working on a ticket sees only that platform's systems.
Roles
Owners and admins set things up and see every platform. Approvers approve replies, fixes and changes. Viewers look. Approvers and viewers see only the platforms you give them. Sign in with Google, Apple or a code by email.
Key library
Add Claude, OpenAI, GitHub and GitLab keys once. Each platform, repository and chatbot picks the key it uses. Keys are never shown again.
Rules
Write instructions every agent and chatbot follows, like tone or words to avoid. Our safety rules always come first.
Notifications
Telegram chats and Slack channels hear when a reply is ready, a change needs approval or an investigation failed.
Metrics and limits
Each platform shows replies sent without edits, time to findings and cost per ticket. It also caps the cost per ticket, minutes and steps per run, and how many tickets run at once.
Phone app
See what waits for you and approve it from your phone, with notifications. On Google Play now. The iPhone app is on the way.
On Team and Business: Development (ask the agent to change your product), the content writer (blog articles from what your product really does) and setup assistants (your customers set things up by chatting).
See it on your own tickets
Early access is open to teams who look after systems, their own or their clients'. Tell us about your setup and we'll get in touch.