Operations agents
Agents that carry a repeating process through the systems that hold it, and stop at the point a person must decide.
Take this request through the process and stop where an approval is needed.
Each step, what it read or wrote in which system, and the point where it stopped for a person.
Named agents by vertical
What an operations agent is designed to do
A request arrives, and the process around it is known to everyone: check the record, check the entitlement, check the limit, write the outcome, tell the person. It is done a hundred times a week, in four systems, by people who did not join to do it.
The pack is designed to:
- move a request through the process in the order the procedure sets out;
- stop at the step that needs a decision, with everything the decision needs already gathered;
- leave a record of every system it read and every field it wrote.
Agents reach your systems through the MCP servers you connect in the console. A token you enter there is sealed, never shown again, and acts only with the permissions your system gives it; a connector that runs on one of your hosts keeps its token in that host's own connector file.
The primitives it composes
An agent is a model, a set of approved skills, tools and a policy, applied to a scope.
Execution follows the configured host policy. A command can be approved, denied or referred for human review; individual approval depends on that policy.
What it runs on
Skills ship with the release, come from AcTree's signed skill catalogue, or are your own uploads, and each workspace enables or disables each one.
Customer-hosted installations support an identity provider through OIDC with PKCE. Hosted workspace SSO must be confirmed for the agreed deployment.
Host investigations show the commands that ran, their exit codes and output, per host.
Customer-hosted deployments use packaged deployment configuration. An offline deployment requires an accepted bundle, local model and disconnected installation tests.
Bring one question of your own.