AI Worker

Key ideas#

• A worker has a contract: inputs, outputs, and failure semantics.
• A worker has constraints: time, cost, rate limits, and tool permissions.
• A worker is observable: structured logs, metrics, and trace fields.
• A worker is repeatable: idempotency and deterministic interfaces where possible.
• Workers compose: orchestration connects independent, single-purpose workers.

Diagram#

Agent / Orchestrator
      |
      | request (inputs + constraints + trace_id)
      v
  +-------------------+
  |     AI Worker     |  bounded execution
  |  - schema checks  |  timeout / retries
  |  - tool gating    |  logs / metrics / traces
  +-------------------+
      |
      | response (outputs + status + artifacts)
      v
Downstream system / Next worker

See also#

• what is AI worker
• AI worker architecture
• AI worker design patterns
• worker protocol
• examples
• Registry
• glossary

FAQ#

Is this a framework or a standard?

No. It is a design pattern and a shared vocabulary. You can implement workers with any model, runtime, or platform.

When should I use a worker instead of an agent?

Use a worker for bounded, auditable execution (do X with these inputs). Use an agent when you need autonomous planning and goal selection.

What belongs in a worker contract?

Inputs, outputs, status codes, constraints (timeouts, tools), and observability fields like trace IDs and attempt counters.

Do workers need to be deterministic?

They do not need to be perfectly deterministic, but they should be repeatable enough that teams can test, monitor, and reason about them.