Product Overview

QoderWake uses digital employees, called Wakers, to take on ongoing work. The product is organized around two perspectives: manage and follow work from the task perspective, and configure Wakers, Groups, and capabilities from the user perspective. For a first run, create one Waker with a clear responsibility, validate it in a chat, and then add capabilities and resources, create a Group, connect IM, or formalize stable work as Autonomous Work or a WakerFlow.

​

Work management

The Dashboard is primarily for observing and handling work. Return to the source chat, Autonomous Work item, or WakerFlow when you need to create, edit, retry, or inspect the full context of a task.

​

Wakers and Groups

A Waker is a digital employee with a defined responsibility. Its behavior is shaped by its role configuration, execution environment, memory, Skills, connectors, knowledge bases, projects, and permissions. Use one Waker for one stable role or service boundary. A Group brings together complementary Wakers and designates a Leader to assign work and consolidate results. It is appropriate for work such as implementation, testing, and review that requires several roles. When tasks have dependencies or shared write access, define the execution order, primary editor, and human confirmation point.

​

Capabilities and resources

Installing a resource does not automatically make it available to every Waker. Assign it to the intended Waker, check permissions, and validate it in a new chat. Adding unrelated resources can increase routing, retrieval, and permission risks.

​

Waker detail page

The Waker detail page lets you manage the following information:

• Home: identity, availability, activity, statistics, and resource overview.
• Work: Dashboard and Autonomous Work.
• Memory & Learning: global memory and self-evolving Skills.
• Capabilities & Resources: Skills, connectors, WakerFlow, knowledge bases, and projects.
• Collaboration & Management: permissions and settings.

After changing a role, resource, workspace, or permission, validate the change in a new task. Existing chats can still contain context from the previous configuration.

​

Choose the right working mode

1. The task is still changing: start with a chat and confirm input, steps, boundaries, delivery format, and acceptance criteria.
2. Several roles must collaborate: create a Group; use WakerFlow when stages, branches, or confirmation points must be explicit.
3. The team works in IM: configure an IM connection and enable @Waker so one entry point can route work to different Wakers.
4. The work is stable and repeatable: create Autonomous Work and select a schedule, event, or API trigger.

Validate in a chat first, formalize the process second, and automate the trigger last. Do not place an unverified task into unattended automation.

​

From creation to rollout

​

1. Create the role

Choose a preset or create a custom Waker. Define responsibilities, accepted inputs, deliverables, boundaries, and actions that require human confirmation.

​

2. Bind the execution environment

Confirm that the Waker runs on the intended device. Tasks that need local files require the device to be online and the directory to be accessible.

​

3. Add the minimum resources

Add only the Skill, connector, knowledge base, and project required for the first validation task.

​

4. Validate in a chat

Start with a read-only task, then validate controlled write operations, out-of-scope refusals, and high-risk confirmations. Inspect the actual artifact instead of relying only on the final reply.

​

5. Extend collaboration

Create a Group, connect IM, or orchestrate a WakerFlow when needed. Run a small validation every time a new entry point is added.

​

6. Automate and maintain

Create Autonomous Work only after inputs, outputs, and failure handling are stable. Retest after changing the role, resources, permissions, application version, or project location.

​

Typical example

For a weekly website quality review:

1. Create a Web Quality Engineer Waker and assign the website project and browser capability.
2. Run one read-only review in a chat and confirm the report structure and acceptance criteria.
3. If remediation and verification require separate roles, create a Group or WakerFlow.
4. Run the process manually and inspect the report, screenshots, and test results.
5. Create weekly Autonomous Work and set a maximum run count or deadline if needed.
6. Retest after an application update or project-path change.

​

Before starting

• The Waker is available, and required files are on an accessible execution environment.
• The workspace or project contains only content needed for the task.
• Skills, connectors, knowledge bases, and permissions passed a minimal validation.
• Code merges, production changes, external publishing, deletion, and payments retain human confirmation.
• Test data, screenshots, and shared artifacts do not expose credentials, personal data, or restricted business information.

Some entries vary by CN or Global edition, account, region, Waker type, and feature flag. Follow the options displayed by the current product.