A self-hosted agent system has a locality problem. Everything runs on one machine at home, which is the point, but you are not always sitting at that machine. And the agents, however capable, could only touch what lived on that box. The last three releases (0.1.12 to 0.1.14) attack both sides of this with a new Tools section in the sidebar and its first two connectors: Telegram, so you can operate your agents from anywhere, and GitHub, so your agents can operate on your repositories. Opposite directions, same security model.

Tools are not add-ons. An add-on is a capability an agent uses (search the web, read a page, fetch a YouTube transcript). A tool in this new section is a connector between HydraOps and an external service, with its own card, its own credential and its own on/off switch.

Telegram: your agents in your pocket

The setup is the usual Telegram bot dance: create a bot with @BotFather, paste the token into Tools, generate a pairing code, flip the toggle. Then from your phone you send /start <code> to your bot and you are talking to your agents:

/agents lists them.
/elena summarize this sends a one-off message to that agent.
/use elena makes her the active agent; plain text goes to her from then on.
With a default agent configured you can skip all of the above and just type.

Under the hood the bot is one more service in the stack, next to the workers. It long-polls the Bot API with plain fetch, no Telegram library, relays your message as a normal task and polls for the reply. It starts with the desktop app and with server mode, shows up in the System view and hot-reloads its config, so enabling it or changing the token takes effect in seconds without a restart. Replies keep their formatting: fenced code arrives as a real monospace frame, so asking a coding agent for a snippet reads fine on a phone.

Access control is an allowlist of Telegram user ids plus the pairing code. Your bot's username is public by nature, so anyone can open a chat with it; without pairing, the bot ignores them. Regenerating the code invalidates the old one.

The part I actually wanted: the box pings my phone

HydraOps has had scheduled tasks for a while: cron rules that wake an agent to do something on a schedule. Until now the results waited politely in the app. Version 0.1.13 closes the loop: when a scheduled task finishes, the bot pushes the result to every paired chat.

The plumbing was already half built. Every worker publishes an agent.result_generated event on NATS when a task completes; nothing consumed it. Now the bot subscribes, checks whether the task came from a cron, deduplicates so you get exactly one message, and sends the full result. A toggle on the Telegram card ("notify on scheduled task") turns it off if you would rather poll.

This is the configuration I run: HydraOps on a small always-on box, a morning cron that gathers what I care about, and the result on my phone before I sit down. No cloud service in the middle.

GitHub: hands for your agents

The GitHub connector points the other way. You connect a fine-grained Personal Access Token in Tools, and agents get a github tool with nine curated operations: list repositories, read a file at any ref, list and read issues, open an issue, comment on issues and PRs, list and read pull requests (with the changed-file list), and search with GitHub's own query syntax. For everything else there is github_api, an escape hatch that calls any REST endpoint by method and path.

Two design decisions matter more than the operation list:

The token is the permission system. Fine-grained PATs already let you scope access to specific repositories and to read or write per resource, enforced by GitHub itself. HydraOps does not reimplement that. Give the token read-only scope and every write from every agent is a 403, no matter what the prompt says. The tool translates those failures into messages a model can act on ("your token's scope may not allow this operation") instead of raw API errors.

Responses are shaped, not dumped. GitHub's raw JSON is enormous; a single repository object is a few kilobytes of URLs a model will never call. Each curated operation returns a compact projection with only the fields that matter, and everything is capped before it reaches the context window. Your agent reads issues, not payloads.

Same firewall, two new tenants

If you read the credential firewall post, you know where this is going. The workers in HydraOps never hold provider API keys; a tiny local proxy injects them at the network boundary. The Telegram bot token and the GitHub PAT go through exactly the same machinery.

The github tool never sees the token. It calls the local key-proxy under a /github/... prefix and the proxy writes the Authorization header from the key store, outside the project tree, at the last possible moment. A prompt-injected agent that dumps its environment finds the same seven letters as before: proxy. As a safety net, the tool guard also redacts GitHub token shapes from any tool output.

Not every agent gets GitHub

Handing repository access to a swarm of agents deserves more than a global switch, so 0.1.14 made tool gating strict and per-agent. An agent can call a tool only if that tool is granted in its own configuration, and the check is enforced in all four workers, not suggested in a prompt. Your research agent can search the web and never touch GitHub; your repo agent can triage issues and never run anything else.

The same release added per-agent tool usage tracking: for each agent you see which tools it is granted and which it has actually called. Granted-but-never-used is a prompt to prune. And a fresh install now starts empty, no default agents and no preconfigured tools, so whatever can reach your repositories is something you connected yourself.

What this does not do

Honesty section, as usual:

Messages to a Telegram bot are not end-to-end encrypted. They transit Telegram's servers like all bot traffic. The connector is for convenience; the fully private path is still the app on your machine.
The pairing code and allowlist keep strangers out of your agents, but the bot token itself is as sensitive as any API key. It lives in the key store for that reason.
On GitHub, the firewall protects the token, not your judgment. A PAT with write scope lets an agent write. Start read-only and widen scope when a workflow earns it.

Both connectors are documented in the Tools chapter of the manual, and the code is where it always is: the bot service and the GitHub tool, Apache 2.0. Discord, Signal and Reddit are on the same shelf, marked coming soon.

HydraOps is a self-hosted multi-agent AI system: one chat, several agents with their own personality, model and tools working on tasks in parallel. Try it here.