> For the complete documentation index, see [llms.txt](https://docs.darcyiq.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.darcyiq.com/build/pipelines.md).

# Pipelines (Beta)

Multi-owner review chains where each stage's agent judges a submission against that stage's requirements, and the stage owner has the final say

Most approvals are a chain of people: legal reads the contract, finance checks the numbers, a director signs it off. The work is real, but the process is usually email — nobody knows where a submission sits, what was already checked, or what still needs fixing.

**Pipelines turn that chain into a structured review.** A pipeline is an ordered set of **stages**. Each stage has an **owner** (a person) and an **AI agent** that reads the submission against that stage's requirements and produces a verdict with reasons. The owner confirms it or overrides it. An item only reaches the end if every stage approves — and a denial doesn't kill it, it goes back to the submitter with a checklist of required changes.

{% hint style="success" %}
**A deal review that reviews itself first**: A rep submits "Acme renewal — 3 year term" with the signed LOE and the pricing sheet. The Finance stage's agent opens both files, confirms the uplift math, and approves. The Legal stage's agent finds that the liability cap wasn't updated, so it returns the item with two specific changes. The rep fixes them, ticks both off, and resubmits — the review resumes at Legal, not back at Finance.
{% endhint %}

{% hint style="info" %}
**Pipelines is in Beta** and is available on plans that include it. If you don't see **Pipelines** under **Build** in the navigation, it isn't enabled for your organization.
{% endhint %}

## Who Is This For?

* **Deal desks & sales leadership** — pricing, discount, and renewal approvals with an audit trail
* **Legal & contracts teams** — first-pass contract review that catches the obvious problems before a human reads it
* **Finance** — margin, LOE, and invoice checks against a written bar
* **Delivery & engineering leads** — design reviews, change requests, go-live readiness
* **Compliance & security** — vendor intake, questionnaire review, exception requests
* **Anyone who owns a queue** — if work reaches you as "can you take a look at this?", that's a stage

## Key Benefits

| Benefit                       | Description                                                                                           | Business Impact                                                |
| ----------------------------- | ----------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| **Agent-First Review**        | Each stage's agent reads the submission and produces a verdict with reasons before a person looks     | Reviewers arrive at a decision, not a pile of files            |
| **Real Ownership**            | Every stage has a named owner, and the agent runs as that owner with their integrations               | Decisions stay accountable to a person                         |
| **Actionable Denials**        | A return carries a numbered checklist of required changes                                             | Submitters know exactly what to fix                            |
| **Resume, Don't Restart**     | A revision re-enters at the stage that returned it                                                    | No re-approving the stages that already passed                 |
| **Apply Changes**             | Darcy can work the required changes itself, edit the scope of work, and resubmit                      | The mechanical half of a revision stops costing anyone a day   |
| **Private Reviewer Guidance** | Requirements are public to submitters; extra agent guidance is not                                    | Reviewers can steer the agent without coaching the submitter   |
| **Documents as Output**       | A stage can be configured to produce files — a memo, a redline, a filled-in checklist                 | Review chains that generate the artifact, not just an answer   |
| **Context That Travels**      | Submissions can carry files, meetings, and scopes of work, re-read from the source before each review | Reviewers judge the scope as it stands today, not a stale copy |
| **Completion Summary**        | An approved item gets a written account of the whole run                                              | The record is readable months later                            |
| **Full Visibility**           | A board per pipeline, a personal queue, an event timeline, and agent transcripts for reviewers        | Nothing is stuck without someone knowing                       |

## How Pipelines Work

```mermaid
graph LR
    A["Submit<br/>title, summary, files"] --> B["Stage 1<br/>agent reviews"]
    B --> C{"Stage 1 owner<br/>decides"}
    C -->|Approve| D["Stage 2<br/>agent reviews"]
    D --> F{"Stage 2 owner<br/>decides"}
    F -->|Approve| G["Approved<br/>+ deliverables"]
    C -->|Return| E["Returned to submitter<br/>with required changes"]
    F -->|Return| E
    E -->|Resubmit| B
    E -->|Resubmit| D
```

A resubmission re-enters at **the stage that returned it**, so the approvals already given stand.

| Step         | What Happens                                                                                                                        |
| ------------ | ----------------------------------------------------------------------------------------------------------------------------------- |
| **Build**    | A pipeline owner creates the pipeline and adds a stage per reviewer, each with requirements, an owner, and an agent                 |
| **Publish**  | The pipeline goes from *draft* to *active* and starts accepting submissions                                                         |
| **Submit**   | Someone submits an item — a title, a summary, and up to 10 files — and the first stage's review starts immediately                  |
| **Review**   | The stage's agent reads the requirements and the files, then approves or denies with reasons and a list of required changes         |
| **Decide**   | The stage owner confirms the agent's recommendation or overrides it — or, in *Agent decides* mode, the verdict stands on its own    |
| **Revise**   | A returned item goes back to the submitter, who works the checklist and resubmits to the same stage                                 |
| **Complete** | Once the last stage approves, the item is approved, deliverables from every stage are gathered, and a completion summary is written |

## Item Statuses

| Status             | Meaning                                              | Who holds it    |
| ------------------ | ---------------------------------------------------- | --------------- |
| **In review**      | A stage's agent is working                           | Nobody — wait   |
| **Awaiting owner** | The agent has answered; the verdict needs confirming | The stage owner |
| **Returned**       | A stage denied it; required changes are listed       | The submitter   |
| **Approved**       | It cleared every stage                               | Done            |
| **Cancelled**      | Withdrawn by the submitter or the pipeline owner     | Nobody          |

## Pipelines vs. Workflows

Pipelines and [Workflows](/build/ai-workflows.md) both put agents to work, but they answer different questions:

|                       | Workflows                            | Pipelines                                       |
| --------------------- | ------------------------------------ | ----------------------------------------------- |
| **Question answered** | "Produce this for me"                | "Is this good enough to pass?"                  |
| **Shape**             | Tasks executed by one or more agents | Ordered stages, each with a human owner         |
| **Who is involved**   | The person who runs it               | A submitter and one reviewer per stage          |
| **Outcome**           | A generated deliverable              | A decision — approved, or returned with changes |
| **Human role**        | Reviews the result at the end        | Owns a gate in the middle                       |

Use a workflow to *create* something. Use a pipeline to *approve* something — including something a workflow created.

## Who Can Do What

| Role                    | Capabilities                                                                                                                                        |
| ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Pipeline owner**      | Create and edit the pipeline, add/reorder/delete stages, reassign stage owners, publish, archive, delete, share — and override any stage's decision |
| **Stage owner**         | Configure their own stage (requirements, agent, guidance, decision mode, outputs) and decide on items at it                                         |
| **Additional approver** | Decide on items at a stage they don't own, and see the pipeline — without configuring the stage or running its agent                                |
| **Submitter**           | Submit items, work the findings checklist, resubmit, cancel their own item                                                                          |
| **Shared viewer**       | See the pipeline and its items without deciding on them                                                                                             |

Stage owners can configure their own stage without holding edit rights on the whole pipeline. Only the pipeline owner can hand a stage to someone else.

## Getting Started

{% stepper %}
{% step %}
**Open Pipelines** Go to **Build → Pipelines**. The home page shows your personal queue, a place to submit, and every pipeline you can see.
{% endstep %}

{% step %}
**Create a pipeline** Give it a name, a description, and intake instructions telling submitters what to include. It starts as a **draft** and accepts nothing yet. See [Building a Pipeline](/build/pipelines/building-a-pipeline.md).
{% endstep %}

{% step %}
**Add a stage per reviewer** Each stage needs a name, an owner, an agent, and requirements — the bar a submission has to clear. Requirements are shown to submitters before they submit.
{% endstep %}

{% step %}
**Publish** Publishing turns the pipeline *active*. If a stage is missing an owner or an agent, publishing tells you exactly which one.
{% endstep %}

{% step %}
**Submit the first item** Use **Submit item** on the pipeline. The first stage's agent starts reviewing straight away. See [Submitting & Revising Items](/build/pipelines/submitting-items.md).
{% endstep %}

{% step %}
**Work your queue** Reviewers see what needs their decision on the Pipelines home page and get notified when an item reaches their stage. See [Reviewing & Deciding](/build/pipelines/reviewing-and-deciding.md).
{% endstep %}
{% endstepper %}

## Next Steps

| Goal                                         | Documentation                                                                |
| -------------------------------------------- | ---------------------------------------------------------------------------- |
| Create a pipeline and configure its stages   | [Building a Pipeline](/build/pipelines/building-a-pipeline.md)               |
| Submit work and respond to a return          | [Submitting & Revising Items](/build/pipelines/submitting-items.md)          |
| Work a review queue and make decisions       | [Reviewing & Deciding](/build/pipelines/reviewing-and-deciding.md)           |
| Get files out of a pipeline                  | [Deliverables & Completion](/build/pipelines/deliverables-and-completion.md) |
| Drive pipelines from chat, agents, or MCP    | [Pipelines with Darcy](/build/pipelines/pipelines-with-darcy.md)             |
| Configure the agents that do the reviewing   | [Agents](/core-features/agents.md)                                           |
| Generate documents instead of approving them | [Workflows](/build/ai-workflows.md)                                          |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.darcyiq.com/build/pipelines.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.