News 10 Mar 2026
Admin Companion expands into guard-railed automation and event-driven workflows
With the 6.x versions, Admin Companion has become more than an interactive shell assistant. It introduced ac-ops for guard-railed automation, and Admin Companion Gateway as a separate package for event-driven workflows. Together this makes Admin Companion a platform for three connected operating modes: interactive co-administration, bounded automation, and alert-driven analysis, notifications, and ticketing.
ayonik engineering
From alert sources to analyzed tickets and notifications with policy-enforced automation.
After a quieter period on this blog, we are resuming product updates with the two releases that most clearly changed what Admin Companion is for.
With version 6.0-8, we introduced ac-ops as a major enhancement for server operations and DevOps workflows. With version 6.1-8, we followed that with Admin Companion Gateway as a separate package for event-driven analysis, notifications, and ticketing.
That matters because Admin Companion is no longer best described only as an interactive AI assistant in the shell. It now covers three related but distinct workflow types:
- ai for interactive co-administration
- ac-ops for guard-railed automation
- Admin Companion Gateway for event-driven workflows
What changed in 6.0
Version 6.0-8 added ac-ops as a major enhancement. This is a policy-first automation client for server operations and DevOps, with allowed tools, per-parameter restrictions, bounded built-in tools, optional debug and audit logging, and a separate binary for ops-only automation scenarios.
This is the important shift: Admin Companion now supports automation that is intentionally constrained.
That means:
- Execution can be shaped by a defined use-case
- Tool access can be restricted up front
- Output stays predictable enough for automation contexts
- Operational workflows can be run without opening systems to uncontrolled AI access.
In practical terms, ac-ops is the part of Admin Companion that expands the platform beyond interactive troubleshooting into bounded operational execution.
What changed in 6.1
Version 6.1-8 added Admin Companion Gateway as a separate package and also introduced ac-ops --ssh-restricted for SSH forced-command execution, the mode used by the new Gateway. The same release also improved multi-action confirmations in the interactive client ai.
Admin Companion Gateway is a lightweight webhook receiver and router. It accepts incoming HTTP events, normalizes them based on configurable profiles, and routes them to the appropriate target host and use-case for secure remote ac-ops execution. Depending on the configuration, it returns the ac-ops output directly and/or triggers integrations such as ServiceNow or Slack.
That extends Admin Companion into a third mode of operation: event-driven workflows.
Instead of only starting in a shell session, a workflow can now begin with an external http event, such as a monitoring alert, and still end in controlled analysis and structured downstream output.
A platform for three operating modes
Admin Companion now spans three operating modes: interactive, automated, and event-driven workflows.
ai
ai supports human operators in interactive troubleshooting and back-and-forth investigation. With a human-in-the-loop security layer, it requires explicit confirmation before execution.
ac-ops
ac-ops provides policy-enforced automation for server operations and DevOps workflows. It is the execution engine for use-case-driven automation with restricted, least-privilege execution boundaries.
Admin Companion Gateway
Admin Companion Gateway allows external systems to trigger analysis and downstream actions through configuration rather than custom glue code. It is the intake and routing layer for webhook-driven workflows.
What this changes in practice
A lot of operational work does not begin with a person typing into a shell. It begins with an alert, an event, or a system-to-system handoff.
That is where the 6.0 and 6.1 releases fit together:
- 6.0 introduced the guard-railed execution through
ac-ops - 6.1 connected that execution model to incoming events through Admin Companion Gateway
The result is a broader Admin Companion platform:
- Interactive where human judgment should stay in control
- Automated where workflows need bounded execution
- Event-driven where http alerts should become analyzed notifications and tickets
Where to go next
- Read the current documentation for client versions 6.0+ and Admin Companion Gateway version 1.0.
- Go to the downloads page for client and gateway software.
Read more
A practical walkthrough showing how Docker alerts can be routed into Slack with AI-assisted first analysis, recommended action, and guard-railed operational triage.
A Linux service fails, an alert fires, and the default reaction is often to restart it immediately. That is frequently the wrong first move. When a service managed by systemd enters a failed state, the first priority is not action but understanding: what failed, when it failed, what changed, and whether a restart is safe or likely to destroy useful evidence. A disciplined first-pass investigation reduces guesswork, avoids unnecessary blast radius, and helps operators distinguish between a service problem, a dependency problem, and a wider host-level issue.