# Background Automation
URL: /response-workflows/background-automation
Type: concept
Description: Set up workflows to automatically generate and send responses without agent involvement.
Keywords: background automation, auto send, cache mode
Background automation lets workflows run on their own — triggered by ticket events, generating responses, and optionally sending them without any agent involvement. This is how you achieve full ticket deflection for scenarios where automated responses are appropriate.

Automation modes [#automation-modes]

Each workflow can be set to one of four automation levels:

| Mode              | What happens                                                                                                                                                                                                          | Agent involved?                |
| ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ |
| **Disabled**      | Workflow only runs when an agent manually selects it                                                                                                                                                                  | Yes                            |
| **Cache**         | Workflow runs in the background and pre-generates a response, but doesn't send it. The response appears as an [Assist suggestion](/response-workflows/assist-suggestions) for agents to review.                       | Yes (reviews before sending)   |
| **Internal note** | Workflow runs and automatically posts the response as an internal note on the ticket. Not visible to the customer. Useful for agent-assist artifacts like QA reports, ticket summaries, or engineering handoff notes. | Optional (can review the note) |
| **Public reply**  | Workflow runs, passes a quality check, and sends the response directly to the customer.                                                                                                                               | No                             |

These modes represent a progression from fully manual to fully automated. See [Progressive Automation](/response-workflows/progressive-automation) for guidance on moving between modes.

How background execution works [#how-background-execution-works]

When a ticket event occurs (like a customer sending a message), here's what happens:

1\. Trigger [#1-trigger]

A customer message arrives on a ticket. Stylo evaluates all workflows with background automation enabled to determine which ones might apply.

2\. Classification [#2-classification]

Stylo evaluates the ticket against all eligible workflows in a single step, comparing the customer's message and ticket context to each workflow's "when to use" description. Each workflow receives a confidence score.

3\. Execution [#3-execution]

* **Cache mode:** all workflows that pass classification are executed. Their pre-generated responses are stored as [Assist suggestions](/response-workflows/assist-suggestions) for agents to review.
* **Internal/Public mode:** only the highest-confidence workflow runs.

4\. Response delay (optional) [#4-response-delay-optional]

For internal and public modes, you can set a delay (in seconds) between when the response is generated and when it's sent. This gives agents a window to respond first. If an agent replies during the delay, the automated response is discarded.

5\. Revalidation [#5-revalidation]

Before sending (internal and public modes), Stylo re-checks the ticket to make sure nothing has changed:

* Is the ticket still open?
* Has anyone (agent or customer) posted since the triggering message?

If the ticket state has changed, the response is discarded. This prevents stale or duplicated responses.

6\. Quality check (public mode only) [#6-quality-check-public-mode-only]

For public replies, a separate AI evaluation checks the generated response for:

* **Accuracy** — is the information correct?
* **Relevance** — does it address the customer's question?
* **Tone** — is it professional and appropriate?
* **Safety** — does it avoid harmful or misleading content?
* **Completeness** — does it fully address the issue?

If the response doesn't meet quality standards, it's blocked and the ticket is left for an agent.

7\. Send [#7-send]

If all checks pass, the response is posted to the ticket and any configured actions (set status, add tags) are applied.

Trigger types [#trigger-types]

You can choose what type of ticket event triggers the workflow:

| Trigger                 | When it fires                                                                                                                                                |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Customer reply**      | When a customer posts a public message on the ticket                                                                                                         |
| **Agent internal note** | When an agent posts an internal note (useful for agent-initiated automation — the agent adds a note like "process refund" and the workflow handles the rest) |

Setting up automation [#setting-up-automation]

1. Open your workflow and go to the automation settings
2. Choose the automation mode (cache, internal, or public)
3. Select the trigger type
4. Optionally set a response delay (recommended for public mode — 30-60 seconds gives agents a chance to respond first)
5. Publish the workflow

Monitoring automated responses [#monitoring-automated-responses]

All automated executions are logged with full details:

* **Status** — succeeded, quality check rejected, stale (ticket changed), escalation triggered
* **Confidence** — how confident the classification was that this workflow matched
* **Response** — the generated text
* **Duration** — how long execution took

Use the draft analytics dashboard to monitor acceptance rates, edit distances, and confidence distributions over time. This data is what informs the decision to graduate a workflow from cache mode to automatic sending.

Best practices [#best-practices]

* **Start with cache mode.** Let agents review AI-generated responses before enabling automatic sending. This builds confidence and reveals edge cases. See [Progressive Automation](/response-workflows/progressive-automation) for the full approach.
* **Use response delays for public mode.** Even 30 seconds gives agents a chance to jump in on tickets they're already handling.
* **Combine with escalation rules.** Automated sending should never handle high-stakes situations — configure [escalation rules](/response-workflows/escalation-rules) to route those to humans.
* **Monitor the quality check rejection rate.** If more than 10-15% of responses are being blocked by the quality check, your strategy instructions or template may need improvement.
* **Review stale rejection rates.** High stale rates may indicate your response delay is too long, or that agents are already handling the tickets your workflows target.
* **Use internal note mode for agent tooling.** Not every automated response is customer-facing. Use internal notes for QA summaries, ticket categorization, engineering handoff briefs, and other artifacts that help agents without being visible to customers.

Related [#related]

* [Progressive Automation](/response-workflows/progressive-automation)
* [Assist suggestions](/response-workflows/assist-suggestions)
* [Escalation Rules](/response-workflows/escalation-rules)