Custom Agents
Any SDLC workflow step can be automated with custom agents powered by production context. You describe a task in plain English, choose when it runs and what it can read, and Autoheal executes it on every trigger, grounds its reasoning in your Production Context Graph, and reports back into the tools your team already uses.
Custom agents are created and managed under the Agents area of Autoheal, which shows every agent, its status, its recent runs, and the integrations it touches.
Build a custom agent
A custom agent is an autonomous investigator that runs a repeatable task for you. Unlike a one-off investigation, an agent has a standing trigger, a fixed set of instructions, and a defined set of integrations it is allowed to use. Each run produces a result, a full step-by-step trace of what the agent did, and a place it posts the outcome. When a result needs a human, the agent flags it for review rather than acting on its own.
A custom agent is defined by three parts.
Triggers
A trigger decides when the agent runs. An agent runs whenever any of its triggers fire. You can trigger on:
- GitHub, GitLab, Azure DevOps, Bitbucket code repo events, such as a pull request merged on a specific repository.
- Schedule, for recurring work like a weekly or nightly run.
- Slack or Microsoft Teams, on a message or a mention.
- Webhook, on an inbound POST from any system that can call one.
Instructions
Instructions are the plain-English steps the agent follows each time it runs. For example, a regression watcher might read the merged PR diff, pull error rate, p99 latency, and saturation for the affected services, check Sentry for new error signatures, correlate any metric shift with the deploy timestamp, and summarize the likely cause with a recommended rollback or fix. You also set the reasoning effort per agent: Fast reasoning for quick, well-scoped checks, or Deep reasoning for tasks that need more analysis.
Allowed integrations
Each agent has an allow-list of integrations it may read from while it works. Nothing outside that list is reachable. The list always includes the built-in Autoheal context (your catalog, memories, and skills), which is the production context that grounds every agent's reasoning. Alongside it you grant only the sources the task needs, such as GitHub, Datadog, Grafana, or LaunchDarkly. Some integrations can also be granted write access when the agent needs to post back, such as commenting on a pull request.
What you can automate
Because an agent is just a trigger, instructions, and an integration allow-list, the same building blocks cover work across the whole software delivery lifecycle. A few examples:
| Agent | What it does |
|---|---|
| Release Risk Scorer | Scores each release candidate from CI before deploy and gates risky ones |
| Flaky Test Detective | Watches CI test runs and identifies nondeterministic tests |
| Deploy Canary Verifier | Verifies canary deploys against baseline metrics |
| PR Regression Watch | Checks every merge to main for production regressions and reports back |
| Weekly Jira Hygiene Verifier | Audits the backlog each week for stale tickets |
| Nightly Cost Anomaly Scan | Flags unexpected model-inference and cloud spend |
| Monthly Cloud Capacity Planner | Projects compute, storage, and budget runway |
These span planning, code review, testing, release, deploy, and cost and capacity work. If a task can be described in steps and grounded in your production context, an agent can run it.
Execution, flagging, and posting
Every run is recorded. An execution shows its status (completed, flagged, or failed), the trigger that started it, the integrations it used, its duration, and a result summary such as "Risk score 18, safe to ship" or "3 new flaky tests in the checkout suite". Opening a run reveals the full trace: each step the agent took, the context it loaded, the integrations it queried, and the conclusion it reached.
When a result needs a decision, the agent flags it for a person to review instead of acting unattended. Agents post their outcomes to the destinations you choose, such as a comment on a GitHub pull request or a message in a Microsoft Teams channel, so the result lands where the work is already happening.
Get Started
- Open the Agents area and create a new agent.
- Connect the integrations the agent needs to read from.
- Add a trigger (GitHub event, schedule, Teams message, or webhook).
- Write the instructions as plain-English steps and set the reasoning effort.
- Choose where the agent posts its results, then activate it.