Respond to incidents together.
When your IRM fires an alert, an agent joins your team’s incident chat. It queries your telemetry, reads the code, reports what it finds, takes direction when you mention it, and ships the fix while you watch.
- Response
- None
- Run
- None
- Patch
- None yet
- Alert
- Quiet
One more responder, in the room with you
Alerts open a response, and the agent works in the open: it reports in the chat, and anyone there can point it somewhere else.
Works with any IRM
An alert webhook opens a response. Later alerts join the same response instead of starting new runs.1
Reads your real telemetry
The agent queries your metrics, logs and traces through the MCP gateway, with only the tools you allowed. The credentials never enter its pod.
Mention it to steer it
Anyone in the incident chat can reach the agent mid-task. Messages arrive as untrusted text, so they can’t widen what the run is allowed to do.2
Fixes ship mid-incident
The agent submits patches while it works, and hears when each pull request is merged or closed.
Start work from chat
Outside incidents too: mention an agent in a chat command room to start a run. It answers in the thread and takes follow-ups until it’s done.3
Write-ups your team can open
Ask the agent to write up what it found, and it publishes a timeline or report as a page in Ryph and links it in the incident chat.4
- The sender needs to support HMAC-SHA256 signing, Standard Webhooks signing or a shared secret header. Incident chat runs in a linked Telegram group, Zulip topic, Slack channel or Discord thread. Later alerts about the same alert group or incident join its open response; alerts without a key, and Telegram rooms, share one response per automation. The default rate limit is one alert per minute, and alerts over it are refused rather than joined. Resolved alerts are recognized from every built-in sender except Sentry issue alerts, which don’t send one.
- Payloads and chat messages cannot change a run’s granted permissions. They are framed as untrusted context for the model, which is a prompt-injection mitigation, not a guarantee that the model will ignore malicious instructions. Each fire uses the current recipe and agent blueprint.
- Command rooms are set up by an admin, with an hourly limit on new runs. In a public channel, agents can only be asked to work on public repos. Slack and Zulip rooms can limit commands to a user group, and Discord rooms to a role; in a Telegram group, everyone can command. Runs started from chat, a /ryph comment or an incident stay open for follow-ups until they go idle; runs started from the web app end when the agent does.
- Everyone signed in to the instance can open every artifact, including people who can’t see the run, the agent or the repos it read. Turning publishing on for an agent takes the permission to change agent policies. The agent posts a link only when Ryph knows its web app’s address; otherwise the page is listed under Artifacts. Comments on pages aren’t supported yet.
More of Ryph
- Automations Recipes that run on a schedule or when a webhook fires.
- Forges and chat Summon an agent with /ryph on an issue, a pull request or a merge request.
- Artifacts Reports and overviews agents publish as pages your team can open.
- Memory What agents learn, shared and kept current with the code.
- Agentic CI One CI for agents and the people working with them. Pull requests open already green.
- Security Keys stay behind gateways, and work leaves as a patch.
- Environments Images built for your repo, and services for every run.
- Deploy One binary on a laptop, or your own cloud.
Try it on your own machine.
One binary with the web app and database built in.
Get started