Skip to main content
Employee Resources

Waker Management

Create Wakers from presets or custom roles, then manage resources, permissions, runtimes, and Groups.

A Waker is a digital employee with a defined responsibility. A production-ready Waker needs more than a name: it needs a clear role, a runtime environment, an explicit work boundary, the right resources, and human gates for risky operations. Start with a small validation task, then add Skills, connectors, knowledge, and projects gradually. If responsibilities conflict, create separate Wakers or use a Group instead of overloading one role.

View Wakers and Groups

Path: left navigation → Waker Management. Use the tabs at the top of the page to switch between Waker and Group; use the employee sidebar for quick access to existing Wakers and Groups.
Waker Management
Use the list to verify:
ItemWhat to check
Name and responsibilityNames are distinct and roles do not overlap unexpectedly
RuntimeLocal, remote, or the intended device
StatusEnabled and available for work
Recent activityNo task is unexpectedly stalled or waiting for action
If a Waker is missing, clear search and filters and confirm that you are viewing the Waker tab rather than the Group tab. The Group tab shows existing Groups. From a Group card, you can open it, start a new task, or use the action menu to maintain it. Multiple avatars indicate member Wakers.
View and manage Groups

Distinguish local and remote Wakers

Each Waker card identifies Local or Remote, the host device, and its online state. A remote Waker runs on another device visible to the same account. Its files, connector credentials, and processes remain on that device; they are not copied to the current computer.
  • A local Waker can normally be managed and opened for chat directly.
  • Remote chat and configuration depend on the remote device being online, remote management being enabled, and the current account having permission.
  • If a card says that remote chat permission is denied, do not repeatedly retry or create a duplicate Waker. Ask the remote device owner to check the account, device state, and remote-management authorization.
  • When remote tasks are allowed, select a directory or project that actually exists on the remote device. A path on the current computer is not mapped automatically.
After changing a remote Waker's role, Skills, connectors, or permissions, run a read-only task in the remote environment. Authentication secrets are not synchronized with remote configuration; reauthorize a connector on the device that owns its credentials when required.

Create a Waker from a preset

  1. Select New Waker.
  2. Browse the presets. Roles cover engineering, QA, design, product, data, content operations, group Q&A, and other common jobs, depending on the current release.
Choose a preset role or create a custom Waker in the role marketplace
  1. Open a role card and review its core capabilities, work style, work methods, and bundled Skills.
Review the preset role before creating a Waker
  1. Select Create Waker to open Complete Details, then enter a descriptive name such as “Website Frontend Maintainer.”
  2. Choose the runtime environment. Use the device that can access required local files and applications.
  3. Review preinstalled Skills, knowledge, and connectors. Keep only capabilities required for the first task.
  4. Select Create Waker.
  5. Open its home page and verify its name, role, runtime, and status.
  6. Run a read-only task such as: “Explain your role boundary and list the files in the selected directory without modifying them.”
Complete the Waker name, responsibility, runtime, and resources
If a preset is mostly correct, create from it and refine the role files later. Use a fully custom role only when the structure differs substantially.

Create a custom role

Select Custom Waker, enter a role name, description, and avatar, then choose a configuration method.

Generate with AI

Use AI generation when you can describe the job but do not yet have complete role files.
  1. Describe the audience, primary responsibilities, inputs, deliverables, prohibited actions, and when human approval is required.
  2. Generate the configuration.
  3. Review every section. Replace broad promises with explicit scope and evidence-based completion criteria.
  4. Add only required Skills and connectors. Never put credentials in the role description.
Generate a custom role configuration
Use this structure:
Audience: who assigns work to this Waker.
Responsibilities: three to five stable job types.
Inputs: directories, files, messages, or business fields it receives.
Deliverables: documents, code, tables, links, or decisions it returns.
Boundaries: what it must not access or change.
Approval: which delete, publish, send, payment, or production actions need a human.

Upload Markdown configuration

Use this method when you already have reviewed role files or are moving a role between environments.
  1. Download the blank template provided by the page.
  2. Maintain files such as identity.md, persona.md, and bible.md according to the template.
  3. Remove credentials, private data, internal-only addresses, and machine-specific absolute paths.
  4. Upload the files and inspect the parsed configuration.
  5. After creation, open Settings, review each source file, and validate in a new chat.
