Worker Management Overview
The WRM module provides a unified way to define, configure, and manage workers across your organisation. A "worker" in Raytio is any entity that performs work — a human team member, an AI agent, or an automated service. WRM gives each worker a structured identity and tracks the resources it needs to operate.
Key concepts
WRM is built around six core concepts:
| Concept | What it represents |
|---|---|
| Role | A named function a worker fulfils (e.g. docs_writer, code_reviewer, qa_tester) |
| Worker definition | A reusable template that specifies a role, system prompt, model preferences, and toolset |
| Worker | A running instance created from a definition, linked to a party in the system |
| Provider | An AI inference service (e.g. Anthropic, OpenAI, Amazon Bedrock) |
| Model | A specific AI model offered by a provider (e.g. Claude Opus 4, GPT-4o) |
| MCP server | A Model Context Protocol server that exposes tools a worker can use |
How it works
Definitions are templates; workers are instances
The split between worker definitions and workers is the central design idea. A definition is a reusable template — it describes what a worker should do and how it should be configured. A worker is a concrete instance created from that definition, bound to a specific party (person, agent, or service) in the system.
This separation means you can define a "code reviewer" template once and then create multiple worker instances from it — one for each AI agent or team member that fills that role. Each instance inherits the definition's configuration but can optionally override specific settings like model preferences or tool access.
The model stack
Workers that use AI models are configured through a three-tier model stack:
- Providers — the companies or services that host AI models (Anthropic, OpenAI, Bedrock)
- Models — the specific models available from each provider (Claude Opus, GPT-4o)
- Availabilities — the deployment endpoints where a model can be accessed, with region and pricing information
Worker definitions specify model preferences — an ordered list of model availabilities the worker should use, with priority ranking and optional parameter overrides. This lets you configure fallback behaviour: if the preferred model is unavailable, the worker can fall back to alternatives.
Tools via MCP
Workers can be given access to tools through MCP (Model Context Protocol) servers. Each MCP server exposes a set of tools, and worker definitions specify which servers (and optionally which specific tools from each server) the worker is allowed to use.
Tool access follows an allowlist model:
- A definition specifies which MCP servers the worker can connect to
- Within each server, specific tools can be included or excluded
- Worker instances inherit their definition's tool configuration but can override the server set
Cross-module integration
WRM does not exist in isolation — it connects to several other areas of the Raytio platform:
- Parties — every worker is a party in the system. AI agents and services use dedicated party types, while human workers link to their existing user record.
- Credentials — AI provider API keys and credentials are managed through the platform's existing merchant authentication system, keeping them encrypted and separate from worker configuration.
- Projects — work items and epic template slots reference WRM roles, so the same role definitions are shared between how work is assigned and how workers are configured.
Multi-tenancy
Like all Raytio modules, WRM is fully tenant-scoped. Provider configurations, worker definitions, workers, and role memories all belong to a specific tenant. Starter data (built-in providers, models, and worker definitions) is provided per tenant and can be customised without affecting other tenants.