# Workflows, agents and Auto-Fix Build workflows and AI agents on a canvas with approval steps, start from ready-made playbooks, and let Auto-Fix turn production errors into pull requests. Workflows automate the work around your telemetry: a trigger starts a run, steps query data, call AI agents and other tools, and a person approves the steps that change things. Auto-Fix is a built-in agent on the same engine that turns production errors into pull requests you review. ## How a workflow is built A workflow is a graph of nodes on a canvas. It starts with a trigger and runs its steps in order, branching where you need it. A new workflow is a draft: its trigger starts runs only after you activate it. | Trigger | Starts a run when | | ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **Trigger manually** | You run it from the canvas. | | **On a schedule** | The interval, daily, weekly, monthly or cron schedule you set comes round. | | **On webhook call** | Another system calls the workflow's webhook, with no authentication, an HMAC signature or a bearer token. | | **On chat message** | Someone sends it a message in its chat pane. | | **On security event** | An alert opens on a monitor with the tags you choose, a triage verdict lands or a case opens. Leave the tags empty to match any monitor. | | **When executed by another workflow** | A parent workflow calls it as a sub-workflow. | | **On workflow error** | Another workflow fails. | Steps include HTTP requests, code, conditions (**If**, **Switch**), loops and waits, actions in other tools such as Slack, Jira, PagerDuty, GitHub or ServiceNow, Tracix operations, and AI nodes. Steps connect to other services with credentials from **Credentials**. ### AI agents An **AI Agent** node plans and carries out a task with the tools you connect to it. It has these connection points: * **Chat Model**, required: the model the agent runs on, such as an Anthropic, OpenAI, Ollama or OpenAI-compatible chat model. Turn on **Fallback model** to connect a second one. * **Memory**: what the agent remembers within a conversation. * **Tool**: the tools the agent may call, such as another workflow, an MCP server, a knowledge base or another agent. * **Output Parser**: appears when you turn on **Return structured JSON**, so the answer follows a shape you define. AI nodes use the model connections your admins add. See [Model providers and the AI switch](https://tracix.io/docs/ai/model-providers). To give agents an MCP server, connect it from **Integrations**, with its tools set to **Read-only** or **All tools**. ## Create a workflow **1. Start a draft** Open **AI & Automation › Workflows & Agents** and select **Create workflow**. You can also ask [Brain](https://tracix.io/docs/ai/brain) to draft one: describe what it should do, and once you confirm, Brain saves the graph as an inactive draft you can open on the canvas. **2. Add a trigger and steps** Select **Add first step…** to pick a trigger, then add the steps that follow it. A node's fields can take values from earlier steps with `{{ }}` expressions, such as `{{ $json.host }}`. **3. Put a person in front of changes** Before a step that changes something, add a **Wait for Approval** node. Set the **Message**, the facts to **Show the approver** and **Who can approve**. People decide in **Executions** with **Approve** or **Reject**. **4. Test, then activate** Select **Run** and check each step's input and output in **Executions**. When the workflow does what you expect, select **Activate** so its trigger starts runs. Running a workflow by hand and deciding its approvals need permission to manage workflows, which admins have by default. > **Some approvals are enforced on every run** > > A workflow that reaches **Network Config Change**, or an MCP server whose tools are set to **All tools**, without a **Wait for Approval** node before it does not run, whatever started it. Actions in other tools with a high impact do not run directly: they file a proposal that a person approves. A **Wait for Approval** node waits 24 hours by default. When the time limit runs out, the run continues as rejected unless you set **When time runs out** to **Continue as approved**. Leave **Who can approve** empty to let anyone who can manage the workflow decide. ## Start from a playbook **AI & Automation › Playbook library** holds ready-made workflows for security, IT operations, engineering and infrastructure teams. Open a playbook to see how it runs and which connections it needs, choose a credential for each or **Connect later**, then select **Install**, or **Install and test** to run it once on sample data. A playbook installs as a draft: nothing runs on its own until you activate it. Playbooks marked **Human approval** include an approval step. Your workflow list also starts with a few inactive drafts, such as **SOC Triage**, **SOC Investigator** and **Threat Hunter**. They run once someone attaches a model credential and activates them. Admins cap what each of these agents may spend per day, and can pin its model, in **Security › Agent Governance**. ## Built-in agents **AI & Automation › Built-in agents** lists the agents Tracix runs in code: **Auto-Fix** and the **SNMP profile generator**, which builds a device profile for SNMP devices that no existing profile matches. You cannot open them in the builder, edit or run them by hand; you see their runs and spend, and change their settings. ## Auto-Fix Auto-Fix takes a production error to a pull request. Brain finds the code behind the error, writes and checks a fix in its own copy of the repository, and waits for an approver. Only then does Auto-Fix open the pull request. It never merges. ### Where errors come from | Source | What it reads | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Trace errors** | Failing spans grouped by service, operation and message, located by the exception stack or `code.*` attributes | | **Browser errors** | Browser and mobile errors from RUM, symbolicated through uploaded source maps | | **Error logs** | Error logs grouped by message pattern and correlated to their trace | | **Infrastructure errors** | Kubernetes workloads that run out of memory, crash-loop or fail probes, and deploys Tracix judged faulty. Fixed by an infrastructure-as-code pull request, a revert or a recommendation, never applied to a cluster | | **CI and dependencies** | CI pipelines failing on a repository's default branch | Trace, browser and log errors are on by default. No source starts fixes on its own until you turn on **Starts fixes on its own** for it. ### Set up Auto-Fix Auto-Fix is off in a new workspace. Open **AI & Automation › Auto-Fix**, which has four tabs: **Fixes**, **Repositories**, **Code hosts** and **Policies**. Admins set it up. **1. Connect a code host** On **Code hosts**, select **Connect GitHub** to use the Tracix GitHub App, or **Connect GitLab with OAuth**. To use a personal token, your own GitHub App, GitHub Enterprise or Azure DevOps Services, open **Advanced: use your own credentials**. Then select **Test connection**. Bitbucket is not supported yet. **2. Choose repositories** On **Repositories**, choose the repositories Auto-Fix may work in. For each one, set the branch, **Paths a fix may edit**, **Paths a fix may never edit**, the services it owns and its **Approvers**. **Run the setup and test commands** is off until you turn it on. **3. Set the policies and turn it on** On **Policies**, choose the model, the approvers, the sources and the limits, then select **Turn on**. If something is missing, such as a code host or a model, the page lists it under **Before it can be turned on**. Some paths are always off limits, whatever your settings: secrets, `.env` files, keys, the `.git` directory and CI configuration. Code fixes also stay out of infrastructure, deploy manifests, migrations, authentication code and lockfiles. | Policy | Default | | ---------------------------------- | ------- | | **Cooldown per error (hours)** | 24 | | **Attempts per error** | 2 | | **Fixes worked on at once** | 1 | | **Daily model budget (USD)** | 25 | | **Approval expires after (hours)** | 72 | | **Open pull requests as drafts** | Off | The cooldown and attempt limits apply to fixes Auto-Fix starts on its own, not to the ones people request. ### Hand Auto-Fix an error Select **Request fix** on a row of **APM › Errors**, **RUM › Errors**, or an error pattern in the Log Explorer when you group logs into patterns. Editors and admins can request fixes. A source set to start fixes on its own also hands over errors that cross its thresholds. ### Review and approve Fixes waiting for your decision appear in the notification bell, and Auto-Fix can post to the [notification channels](https://tracix.io/docs/alerting/notifications) you choose in its policies. The fix page shows the error, where Auto-Fix located it, the staged change, the output of your checks and the evidence. Before you see it, the change has passed the path rules and a secret scan, plus the repository's own commands when you turned them on. **Approve** pushes a branch and opens the pull request or merge request. **Reject** closes the fix. After you merge the pull request yourself, Auto-Fix marks the fix confirmed once the merge is deployed and the error stays away for an hour. ## Next steps - [Brain](https://tracix.io/docs/ai/brain): Ask questions and draft workflows in chat - [Model providers and the AI switch](https://tracix.io/docs/ai/model-providers): Choose the models agents use and price them - [Security response](https://tracix.io/docs/security/response): Approval-gated response actions and playbooks