Create and complete work with Awaken Workforce

Use Workforce when one job must keep moving across Agent runs, human decisions, and external systems. Start with the job itself: who owns it, what result is needed, what may block it, and which system can say that it is complete.

Workforce is available through focused early access. The first useful result is one Issue that you can create, advance, stop with an exact reason, and resume without replacing its owner or Workflow revision.

Start from the decision in front of you

The browser console groups the same product facts by the decision a person needs to make:

Runs and Agent Center project Agents execution health into the composed console. Resources projects Objects business facts and actions. Workforce uses those products without taking ownership of their Session, Run, Resource, or Action truth.

Chats is a command workbench projected over an Awaken conversation; it is not a Flow transcript, Issue, or execution record. Canvases is an Objects-owned Resource surface with immutable revisions, isolated Preview, review, and an explicit Send-to-Agent bridge; it is not a second Design backend or Workforce aggregate.

How the three products work together

The composed path is Workforce commissions → Objects grounds context and actions → Agents executes → evidence returns → Workforce accepts. A technical Run can finish before the Outcome is ready for acceptance.

Create the first Issue

1. Follow the quickstart to validate the deployment, start the local topology, and bootstrap a Project.
2. Create an Issue with an owner and the outcome you expect. Add its required inputs and active dependencies before dispatch.
3. Pin the Workflow revision that defines states, named outputs, approvals, and transitions. Later edits produce another revision; they do not change this Issue underneath you.
4. Assign the ready WorkUnit to an Agent, person, or automation. The assignment and each attempt remain attached to the Issue.
5. If a required input, approval, or check is missing, resolve the recorded Attention and retry. End the Issue only after its declared completion conditions pass.

The visible result is an Issue with one pinned process, a current state, and a reason for every advance or stop. Workforce can evaluate declared Workflow rules and recorded facts. Put an external check behind the Connector or verifier owned by that system, then record its returned fact.

Workforce is the work, responsibility, and outcome plane. Awaken is the sole Agent execution and control plane. A WorkUnit may use an Agent configured in Awaken, a supported compatible Agent, or an existing publication; none of those choices replaces the Issue as the work record.

How Workforce carries that Issue

flowchart LR
    I["Issue"] -->|pins| W["WorkflowRevision"]
    W --> R["readiness and assignment"]
    R --> U["WorkUnit"]
    U --> A["Agent or human action"]
    A --> F["named outputs and Resource facts"]
    F --> G["guards, approvals and transition"]
    G -->|advance| I
    G -->|cannot advance| N["Attention"]
    N -->|resolve or retry| I

A schedule can recheck later, a reaction can recompute after facts change, and an active dependency can withhold dispatch until its upstream Issue terminates. Those paths return to the same Issue and Workflow authority; they are not parallel task systems.

Static structure and ownership

The separation is deliberate: Workforce owns work and responsibility; Awaken owns Agent configuration and execution. Deployment TOML selects process composition but does not duplicate the persisted model catalog or credential vault.

Continue with the task you need

For application-facing Agent configuration, protocols, durable sessions, and sandbox operations, use Awaken. Enter Awaken Agents internals only when embedding or extending its Rust execution kernel.