AI Worker worker.md

Email Summarization Worker

Problem: Summarize a noisy email thread and extract next actions without leaking sensitive content or inventing facts.

This example follows the core principles described in the AI Worker Design Patterns and uses the standard Worker Protocol schema.

Key ideas#

  • Keep the worker single-purpose and explicit about inputs and outputs.
  • Put hard limits in the contract (timeout, retries, tools allowed).
  • Make failures machine-actionable with stable error codes.
  • Emit structured signals so orchestrators can route, retry, or escalate.

Diagram#

email thread -> worker -> { summary, key_points, action_items }

Worker spec#

worker_id: email-summarization-worker
version: 1.0
purpose: Summarize a noisy email thread and extract next actions without leaking sensitive content or inventing facts.
inputs:
  - thread_text: string
  - customer_context: object (optional)
  - audience: enum(internal, external)
outputs:
  - summary: string
  - key_points: array
  - action_items: array
  - tone: enum(neutral, friendly, formal)
constraints:
  timeout_seconds: 60
  max_tokens: 1500
  tools_allowed: [redact_pii, language_model]
retries:
  max_attempts: 2
  backoff: exponential
observability:
  trace_id: required
  log_fields: [worker_id, attempt, duration_ms]

Input schema#

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "additionalProperties": false,
  "properties": {
    "thread_text": {
      "type": "string"
    },
    "customer_context": {
      "type": "object"
    },
    "audience": {
      "type": "string",
      "enum": [
        "internal",
        "external"
      ]
    }
  },
  "required": [
    "thread_text",
    "audience"
  ]
}

Output schema#

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "additionalProperties": true,
  "properties": {
    "summary": {
      "type": "string"
    },
    "key_points": {
      "type": "array"
    },
    "action_items": {
      "type": "array"
    },
    "tone": {
      "type": "string",
      "enum": [
        "neutral",
        "friendly",
        "formal"
      ]
    }
  }
}

Constraints#

{
  "timeout_seconds": 60,
  "max_tokens": 1500,
  "retries": {
    "max_attempts": 2,
    "backoff": "exponential"
  },
  "rate_limit": "per-tenant (example: 10/min)",
  "tools_allowed": [
    "redact_pii",
    "language_model"
  ]
}

Failure modes & handling#

  • PII detected but redaction fails: return error_code=pii_redaction_failed.
  • Thread too long: return partial summary with error_code=context_truncated or request a smaller window.
  • Ambiguous requests: return action_items with needs_clarification=true.

Observability signals#

  • logs: worker_id, attempt, duration_ms, status, error_code
  • metrics: success_count, failure_count, retry_count, p95_duration_ms
  • trace fields: trace_id, span_id, upstream_request_id (if present)

See also#

FAQ#

Should the worker return partial results on failure?

If partial results are safe and useful, return them with a stable status and error_code. Otherwise fail fast and let orchestration decide.

Where should large artifacts go?

Store them externally (object storage or DB) and return a reference (URL or artifact ID) in the response.

How should I choose timeouts?

Set a hard ceiling based on SLOs and queue backpressure. Prefer smaller workers with tighter timeouts over monolith workers.