Upload a reviewed Markdown role configuration

Enter configuration manually

Manual entry is best for tightly controlled roles.
FieldRecommended content
Core responsibilityStart with an action and name the object and deliverable
Work styleExplain analysis, execution, validation, and reporting order
Red linesExplicitly list forbidden access, modification, publishing, or sharing
WorkflowDefine the normal path and what happens on errors
Skills and connectorsAdd only capabilities required by the role
Enter a tightly controlled custom role manually
If the role needs a major rewrite after creation, pause automations and external entry points first, then update and revalidate it.

Use the Waker detail page

The redesigned detail page groups configuration by work stage:
GroupPagesPurpose
HomeHomeIdentity, status, activity, and resource overview
WorkDashboard, Autonomous WorkInspect tasks and automated work
Memory & LearningMemory, self-evolving SkillsMaintain durable learning
Capabilities & ResourcesSkills, Connectors, Workflows, Knowledge, ProjectsControl tools and context
Collaboration & ManagementPermissions, SettingsControl risk boundaries and role configuration
Installing a resource does not automatically make it available to every Waker. Verify that the resource is assigned to the current Waker and allowed by its permissions.
Review a Waker from its lifecycle-based detail page

Configure permissions

Open Permissions. Current releases organize controls into areas such as tool protection, file protection, built-in tools, and model safety.
Configure the Waker's permission boundaries
  1. Start with the minimum required files and tools.
  2. Keep human approval for deletion, overwrite, external sending, production changes, payments, and publishing.
  3. If IM users may change Waker settings, restrict the allowed users and chat scope.
  4. Save and run a low-risk validation: guarded actions should request approval, and forbidden actions should be blocked.
Permission changes affect future operations; they do not undo changes that already happened. Validate with a new chat because an existing chat may retain earlier context.

Update role and basic settings

Use Settings to maintain the profile and inspect source files.
Maintain the profile and inspect role source files
  • For a name, avatar, or short description change, update basic information.
  • For a responsibility or boundary change, also review role files, Skills, connectors, and permissions.
  • For a runtime or directory change, revalidate file access, projects, and automations.
  • For a completely different purpose, create a new Waker so the old role remains auditable.
After a role-file change, test an in-scope task, an out-of-scope request, and a high-risk request that must pause for approval.

Create and maintain a Group

A Group lets complementary Wakers collaborate through one chat entry point. The Leader interprets the request and organizes the work; member Wakers execute according to their responsibilities, while progress and results remain in one task.

Create a Group

  1. Open Waker Management, switch to Group, and select New Group.
  2. Enter a title that reflects the shared goal, such as “Release Delivery Team.” The title appears in the employee sidebar, Task Board, and chats.
  3. Select members on the left. Start with the Waker that can complete the primary work, then add complementary engineering, review, QA, or operations roles.
  4. Assign one Leader to receive Group requests, decide the order of work, coordinate members, and consolidate results.
  5. Select each member and confirm its response model and working directory on the right. When several members access one directory, define one primary writer and read-only reviewers.
  6. Confirm the configured-member count, then select Create.
Create and configure a Group
Selecting a member on the left and configuring that member on the right are separate steps. A checked member is not fully configured until its required settings are complete.

Validate Group collaboration

From the Group card, select New Task and run a small validation. Confirm that:
  • the Leader clarifies the goal and routes subtasks to suitable members;
  • each member uses the expected model, workspace, and permissions;
  • one primary writer owns shared-file changes while reviewers remain read-only;
  • progress, approvals, and the final result are visible in the same task.
After changing members, the Leader, models, or directories, start a new validation task. Deleting a Group does not delete member Wakers, but it breaks entry points that depend on that Group; resolve active work and retain required artifacts first.

Before disabling or deleting

Check for running chats, pending approvals, Autonomous Work, WakerFlow references, Group membership, @Waker sessions, and artifacts that must be retained. Pause external triggers first, resolve dependencies, then disable or delete.

Go-live checklist

  • Role, name, runtime, and status are correct.
  • Only required Skills, connectors, knowledge, and projects are assigned.
  • In-scope, out-of-scope, and approval-gated tasks have been tested.
  • Chat, automation, Group, and IM entry points have each passed a small test when used.
  • Test data and screenshots contain no credentials or sensitive information.