Task Intake¶

Task Intake routes workspace events and messages from external systems to a selected Agent. The Agent collects the input according to the intake configuration, creates a task session, and analyzes it with the context and tools available to it. Results can remain in the session or be delivered to a configured Channel session.

An Agent's available capabilities are determined by what is enabled and authorized for it. In addition to observability data such as metrics, logs, and traces, it can use enabled Skills and MCP services, as well as task-relevant information accessible from its runtime environment. Resources that are not configured or authorized are not used.

It turns fragmented alerts, monitoring notifications, tickets, and business events into repeatable, event-driven workflows. For example, an Agent can provide an initial assessment after an alert fires, or analyze a failed release reported by an external system and send the result to the on-call group.

What Task Intake Does¶

Task Intake connects event triggers, analysis, and result delivery. It helps teams:

• Respond faster by having an Agent prepare an alert summary, likely causes, impact scope, and recommended next steps when an event occurs.
• Correlate broader context by combining the incoming event with metrics, logs, traces, and other observability data, then using the Agent's Skills, MCP services, and accessible environment information as needed.
• Reduce manual handoffs by delivering the analysis to an on-call group, incident room, or owner conversation.
• Extend automation through Webhooks for third-party monitoring, ticketing, release, and business systems.
• Preserve the reasoning trail because every trigger has a run record and a linked task session for review and improvement.

Scheduled Tasks run on a fixed schedule. Task Intake runs when a workspace event or external message arrives.

Intake Types¶

Task Intake has two entry points. Both are handled by the selected Agent.

flowchart LR
  A[Workspace alert policy] --> B[Workspace intake]
  C[External system] --> D[Custom Webhook intake]
  B --> E[Agent creates and analyzes a task]
  D --> E
  E --> F[Task session and run record]
  E --> G[Configured Channel sessions]

Before You Start¶

Before configuring an intake, make sure that:

• The target Agent is created in the current workspace.
• The Agent has the Skills and MCP services required for the task, with permission to access the needed workspace data or environment information.
• A Channel session has been established for each group or person that should receive the result.
• For a custom intake, the external system can send JSON in an HTTP POST request.

Start by asking the Agent for analysis and recommendations. Add requests for actions only after the output is reliable and the operating boundary is clear.

Prepare Result Delivery Targets¶

Channel delivery in Task Intake targets specific sessions. The list shows only Channel sessions that have already been established for the current Agent. If only the message channel has been configured, the target group or direct message may not appear yet.

If the list is empty or the target session is missing, follow Prepare a Channel Session for Result Delivery to send the bot a message from the target conversation. Then refresh this page or reopen the configuration before selecting it.

After a display alias is set for a Weixin Message Channel, delivery targets prefer that alias so sessions with an unclear default name or ID are easier to identify.

Result delivery has no separate toggle. Selecting 1 to 20 sessions enables delivery; selecting none keeps the result only in the run record and task session. Results are sent only to the selected sessions, not to every session under the same Channel.

Use Workspace Intake¶

Workspace intake handles monitor events produced inside the workspace. Select a target Agent in an alert policy. When the event is generated, the workspace sends its context to the Agent, which can analyze it with its available data, tools, and environment information.

After selecting result delivery sessions, Workspace intake can also enable Deliver source events first. Each event is sent to the selected sessions as soon as it arrives. The Agent still collects and analyzes events according to the configured execution period, then sends its analysis when complete. When this option is off, only the final analysis is delivered. A source event gives recipients earlier awareness and does not mean that the Agent has completed its analysis.

Open Task Intake in the Agent workspace, find the intake whose type is Workspace, and open its details to review or adjust the following settings:

Use Custom Intake¶

A custom intake generates a Webhook URL for the current Agent. An external system sends JSON to that URL, and the system organizes the incoming fields with the task instruction before triggering the Agent.

Create an Intake¶

1. Open Task Intake for the target Agent.
2. Select New custom intake.
3. Configure the intake and save it.
4. Copy the generated Webhook URL into the external system.
5. Send a test event and confirm that the Agent created a task and returned a result in the intake run records.

Configuration Settings¶

After you save the intake, the system generates a Webhook URL that includes an access token. Treat this URL as sensitive information and do not expose it in uncontrolled locations. To stop use of an old URL, reset the Webhook URL in the intake details. The old URL becomes invalid immediately, so update the external system with the new one.

Request Format and Field References¶

Send JSON to the custom-intake Webhook URL with the POST method. The request must follow these rules:

The task instruction uses fields inside data as its variable context. Do not add a data prefix to placeholders:

• {{title}} reads data.title.
• {{detail.message}} reads data.detail.message. Use periods to reference fields in nested objects.
• A placeholder path can contain letters, numbers, underscores, hyphens, and periods.
• Arrays are converted to comma-separated text, while objects are converted to JSON text.

The endpoint returns 400 when the body is not valid JSON or does not contain a valid data object. If a referenced field cannot be found, its placeholder remains in the task instruction. Use stable, clearly named fields and send a test message before going live to verify that each field is referenced correctly.

