ITOps Agent Platform: an LLM multi-agent remediation stack that is mid-refactor

The problem: alerting tools stop at notification

Monitoring stacks tell you something broke. Zabbix and Prometheus both do that well. What neither does is carry the incident to its end: someone still has to read the alert, log in, work out which host or service is actually at fault, pick a fix, apply it, and confirm the fix held. The README frames the gap in time terms, describing a night-time CPU spike that turns into a 30 to 60 minute manual loop of VPN, SSH, command archaeology and report writing. The platform's stated target is that same loop compressed into an alert, an automated root-cause diagnosis, a generated remediation command, a phone approval, an execution and a verification report. The intended audience is spelled out in a table: operations engineers woken at night, SRE and DevOps staff moving between disconnected tools, IT managers who want scheduled inspection and self-healing policies, small and mid-sized IT teams that cannot justify commercial software, and compliance teams that need approval and audit trails on every remediation action. That last row is the interesting one, because it is the constraint that shapes the architecture rather than a feature bolted on afterwards.

Twelve agents, ten workflows and a human in the approval path

The badge line on the repository counts 12 agents, 68 API routes, 72 services, 63 frontend pages and 10 workflows, on React 18, TypeScript 5.7 and Node.js 22. Those are counts of surface area, not measures of quality, and the README does not map individual agents to individual responsibilities, so the exact division of labour between them is not something I can confirm from the material. What the README does describe is the pipeline shape: perception, diagnosis, decision, execution, verification. The alert arrives from Zabbix or Prometheus, an agent proposes a root cause, a remediation command is generated, and then the flow stops at a human approval gate before anything executes. The README calls this HITL, human in the loop, and pairs it with full-chain audit logging and command safety filtering. The approval gate is what separates this design from a fully autonomous remediation loop, and it is also what makes the compliance use case coherent: a command that a person approved and a log that records who approved it. The command safety filter is the second control, sitting between the generated command and the executor. The README does not document the filter's rules, so how it distinguishes a safe restart from a destructive command is an open question worth resolving in the source before trusting it.

Getting it running: one shell script, and a warning attached to it

The README's recommended path is a single script fetched from the Gitee mirror:

curl -sL https://gitee.com/IT_Oline/itops-agent-platform/raw/main/deploy.sh -o deploy.sh && chmod +x deploy.sh && ./deploy.sh

That is the only deployment command given in the material. The description mentions Docker deployment, and the release name for v3.1.0 refers to a container virtualisation upgrade, so the script is presumably orchestrating containers, but the README excerpt does not list the compose file names, the environment variables, the ports or the default credentials. Anyone evaluating this should read deploy.sh before running it rather than piping it blind, since the repository is mid-refactor and the script is part of the transitional state. The same caution applies to the AI tooling configuration: the README states that the files under ai-tool-configs/ are derived templates for Cursor, Windsurf, Aider, Continue, Claude Code and GitHub Copilot, and explicitly says they are not the source of truth. The source of truth is AGENTS.md in the repository root plus the .trae/ directory. The README's instruction is to read AGENTS.md first and then copy and adjust the relevant template for your environment, not to copy the defaults directly.

The README tells most people not to deploy this yet

This is the limitation that matters more than any technical caveat. The README opens with a notice that the project is undergoing a full refactor around a 4A architecture framework and domain-driven design, aimed at decoupling business logic from technical implementation. It then states that the refactor is large, that it is in a progressive replacement phase, and that recently pushed code and built Docker images are a transitional state with unverified and tangled dependencies, and are not recommended for direct use. The README's own guidance is that ordinary users should wait for a stable release, while developers able to debug and modify source can work from the source tree and are invited to help fix temporary defects. A second limitation follows from the first: a refactor that decouples business logic from technical implementation, in progress, means the module layout you read today is not the one you will maintain tomorrow. The 72 services and 68 API routes are exactly the kind of surface that a DDD restructuring moves around. For a team that wants to fork and extend, that is a real cost, because your patches will need rebasing against a moving target. The README does not give a timeline or a target version for completion, so the only signal available is the release cadence, and v3.1.0 landed on 2026-06-27 against a last push of 2026-09-07.

Licence: MIT before 2026-05-27, MPL-2.0 after

The repository's licence field reports NOASSERTION, which is consistent with a split rather than a single identifier. The README explains the split directly. Code committed before 2026-05-27 remains under MIT and can be used, modified and redistributed commercially under MIT terms. Code added or modified from 2026-05-27 onward is under MPL-2.0. The README's summary of the MPL-2.0 obligations is that anyone distributing binaries, images or deployment packages containing modified project code must open source the modified source files and preserve the original copyright and licence notices, and must not strip attribution and pass the work off as an in-house product. Internal private deployment and internal modification for own use are permitted, as is paid deployment, consulting and custom development work. What the README says is prohibited is wrapping the source in a thin layer and selling it closed-source as a standalone commercial product or image, and building a competing commercial SaaS on top of it. This is the project's own characterisation, not legal advice, and the practical consequence for an adopter is that the licence applicable to any given file depends on its commit history. If you plan to redistribute a modified build, you need to determine which side of that date each file falls on.

Rundeck and Ansible solve a different half of the problem

The README positions the platform as a domestic open source alternative to PagerDuty, Rundeck, Portainer and vCenter. Rundeck is the closest comparison for the execution half. Rundeck runs job definitions that a human wrote in advance: you decide which commands exist, who may run them, and under what conditions, and the tool handles scheduling, access control and logging. The decision about what to do is made before the incident, by a person. ITOps Agent Platform inverts that. The remediation command is generated at incident time by an LLM, from the alert and the diagnosis, and the human approves a proposal rather than selecting from a pre-authored catalogue. That is the actual difference in approach, and it cuts both ways. The generated-command model can handle a failure mode nobody wrote a job for, which is the whole point. It also means the safety properties depend on the command filter and the reviewer, because there is no pre-reviewed job definition standing between the model and the host. Ansible sits further upstream still, as configuration management rather than incident response. A team already running Ansible with well-tested playbooks has a working remediation path that is deterministic and reviewable; the reason to add this platform is the diagnosis and triage layer above it, not the execution layer below.

Who should adopt it, and what to check before you do

The README's own split is the right one. Developers who can read TypeScript, run the source tree locally and debug it can start now, with the expectation that they will be rebasing against an in-progress DDD refactor and that the README invites them to fix temporary defects. Teams that need a remediation pipeline in production this quarter should not deploy the transitional images, because the README states plainly that they are unverified and not recommended for direct use, and there is no published date for the stable release. Compliance-sensitive organisations evaluating the approval and audit story should read the command safety filter implementation first, since the README names the feature but does not document its rules. Before running deploy.sh, read it. Before configuring an AI coding tool, read AGENTS.md rather than copying from ai-tool-configs/, because the README designates that directory as derived templates rather than the source of truth. And before redistributing anything, establish which files predate 2026-05-27, because that date decides whether MIT or MPL-2.0 applies to the code you are shipping.

Editorial conclusion

Adopt it only if you can read and modify TypeScript source, or if you are willing to wait for the stable release the README promises. Teams that need a working remediation pipeline today should not pull the transitional Docker images, because the README states they are unverified and have tangled dependencies. Before doing anything else, check the licence boundary at the 2026-05-27 commit date and read AGENTS.md rather than the derived templates in ai-tool-configs/.

Official sources

1. Issues
2. Project website
3. qinshihu/itops-agent-platform on GitHub
4. README
5. Releases