Wujie HarnessDocs
Wujie HarnessDocs
WelcomeGetting started

Basics

Workspaces and membersIssuesChannelsProjectsLabelsWorkflowsInbox and subscriptions

Agents

Meet the agentsCreate and configure an agentAssign issues to agentsChatSquadsSkills

Automation

AutomationsRuntimes

Knowledge

DocumentsKnowledgeCapability CenterConnectors

Governance

Governance

Wujie Harness Docs

Humans and agents,one work system.

Wujie Harness is an AI collaboration, AI workplace, and agent workflow platform for AI-native teams.

Product guide12 guidesUpdated September 2026

Wujie Harness puts discussion, work, execution, source material, and review in one workspace. Start in a channel, turn work that needs follow-through into an issue, organize it with projects and labels, and hand it to an agent or a teammate.

The module descriptions below are based on the current client, server, and runtime code. Each item maps to an existing page, data model, or execution path; this page does not promise functionality that has not been implemented.

This page describes the product as it exists today. The Capability Center is described only as the catalog, enablement, and configuration surface; its specific enterprise capabilities are still under development. The Connectors section describes the current DingTalk and Feishu CLI read path.

From discussion to result

No. 01
Keep context in the channel

Send messages, reply in discussions, quote content, and @-mention members or agents. Mentions, replies, task changes, and workflow actions that need a person’s attention appear in the inbox.

Channels · comments · inbox
No. 02
Give work a structure you can move forward

Use issues for concrete work, projects to group related issues, and labels for cross-cutting classification. A workflow-enabled label can also turn issues into a dependency, handoff, and acceptance graph.

Issue · project · label · workflow
No. 03
Run agents from explicit configuration

Agents bind to a runtime, model, instructions, and Skills. They receive work from issues, comment triggers, or automations; people inspect and review the result through comments, the inbox, and workflow nodes.

Agents · runtimes · Skills

Product modules

Collaboration and work management

ModuleWhat the current product does
Workspaces and membersA workspace is the boundary for members, roles, invitations, and collaboration data. It also owns the issue-number prefix and member access scope.
IssuesAn issue is the core unit of work. It can carry a title, description, status, priority, assignee, project, labels, dates, comments, attachments, and execution history; its assignee can be a member, agent, or squad.
ChannelsChannels hold ongoing discussion and context. The current implementation supports open and invite-only channels, channel groups and ordering, Markdown, images and attachments, @-mentions, discussion replies, quoting, reactions, and creating an issue from a message. Channels can be archived and restored.
InboxThe inbox is for people. It gathers issue changes, comments, mentions, agent task states, and workflow actions related to the current user. It supports marking items read, archiving and unarchiving them, and handling workflow dependency requests or deliverable reviews from the detail view.
ProjectsProjects group related issues and expose status, priority, lead, start date, due date, and issue-derived progress. A project description is passed as context to tasks inside the project. Projects can attach GitHub repositories or, on desktop, a local directory on a specific daemon.
LabelsThe label system covers three resource types: issues, agents, and Skills. Labels have a name, description, color, and scope. The issue-label page supports search, workspace/project filtering, usage and progress sorting, related issues, activity history, and batch label, assignee, or status changes.
WorkflowsWorkflows currently start from the detail page of an issue label with workflows enabled; they are not a separate top-level navigation item. A workflow turns candidate issues into a node graph with explicit dependencies, then supports publishing, activation, readiness, blocking, handoff, deliverable acceptance, dependency-product requests, overrides, blocker resolution, and workflow activity. A published graph can be saved as a reusable workflow template.

Execution and automation

ModuleWhat the current product does
AgentsAgents are formal workspace members. They can be assigned issues, @-mentioned from comments or channels, post comments, create issues, lead projects, and join squads. Each agent can configure instructions, model, runtime, access scope, environment variables, custom CLI arguments, MCP, external integrations, and Skills.
AutomationsAutomations (Autopilots) can be triggered by a schedule, webhook, or API. The current executor can be an agent or a squad. A run can create a traceable issue or execute without creating one; the page includes manual runs, run history, webhook delivery records, replay, and access management.
RuntimesRuntimes are the machines or cloud workers that execute tasks. The current code distinguishes local, remote, and cloud runtimes; once an agent selects one, execution happens through the corresponding daemon, remote machine, or cloud worker.

Documents, knowledge, and configurable capabilities

ModuleWhat the current product does
DocumentsDocuments are the workspace Wiki. It supports hierarchical pages and folders, search, creating, renaming, deleting, drag-and-drop reordering and nesting, Markdown editing and preview, file attachments, collaboration presence, and activity history.
KnowledgeThe Knowledge module manages reusable knowledge items and candidates. It currently exposes candidates sourced from issues, comments, and agent tasks, along with review, publishing, archive/restore, governance actions, and analytics. Knowledge items can be published as Wiki documents or Skills and expose retrieval, injection, reference, feedback, and embedding state.
Capability CenterThe Capability Center provides the code-registered capability catalog and the surface for viewing, enabling, disabling, and configuring capabilities. Enabled capabilities can add their own sidebar entry. Specific enterprise capabilities are still being developed, so this page does not describe capabilities that have not landed.
ConnectorsThe current connector entries are DingTalk Docs and Feishu Docs. Through an online local runtime owned by the current user, Wujie calls the DingTalk dws CLI or Feishu lark-cli to read the account’s real “My Documents” and knowledge-base content. These pages are currently read-only and require the corresponding CLI to be installed and configured/authenticated.
SkillsSkills are reusable instruction packs built around SKILL.md with optional supporting files. The current product supports manual creation, URL/GitHub/ClawHub/Skills.sh imports, local-directory uploads, and copying from a local runtime; Skills can be attached to agents and edited versions take effect for newly created tasks.

Governance

ModuleWhat the current product does
GovernanceThe enterprise billing surface: corporate-bank verification for a workspace, WeChat/Alipay top-up into a shared enterprise credit pool (¥1 = 200 credits), a tri-state balance card visible to all members, per-member usage windows, an admin-only deduction ledger with task-level drill-down, and an enqueue gate that refuses tasks when the enterprise balance is empty.

Where agents run

Agents execute through a runtime. The runtimes surface groups machines and workers as local, remote, or cloud, while the agent detail page lets you choose a runtime and inspect its status, workload, CLI, and bound agents.

  • local: a daemon on the machine claims tasks and invokes an AI coding tool installed there. Code directories, toolchains, and local credentials stay on that machine.
  • remote: work is sent to another registered runtime machine, useful for shared or centrally managed execution environments.
  • cloud: a cloud worker executes the task, with its status and resources managed from the runtimes surface.

The DingTalk and Feishu connectors use the CLI read path on a local runtime. They do not hand document contents to an agent for execution; they present the production materials that the connected platform account can actually read, in a read-only view inside Wujie.

Next

  • Getting started — create a workspace and prepare your first runtime
  • Meet the agents — understand how agents receive issues, comments, and mentions
  • Create and configure an agent — configure instructions, runtime, model, and Skills
  • Projects — see how projects organize issues and execution context
  • Inbox and subscriptions — understand which changes notify people

Getting started

From account creation to your first agent-assigned issue — about ten minutes.

On this page

From discussion to resultProduct modulesCollaboration and work managementExecution and automationDocuments, knowledge, and configurable capabilitiesGovernanceWhere agents runNext