Task Intake¶
Task Intake sends events, incidents, and related information from the workspace, or messages from external systems, to an Agent for processing. After information enters an intake, the Agent aggregates the input according to the intake rule, creates a task session, and produces analysis, remediation guidance, automated actions, or result notifications.
Task Intake is suitable for event-driven automation, such as:
- Send alert policy events to an on-call Agent so it can summarize abnormal metrics, related services, impact scope, and next investigation steps. If the Agent has access to the relevant code repository, it can also reference code logic, recent changes, or configuration files to provide more practical remediation suggestions.
- When potentially related SLO, log, trace, or infrastructure alerts enter the same aggregation window, let the Agent use the broader context for correlation analysis.
- Let an Agent summarize context, risks, and required human confirmations before incidents, tickets, changes, or third-party alerts enter the team workflow.
- Deliver the Agent's analysis, remediation result, or follow-up actions to selected Channel conversations.
Scheduled Tasks usually run at fixed times. Task Intake is triggered by workspace events, incidents, related information, or external messages.
Intake Types¶
Task Intake has two types:
| Type | Entry point | Best for | Main settings |
|---|---|---|---|
| Built-in intake | Select an Agent in alert policies or other workspace workflows. When related events or incident information is produced, the Agent is notified and starts processing. | Guance alert triage, initial incident review, event aggregation, result notification. | Aggregation window, instruction, Channel delivery. |
| External intake (custom) | Create a Webhook for the current Agent. External systems send tasks through the Webhook. | Third-party alerts, tickets, incidents, changes, release checks, or other platform events. | Task name, aggregation window, permission mode, message template, Channel delivery, enabled status. |
Processing Flow¶
Both entry points send tasks to the same Agent. The difference is where the message comes from:
flowchart LR
A[Built-in intake: alert policy selects Agent] --> C[Agent processes task]
B[External intake: Webhook sends task] --> C
C --> D{Channel delivery enabled}
D -->|Yes| E[Send result to message channels]
D -->|No| F[Keep result in run records and session]Configure Built-In Intake¶
Built-in intake sends events, incidents, and related information produced inside the workspace to an Agent. Users can select the Agent in alert policies or similar workflows. When related information is produced, it enters the Agent's Task Intake flow.
Open Task Intake in the Agent workspace to view and edit the built-in intake:
| Field | Description |
|---|---|
| Aggregation window | Controls whether events are processed immediately or collected within a 1, 2, 5, 10, or 15 minute window. Use a window for alert storms or flapping events; use immediate processing for single critical alerts. |
| Instruction | Describes what you want the Agent to do. The default goal is analysis. You can also ask the Agent to provide remediation steps, try to resolve the issue within its allowed permissions, or summarize the result for human notification. |
| Channel delivery | Optional. When enabled, the Agent result is delivered to selected Channel conversations, such as on-call groups, incident rooms, or service owner chats. |
Built-in intake is a good starting point for core alerts, such as high-priority SLO alerts, error-rate spikes, database connection anomalies, or trace latency anomalies. Start with analysis and recommendations first, then add automated handling requirements after the output is stable.
Configure External Intake (Custom)¶
External intake sends events from other systems to an Agent through a Webhook. Open Task Intake in the Agent workspace and click New custom intake. Configure the following fields:
| Field | Description |
|---|---|
| Task name | A recognizable purpose, such as "PagerDuty alert triage", "Jira incident first review", or "Release failure analysis". |
| Aggregation window | Controls whether external messages are processed immediately or collected within a 1, 2, 5, 10, or 15 minute window before being sent to the Agent. |
| Permission mode | Controls how the triggered task session can use Agent capabilities. Prefer the default mode; use full access only when the source is trusted and the task scope is clear. |
| Message template | Defines how external messages are written into the Agent session and acts as the handling instruction. This field is required. Include the event source, affected object, symptom, expected output, and risks to watch. |
| Channel delivery | Optional. When enabled, select existing Channel conversations. The Agent result is delivered to those message channels after processing completes. |
| Enabled status | When enabled, the external system can continue sending tasks. When paused, this intake no longer triggers the Agent. |
After saving, the system generates a Webhook URL. The URL includes an access token. Store it as sensitive information and copy it into the external system's Webhook configuration.
If an old URL should no longer be used, rotate the Secret in the intake detail page. The old Webhook URL becomes invalid, and the new URL must be updated in the external system.
Write Instructions And Message Templates¶
Instructions and message templates determine what the Agent sees and what it should do. They do not need to be long, but they should make the event, affected target, and expected output clear.
For an alert intake, the template can include:
- Alert name, severity, and trigger time.
- Affected service, host, cluster, or business object.
- Alert summary or details from the external system.
- Expected Agent output, such as impact scope, possible causes, risks that need human confirmation, and next actions.
If the external system sends structured JSON, reference stable fields in the template, for example [{{status}}] {{detail.message}}. Field names depend on the actual payload sent by the external system.
Review Run Records¶
Each trigger creates a run record. In the intake detail page, you can view:
- Latest trigger time, received message count, and current status.
- Records in collecting, running, completed, or failed states.
- The Agent session created for each run.
Open a processing session to review the external message, the Agent's analysis, and the final result. If a run fails, adjust the instruction, message template, aggregation window, Agent capabilities, or the payload sent by the external system.
Manage Intakes¶
From the Task Intake list or detail page, you can:
- Enable / pause: temporarily stop this intake from triggering the Agent.
- Edit: update the aggregation window, instruction, and result delivery for built-in intake; update the name, permission mode, and message template for custom intake as well.
- Rotate Secret: custom intake only. The old Webhook URL becomes invalid, and the new URL must be copied to the external system.
- Delete: custom intake only. After deletion, external systems can no longer send messages through that URL.
Best Practices¶
- Use built-in intake for alert policies first, and use external intake for third-party systems or team-owned workflows.
- Create separate intakes for different sources or processing goals so one entry point does not mix unrelated events.
- Use an aggregation window when alerts are dense, allowing the Agent to reason over related events together.
- Make the instruction specific, such as "identify the impact scope and provide three investigation steps" instead of "take a look".
- Use Channel delivery when the result should be sent to an on-call or collaboration group; otherwise, keep the result in run records.
- Treat the Webhook URL as sensitive because it includes an access token. Rotate the Secret if you suspect exposure.