Worker management
Define, run, and govern AI and human workers with full cost and quality visibility.
Raytio Worker management describes every worker - human or AI - and everything needed to spin one up: role, template, system prompt, model stack, and toolset. It records each dispatch as a structured run, evaluates the quality of the output, checks it against guardrails, and tracks its cost against budgets - governed work with the same access control and multi-tenancy guarantees as the rest of the platform, and a human kept in the loop wherever the work is high-risk.
Capabilities
A definition captures role, system prompt, model preferences and tool access once. Workers are instances of that definition, and can override settings without touching the template.
Providers, models and deployment availabilities are configured separately. Definitions hold an ordered preference list, and dispatch falls back to the next choice when a model is unavailable or rate-limited.
Workers connect only to explicitly granted tool servers, narrowable to specific tools within a server.
Every dispatch is recorded as a structured run.
- The worker, and the model and provider actually used.
- Tokens, cost and duration.
- Branch and merge-request links.
- Final status and a step-by-step trace.
Rule-based, model-graded and statistical scorers assess completed work on a 0-1 scale. Scoring runs asynchronously, so it never blocks delivery. A different model can be used for cross-model validation.
Pre-dispatch checks scan the prompt and budget before any cost is incurred. Post-dispatch checks inspect the output. Each check is rule-based or model-graded, at warn or block severity.
Budgets cascade from role to definition to instance, and are checked before dispatch. Budget periods can be daily, weekly, monthly or per-run. A circuit breaker skips providers with too many recent failures.
High-risk work pauses and waits for a human decision, with configurable reminder and escalation timeouts. The system never auto-approves.
Persistent, typed notes attach to a role, so a worker carries forward past decisions rather than starting cold. The note types are feedback, lesson, reference and project.
A supervisor decomposes an epic into dependent child work items. The items are dispatched in parallel where dependencies allow, then rolled up into a summary on completion.
Notable details
The run states are RUNNING, SUCCESS, FAILED, TIMEOUT, BUDGET_EXCEEDED and INVALID_OUTPUT. Every run ends in an explicit state.
Provider API keys are held encrypted in the platform's merchant authentication system, never in worker configuration.
Three factors determine what dispatches next: standard dependency types, concurrency limits, and same-repository serialisation.
Part of Agents · Read the documentation →
Verified customers, protected data, and agents you can hold to account.