Best Practice: Connect an External Monitoring Alert¶

The following example connects a third-party monitoring alert to an Agent and delivers the analysis to on-call staff.

1. Create a Custom Intake¶

Use settings such as:

Enter the following in Task instruction:

The following is an alert from a third-party monitoring system. Based on the alert fields, the observability data available in the current workspace, enabled Skills and MCP services, and related information accessible from the runtime environment, complete an initial analysis.

Alert title: {{title}}
Time: {{date}}
Environment / tags: {{tags}}
Details: {{message}}

Provide:
1. Alert summary
2. Possible causes
3. Impact scope
4. Recommended handling steps

This instruction tells the Agent both how to read the event and how to structure its response. When the Agent should take action, state the action goal, boundaries, and required human confirmations separately.

2. Send an Alert from the External System¶

Replace the generated Webhook URL with the real one and send this JSON with POST. The business alert remains inside data so the task instruction can reference its fields.

{
  "data": {
    "title": "接口异常 / unknown upstream issue",
    "date": "2026-07-14T16:08:32+08:00",
    "tags": ["prod", "order", "gateway", "auto-alert", "sev:?"],
    "message": "[FIRING] rule=gw_5xx_rate maybe order-create; current=8.7? prev=0.3? unit=%; path=/v1/orders/create,/v1/orders/*; region=cn-east-1; host=gw-prod-17|gw-prod-22; upstream=?; err_code=502/503/000; raw_log=\"upstream_reset_before_headers EOF timeout context_canceled\"; payload_hash=***; detail_truncated=true; dashboard_ref=apigw-err-03; note=\"auto merged from 3 signals, confidence=0.62\""
  }
}

3. Review the Analysis Delivered to On-Call Staff¶

The Agent first writes the task instruction and alert fields into a task session, then analyzes them with the data, tools, and environment information available to it. The following mock result illustrates what on-call staff might receive in a configured Channel session. Its metrics and conclusions are examples only; use the information available to the Agent for the current task as the source of truth.

[Initial Analysis: Order Gateway Exception]

1. Alert summary
- At 2026-07-14 16:08:32, the production order gateway 5xx rate rose to 8.7%, compared with a previous level of about 0.3%.
- The issue is concentrated on /v1/orders/create and /v1/orders/*, involving gw-prod-17 and gw-prod-22 in cn-east-1.
- The alert combines three related signals and should be validated against traces and logs as the incident develops.

2. Possible causes
- Gateway logs contain upstream_reset_before_headers, EOF, timeout, and context_canceled, which suggests an interrupted connection or a timeout between the gateway and an upstream service.
- Workspace signals for the same period show increased 502/503 responses and elevated latency on the order-create dependency path. Check the order-create service and its dependencies first, including availability, connection pools, and timeout settings.
- The upstream field does not identify a specific instance. This alert alone is not enough to confirm the root cause; use request traces to identify the failed downstream service.

3. Impact scope
- Order creation and related order APIs in production may fail or retry, causing users to see checkout failures or request timeouts.
- Current evidence points to two gateway instances in cn-east-1 and order-related paths. Confirm whether other regions, entry points, or asynchronous order flows are affected.

4. Recommended handling steps
1. Open dashboard_ref=apigw-err-03 and confirm the start time, duration, request volume, latency, 5xx trend, and affected instances.
2. Query gateway logs around the alert time for gw-prod-17 and gw-prod-22, then correlate /v1/orders/create requests with downstream calls by trace ID.
3. Check health, error rate, connections, and timeouts for the order-create service and its direct dependencies. Compare them with recent releases, configuration changes, and traffic changes.
4. If the error rate continues to rise, follow the incident process for traffic limiting, instance isolation, scaling, or rollback. Complete the required confirmation before making changes.

4. Review Run Records¶

Open the custom intake details to review each processing record by status:

• Collecting: messages are waiting for the current execution window to end.
• Running: the Agent has created a task and is analyzing the input.
• Completed: open the linked task session to review the input, analysis, and final result.
• Failed: check the error, task instruction, field mapping, Agent capabilities, and external request format before testing again.

Run records also show the trigger time and received-message count. When windowed processing is used, messages received in the same window are combined into one task so the Agent can analyze their relationship.

Recommendations¶

• Create separate intakes for different sources and processing goals. Do not mix unrelated events in one intake.
• Use an execution window for alert storms, flapping alerts, or strongly related events; use immediate processing for urgent single events.
• For Workspace intake, enable Deliver source events first when recipients need earlier awareness. Leave it off if frequent source events would create unnecessary message noise.
• Make task instructions testable. State the fields, analysis target, output structure, and escalation criteria instead of writing only "please investigate."
• Send only the information needed for analysis. Do not include secrets, personal data, or unnecessary raw content in a Webhook request.
• Prefer default permissions for externally triggered tasks. Consider full access only after the output is stable and the boundary is explicit.
• Review failed runs and low-quality results regularly, then refine the task instruction, execution period, Agent capabilities, or delivery targets.
• Reset the Webhook URL immediately if you suspect that it has been exposed.