> ## Documentation Index > Fetch the complete documentation index at: https://altostrat.io/docs/llms.txt > Use this file to discover all available pages before exploring further. # Digital workers (early access) > Create owner-enabled cloud workers that run staged, trigger-driven pipelines under a shared channel's grounding and tool policy. Digital workers are cloud-run, trigger-driven pipelines for repeatable operational work such as ticket triage, scheduled reports, and follow-ups. A worker is bound to a shared channel and acts under that channel's grounding and tool ceiling. Digital workers are an owner-gated early-access capability. Organizations fail closed with workers disabled. If **Administration → Workers** says workers are off, only the organization owner can enable access when the feature is available to the organization. ## When to use a worker Use a worker when all of these are true: * Work arrives from a repeatable trigger. * The job can be split into clear stages with explicit outputs. * The channel's context and tool policy provide a safe operating boundary. * A human gate can catch steps that need judgment. * The organization accepts cloud execution for the selected tools and data. Use an interactive conversation or a [procedure](./procedures) when a person should initiate and supervise the work directly. Workers are not a shortcut for removing approvals from uncertain tasks. ## Worker structure | Part | Purpose | | -------------- | ------------------------------------------------------------------------------ | | Identity | Name, description, and lifecycle state. | | Channel | Shared channel that supplies context, membership, and the maximum tool policy. | | Trigger | Event or schedule that starts work. | | Input contract | Fields a new work item must provide. | | Stages | Ordered AI steps with their own instructions and grants. | | Stage exit | Automatic continuation, verification criteria, or a human gate. | | Output | Result passed to later stages, the channel, or the originating system. | New workers begin as drafts. Configure and test them before activation. ## Create a worker Set the channel's members, grounding, and tool policy first. A worker cannot safely compensate for an ambiguous channel boundary. Select **Create worker**. If the action is unavailable, confirm the organization owner has enabled the feature. Name the worker for the outcome and define structured input fields. Avoid one free-form field when the trigger can provide tenant, device, priority, or ticket ID separately. Give each stage one job, a clear completion condition, and only the tool domains or individual tools it needs. Use a human gate before consequential external actions. Add exit criteria that prove the stage produced usable evidence. Run representative inputs, failure cases, missing credentials, and policy-denied tools. Review the resulting work item and channel activity. Enable the trigger only after the draft is ready. Pause the worker if behavior, source data, or policy becomes uncertain. ## Tool policy and credentials A worker stage can narrow the tools available to it, but cannot exceed the bound channel or organization policy. If a selected domain is disabled at the channel layer, the runtime drops it even if the worker editor still contains the old grant. Workers are organization actors rather than member sessions. Plan credential access deliberately: * Prefer read-only organization service credentials for unattended collection. * Keep tenant and target explicit in stage instructions and tool inputs. * Do not assume a member's personal Key Chain entry is available to a cloud worker. * Use human gates for writes, purchases, user communication, or other irreversible external effects. ## Human gates A stage with **Human gate** pauses before leaving the stage. The reviewer should inspect input, evidence, proposed action, and channel scope before approving or answering the task. A good gate asks for a decision a person can actually make. "Approve remediation on `edge-03` using change `CHG-123`" is better than "Continue?" Open worker items can surface in the channel's work flow and chat board. Assign ownership for reviewing gates; an unattended gate is a stalled automation. ## Operate the lifecycle * **Draft** — editable and not trigger-active. * **Active** — accepts enabled triggers and runs work. * **Paused** — stops new triggered work while preserving the definition and history. * **Archived** — retained for history and no longer operated. Pause before changing a live worker's tool boundary or stage semantics. Validate the updated draft path, then reactivate. ## Troubleshooting | Symptom | What to check | | ------------------------------ | ---------------------------------------------------------------------------------------- | | Workers are off | The organization owner must enable early access when available. | | Create worker has no channel | Create an active shared channel first. | | A stage cannot find a tool | Check organization, channel, and stage policy, then confirm the tool catalog is current. | | A stage lacks authentication | Use an appropriate organization credential; do not rely on a member's private entry. | | Work is stuck | Check trigger state, open work items, human gates, and stage verification criteria. | | A policy change broke a worker | Pause it, review effective grants against the channel, and test before reactivation. | ## Related Define the grounding, membership, and tool ceiling a worker inherits. Manage organization context, integrations, members, and effective access.