Reference documentation for workflows, runtime, and reusable operations.

The clearest way to understand c8c is through the jobs people are already trying to get done with Claude Code or Codex, but cannot yet operate cleanly inside a team.

At a practical level, a workflow in c8c is the answer to a very specific operator problem: "this process is useful, but I do not want it to disappear inside one person's private AI session."

Workflows are directed graphs with explicit node types and runtime policy. They can branch, merge, pause for humans, and rerun from state instead of requiring another ad hoc chat session.

The high-level mental model is simple: define an input contract, route work through skills and gates, capture operator decisions when needed, and persist enough state to inspect or rerun the process later.

Input -> Skill -> Evaluator -> pass -> Output
                        |
                        -> fail -> retry from selected node

Input -> Splitter => parallel branches => Merger -> Output
Input -> Skill -> Approval/Human -> continue -> Output

The runtime matters when the work is no longer a one-off answer. As soon as the same process has to survive interruption, review, scale, or handoff, execution state becomes part of the product.

The runtime surface is designed for long-lived operational work. The important difference from a normal AI session is that status, retries, artifacts, and recovery are durable enough to survive review and rerun.

• Directed graph execution instead of single-session prompting.
• Retry policy with max tries, wait time, and linear or exponential backoff.
• Execution controls such as stop, continue, continue_error_output, alwaysOutputData, and executeOnce.
• Per-node logs, token usage, cost, duration, active stage, and result artifacts.
• Resume, rerun from a chosen node, inspect history, and review completed runs after the original session ends.
• Batch execution and a multi-run dashboard for concurrent workflows across projects.

In user language, this is the difference between saying "the agent already did most of the work, but I cannot prove what happened" and saying "the workflow is visible, resumable, and inspectable."

• When I say 'rerun just the flaky step', I do not want to start the whole process over.
• When a workflow fails at 80 percent, I need recovery from state, not another guessing session.
• When I hand work to someone else, I need them to see the same run state, not just the final answer.

In practice, this means a workflow can fail in the middle, stop for review, or be revisited later without losing the operator's understanding of what already happened.

Human checkpoints are not there because the model is useless. They are there because some outcomes only become safe when a person confirms, edits, or enriches the result at the right boundary.

c8c treats human intervention as part of the workflow model, not as an out-of-band workaround. This is the layer that makes governed release, review, and handoff possible.

• Approval checkpoints for merge, send, publish, write, or any other risky boundary.
• Editable checkpoints so operators can adjust intermediate output before continuing.
• Human-task forms with text, textarea, number, boolean, select, multiselect, or JSON fields.
• Inbox and notifications UI for blocked runs, unread events, pending approvals, and pending human tasks.
• Timeout policies for approvals and human tasks, including fail, skip, auto-approve, or auto-reject variants depending on node type.

• I need the workflow to stop before a risky action, but I do not want to lose context while waiting for a human.
• I need a reviewer to fix or enrich intermediate output without falling back to Slack threads and manual copy-paste.
• I need structured answers from a person, not just a free-form 'looks good'.

The Hub exists for the moment when the user is not asking for "a better prompt", but for "a starting workflow I can trust enough to adapt."

The Hub is the starting-point library for the system. It turns repeatable work into discoverable assets rather than leaving reuse trapped in one operator's local prompt craft.

Use the Hub when the team needs a readable starting point with named stages and output expectations instead of another blank workflow canvas. Skills, plugins, and marketplace sources extend the same reuse layer from a different angle.

• I know roughly what I want the workflow to do, but I do not want to model the whole graph from scratch.
• I need a readable starting point that another teammate can inspect before we customize it.
• I want to browse workflows by the job to be done first, not by whatever prompt wording someone happened to use.

Hub coverage today: 111 workflows.

This part of the product matters when the user is thinking: "I do not need another AI app. I need my existing AI stack to become operable under real constraints."

Provider control is explicit in the product. Authentication status, backend health, model defaults, safety profile, MCP servers, telemetry, and updates live in settings instead of being hidden in implicit local setup.

MCP servers are managed as first-class runtime infrastructure. The settings UI exposes provider-specific server lists, transport details, scoped configuration, connection testing, and enable or disable controls.

• I want to keep using the provider that already fits the task instead of standardizing the whole company on one model path.
• I need permission and safety posture to be explicit because some workflows touch the workspace and some should stay read-only.
• I need MCP servers to behave like managed runtime infrastructure, not private setup hidden on one laptop.

The CLI is for users who want workflows to behave like software infrastructure, not only like UI objects in a desktop app.

The desktop app is not the only interface. c8c also exposes a CLI and a standalone workflow runner package so workflows can participate in other automation contexts.

The @c8c/workflow-runner package exposes the execution layer separately from the desktop app, so workflows can be run, resumed, and integrated in other contexts without rebuilding the runtime.

• I want the same workflow model in scripts, tooling, or external automation, not only in the desktop UI.
• I need to resume a blocked run or answer a human task without opening the whole editor.
• I want workflows to become operable assets that can move between UI usage and programmatic usage.

The best first use case usually sounds ordinary in the user's own words: "this is the flow we keep repeating, this is where it breaks, and this is where somebody else needs to step in."

The right first workflow is rarely the most creative one. It is usually the process that already needs a second person, a retry path, or a visible approval boundary.

1. Pick one workflow that already needs review, rerun, or handoff.
2. Map the current process into explicit input, stages, output, and owner.
3. Insert one evaluator or approval boundary where failure becomes expensive.
4. Run it twice from the same structure before expanding scope.

Next steps: Browse the Hub, Download the app, or view on GitHub.

Where c8c shows up in day-to-day use — the major interfaces and system areas available today.

• Desktop workflow editor
• Project-scoped workflow library
• Template hub and starter flows
• Inbox for approvals and human tasks
• Batch and multi-run dashboard
• CLI and reusable workflow runner package