Human-in-the-loop for DevOps and SRE agents

The on-call engineer is not at the terminal.

Your agent stops before the risky change, and Pushary gets the on-call engineer's answer back fast.

How does an AI DevOps agent get approval from an on-call engineer?

Pushary lets an AI DevOps agent get approval from the on-call engineer on their phone. Put one Pushary call in front of the migration, the restart or the scale-down. The engineer taps Approve or Deny on the lock screen. Your agent waits for the answer. If nobody answers in time, the change does not run. Every answer is saved with who decided and when, ready for the incident review.

What needs a yes

The calls that should not be automatic

runMigration(name): A migration you cannot cleanly reverse is the classic action worth waking someone for. It is also the classic action an agent will happily run at 02:00.
scaleDown(service, replicas): Cutting capacity during an incident you have misdiagnosed turns a slowdown into an outage, and everyone feels it.
rotateSecret(name): Rotating a credential fixes one problem and can break every service that cached the old value. That takes judgment, and a threshold cannot supply it.
deleteResource(arn): Cleanup agents are useful right up to the moment one deletes something that looked idle and was load bearing.
promoteToProduction(sha): Shipping is the step where your users pay for a mistake, instead of a test suite catching it.

The code

One call inside the step you already have

Wrap the action, not the whole agent. Everything the agent does that is safe keeps running without asking anyone.

bash

pip install pushary

one call

import os
from pushary import PusharyServer

px = PusharyServer(api_key=os.environ["PUSHARY_API_KEY"])

def remediate(incident, plan):
    # Read-only diagnosis and reversible fixes run unattended.
    if plan.reversible and plan.blast_radius == "single-pod":
        return apply(plan)

    decision = px.decisions.ask(
        external_id=incident.on_call_id,
        type="confirm",
        question=f"{plan.summary}\nBlast radius: {plan.blast_radius}. Reversible: {plan.reversible}.",
    )

    if not decision["approved"]:
        return page_secondary(incident, reason="human declined automated remediation")
    return apply(plan)

Who answers

The approver is not at a desk

The approver is whoever is on call, and being on call means you are not at a terminal. Most remediation agents post the request in a chat channel. That works if the engineer is in the channel with notifications on. The rest of the time it fails quietly: the change is correctly blocked and the incident keeps burning. Pushary reaches the on-call engineer's phone, by the id your rota uses.

We already post approvals to Slack. What is different?

Slack is a good place to see a request and a bad place for a run to depend on. The message arrives whether or not the right person is looking. Your code gets no answer it can wait on. Nothing stops the change if nobody replies. So you end up building the missing half yourself: a poller, a timeout, state that survives a deploy in the middle of an incident, and a record of who clicked what for the review. Pushary is that half, as one call that returns an answer. If your team lives in Slack, the request can still go there. Either way, every answer is saved in one place instead of scattered across channel history.

Worth reading: Google's SRE book on release engineering and change management.

$99/ month, Partner plan

Add it to your product. Your users never make a Pushary account or pay us.

What the Partner plan covers

FAQ

Questions, answered

Does the wait survive a deploy in the middle of an incident?

The request does, but the wait inside your process does not. Pushary keeps the pending request on its side, so restarting your service does not lose it. Save the decision id before you deploy. When the engineer answers, pick the run back up from the signed webhook or by polling. That matters most when you are shipping fixes while a remediation agent waits for an answer.

Can approval route to a rota rather than one person?

Yes, through your own rota logic. You pass the user id of whoever should decide, and Pushary reaches that person. If nobody answers, the change does not run and your agent can page a secondary. That is the same escalation shape you already use for alerts.

How do we keep from paging someone for every trivial change?

Gate on reversibility and blast radius rather than on importance. Anything you can cleanly undo runs now and gets reviewed after. Anything you cannot undo asks first. That keeps the queue short, so the requests that do arrive get read properly instead of approved on reflex.

What do we hand an auditor afterwards?

The saved record of each request. It holds the question as asked, what the engineer saw, the answer they gave and when. You can query and export it. Pushary keeps it for your plan's history window: 90 days on Partner Launch, 365 on Partner Growth. Add a callback URL and each answer is also sent to your server as a signed webhook, if you want a copy in your own evidence store.

Human-in-the-loop for other products

Human-in-the-loop API See the Partner plan travel and expense agents customer support agents AI SDR and outbound agents legal AI agents finance and accounting agents healthcare AI agents insurance AI agents security and SOC agents

Put a person on the step that needs one.

Connect a user once, ask with one call, and run the action only on a yes. Every answer is saved.

Start free