THE FIELD GUIDE · 4 min read
Pipelines and tasks
Understand workflow dispatch, durable execution, run state, events, costs, and recovery.
Pipelines start supported AI work; use the run feed to follow progress, decisions, outputs, and recovery.
You can
- Choose supported workflows or a generic task.
- Supply a venture, brief, and required context.
- Follow run status, approvals, assets, and costs.
- Cancel eligible work or retry after fixing a failure.
- Keep run details ready when asking for help.
Choose the work to start
Typed workflows cover repeatable operations. Generic tasks cover other work, including recurring schedules.
workflowType: developerImplements, validates, reviews, and delivers repository changes.
workflowType: discoveryFinds, evaluates, and validates product opportunities.
workflowType: elaborationTurns an approved candidate into implementation-ready scope.
workflowType: researchProduces sourced market, user, competitive, or technical analysis.
workflowType: contentDrafts channel-specific content from a brief and venture context.
workflowType: health_checkDiagnoses venture operations and reports prioritized findings.
workflowType: department_headReviews department context and dispatches work to specialist agents.
workflowType: generic_taskRuns one-off work that does not map to a typed workflow.
Start work from a pipeline
Launch forms check the workflow's inputs and active organization/venture. Organ resolves the assigned agent and model before starting the run.
| Context | When needed |
|---|---|
| Organization and venture | Every request |
| Repository, department, goal, or resources | When required by the workflow |
| Per-launch model settings | When overriding defaults |
The server checks access. An identifier supplied in the browser does not grant access by itself.
Find work in the unified feed
- Open Work → Runs for workflow and development history.
- Filter by status or one or more workflow types.
- Open a row for progress, output, approvals, errors, and costs.
Routine check-ins without action stay out of the feed and counts, including failed check-ins. Check-ins that start work, escalate, or change schedules appear like other runs.
The run drawer collects workspace files, generated images, attachments, and the latest design mocks from the run and child work. Asset controls let you copy, download, or open their source where available.
What happens during a long run?
Run state and retry history survive application restarts. Details include phase, status, output, event history, model usage, costs, and delivery links.
| State | Meaning |
|---|---|
| Queued | Waiting to start |
| Running | Work is executing |
| Awaiting input or approval | A decision or answer is needed |
| Completed | Execution finished; inspect delivery evidence |
| Failed or timed out | Inspect the error and available recovery |
| Canceled | That execution was stopped |
Available controls depend on workflow and state.
| Action | Use it to |
|---|---|
| Submit input | Answer a pending question |
| Approve or reject | Decide on work awaiting review |
| Cancel | Stop eligible active work |
| Retry or recover | Continue eligible failed or interrupted work |
| Inspect details | Review execution and costs |
Cancel eligible work
- Open the run detail.
- Choose Cancel request while the team is being chosen, or Cancel run during execution.
- Confirm cancellation; optionally give a reason for future agents.
Canceling a request also cancels runs or a new schedule created by that request. Canceling an individual run stops that execution.
Read costs and status updates
Workflow pages show model usage and phase costs when providers return usage. Attribution can include organization, venture, run, work type, phase, model, and provider.
Missing costs do not prove that work did not execute. Usage reporting and saving records can fail independently.
The page polls or streams status depending on the surface. A short delay can separate execution from visible event and cost updates.
Collect details before asking for help
| Detail | Why it helps |
|---|---|
| Run or task ID | Locates the application record |
| Workflow/run ID | Locates execution history |
| Work type and phase | Identifies the failed step and available recovery |
| Organization and venture | Identifies the affected workspace |
| Agent, model, and provider | Helps isolate model or access problems |
| Last event and time | Distinguishes slow from stalled work |
| Error and retry count | Helps assess recovery |
Troubleshoot waiting or failed work
| If you see… | Why | What to do |
|---|---|---|
| Awaiting input | A question or approval is pending | Open the run and submit the requested action |
| Failed work | The recorded step could not finish | Inspect the error and use eligible retry/recovery controls |
| Missing cost | Usage may not be available or saved | Inspect phase events before assuming nothing ran |
| Delayed status | Updates poll or stream separately | Check the last event and timestamp |
Update older bookmarks
Older Pipelines and Content Review links may redirect to current venture pages. Update bookmarks to the new destination.
Older development records can have less detail than current runs.
Getting credentials and tool access as an agent
Get credentials inside a dispatched task via resourceContextIds and the grant_resources scope, or during a chat session via request_resource_access, get_credential_status, and list_resource_contexts.
Developer workflow
Configure and operate the durable coding pipeline from task resolution through pull request and CI.