Your team asks the servers.
The servers answer.
A private AI assistant that lives in your Discord or Slack. It answers questions from your own documentation, checks your servers, explains why the pipeline broke, and restarts what you allow it to — without handing anyone an SSH key.
qa-test is at 91% disk — that is your slowdown.
/dev/vda1 78G 71G 6.2G 91% / → /var/log/nginx/access.log 14G → /var/www/qa/storage/logs 9GLog rotation is not running. Want me to show the logrotate config?
Error: composer install exited 1 → requires ext-gd, missing on runner imageSame failure as run #402 last Tuesday. The fix is adding
gd to the setup-php step. I can re-run it once that lands.🚫 Refused — destructive command blocked by policy. This request never reached the server.
One person has the keys. Everyone else waits.
Most small teams run infrastructure the same way: a single engineer holds the SSH access, and every routine question turns into an interruption.
"Can someone check the server?"
A developer needs to know if a service is up, a disk is full, or a log has an error. They cannot look themselves, so they wait — sometimes hours, sometimes until morning.
Root access is the only lever you have
The alternative to waiting is handing out server credentials. There is nothing in between full access and none, so teams pick the risky option and hope.
The documentation nobody reads
Deploy steps, environment quirks, that one command you run after a release — written down somewhere, findable by no one. So the same three questions get asked every month.
Three jobs, one assistant, zero new tools to learn
Your team already lives in a chat window. The assistant works there — mention it, ask in plain language, get an answer in the thread where everyone can see it.
Answers from your docs
It reads your runbooks, deployment notes and internal wiki, then answers questions grounded in them — not in whatever a general chatbot guesses.
- Trained on your documentation, not the internet
- Teach it new facts mid-conversation
- Says "I don't know" instead of inventing
- Knowledge stays separated per channel
Eyes on your servers
Connects over SSH to the hosts you nominate and runs the checks you would run — then explains the output instead of dumping it.
- Disk, memory, load, service status
- Tail and interpret error logs
- Restart allowlisted services only
- Run named app commands, in named apps
Pipelines, explained
Reads your GitHub Actions history, finds the actual failing step, and tells you what broke in a sentence — not a 4,000-line log.
- "Why did the last QA run fail?"
- Spots repeat failures across runs
- Re-run or cancel workflows on request
- Locked to your organisation's repos
The AI does not decide what it is allowed to do
Anyone can wire a chatbot to a server. The engineering is in what happens when someone asks it to do something stupid. Every rule below is enforced in code, before the model is ever consulted — so a clever prompt cannot talk its way past them.
Destructive commands blocked in code
Database drops, wipes, recursive deletes, disk formatting, reboots and shell redirects into system paths are rejected by a hard-coded filter. The request never reaches the model, let alone the server.
Allowlists, not blocklists, for anything that changes state
Restarts work on a named list of services. Server access is limited to a named list of hosts. Repository actions are limited to your organisation. Everything outside those lists is refused by default.
Two gates before anyone reaches a server
Operational commands only work in the private channels you designate, and only for the specific user IDs you approve. Everyone else can use the assistant for questions and gets a polite refusal for anything else.
A dedicated key you can revoke in one line
The assistant connects with its own SSH key, not a copy of anyone's personal one, and runs as an unprivileged user on its own isolated server. Removing one public key cuts off all of its access, instantly.
Everything happens in public
Every command and its output is posted in the channel. There is no hidden execution path, so the team gets an audit trail for free and mistakes are visible the moment they happen.
Your data can stay on your hardware
The language model is pluggable. Use a hosted model for best quality, or run an open model on your own machine so that no server output, code or document ever leaves your network.
From first call to live in your channel
No long discovery phase. Most of the work is agreeing what the assistant may touch, and proving the guardrails hold before it sees production.
A call, and an honest answer
Twenty minutes on what your team actually asks each other all day. If a bot is the wrong fix for it, I will tell you that instead of selling you one.
Scope the boundary
We write down which hosts it may reach, which services it may restart, which channels it lives in and which people can command it. That document becomes the configuration — nothing is left to interpretation.
Build and load your knowledge
Deployment onto a small server in your own cloud account, your documentation loaded and indexed, chat app connected, dedicated access key issued.
Try to break it, on staging
I run the destructive requests at it deliberately — the drops, the wipes, the out-of-scope repositories — and show you each one being refused before it goes anywhere near production.
Live, then watched
Production access enabled, a short session so the team knows how to talk to it, and the retainer starts: monitoring, updates, new knowledge and new commands as your infrastructure changes.
No migration, no new platform
The assistant adapts to your stack rather than the other way round. If your team can SSH to it or call it over an API, it can be wired in.
Chat
Servers & platforms
Apps & pipelines
The model behind it
The questions everybody asks
Stop being your team's terminal
Twenty minutes, no slides. Tell me what your team keeps asking you, and I will tell you straight whether this solves it — and what it would cost.