> 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/building-a-pipeline.md). # Building a Pipeline Create a pipeline, configure each stage's owner, agent, requirements and outputs, then publish it to start accepting submissions A pipeline is built once and used many times, so it's worth spending the time on the stages. Everything a reviewer's agent knows about its job comes from the stage you give it. {% hint style="success" %} **A three-stage deal review**: *Verify LOE* (owner: Finance lead, agent checks the effort matches the pricing sheet) → *Legal review* (owner: Counsel, agent checks the liability cap and the renewal clause, and writes a risk memo) → *Sign-off* (owner: VP Sales, agent decides on its own once the first two have passed). {% endhint %} ## Creating the Pipeline {% stepper %} {% step %} **Click New pipeline** From **Build → Pipelines**, create a pipeline. You need the pipeline-create permission for your organization. {% endstep %} {% step %} **Fill in the basics** A **Name** (required), a **Description** of what this reviews and who it's for, and **Intake instructions** telling submitters what to include — "the signed LOE and the pricing sheet". Intake instructions are shown on the submission form. {% endstep %} {% step %} **Add your stages** You land on the pipeline's board with the first stage's editor open. Add one stage per reviewer, in the order they should review. {% endstep %} {% step %} **Publish** The pipeline is a **draft** until you publish it, and a draft accepts no submissions. {% endstep %} {% endstepper %} ## Configuring a Stage | Field | Who sees it | Notes | | --------------------------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | **Name** (required) | Everyone | The gate, not the person — e.g. "Verify LOE" | | **Stage owner** | Everyone | The person accountable for this gate. **The agent runs as this user**, with their integrations and credentials — not the submitter's | | **Additional approvers** | Everyone | Other people who may make the decision at this stage, without owning it (see below) | | **Requirements** | Submitters too | The bar a submission must clear. Shown to submitters *before* they submit, and given to the agent as the standard to judge against | | **Decision mode** | — | Whether the owner confirms the verdict or the agent's verdict stands (see below) | | **When the submitter dismisses an ask** | — | Whether a checklist cleared by dismissing asks waits for you to accept it (the default) or moves on by itself | | **Agent** | Everyone | Which [agent](/core-features/agents.md) reviews at this stage. Required before publishing | | **Extra agent guidance** | Reviewers only | Private steer for the agent — "reject scanned copies". Submitters never see this | | **Pass findings to later stages** | Later stages' agents | Off by default. Hidden on the last stage, which has nowhere to forward to | | **Produces deliverables** | — | The agent writes files as well as deciding | {% hint style="warning" %} **The agent runs as the stage owner.** It inherits that person's integrations and credentials, which is what lets a Legal stage read from SharePoint while a Finance stage reads from the CRM. It also means a stage owner change changes what the agent can reach. {% endhint %} ### Writing Requirements That Work Requirements do double duty: they're the checklist a submitter reads before submitting, and the standard the agent judges against. Write them as things that can pass or fail. | Instead of | Write | | ----------------------------- | ----------------------------------------------------------------------------------------------------------- | | "Make sure the deal is sound" | "Term is 12, 24, or 36 months. Uplift is stated as a percentage. The pricing sheet totals match the LOE." | | "Check the contract" | "Liability cap is present and no higher than 12 months of fees. The renewal clause states a notice period." | The stage's agent doesn't only see an excerpt — submitted files are placed **on the agent's cloud computer**, so it can open a document in full. That means requirements and guidance can tell it to go and look: *"open the contract and check that clause 7 survives the renewal"* is a reasonable instruction, and it works even on a scanned PDF or a spreadsheet that text extraction can't handle. ### Decision Modes | Mode | Behavior | Use when | | ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | | **Agent recommends, I decide** (default) | The agent produces a verdict and the item waits on the stage owner to confirm or override it | The decision carries weight, or you're still learning to trust the agent at this stage | | **Agent decides** | The agent's verdict moves the item on its own — approving it to the next stage, or returning it to the submitter | The check is mechanical and well specified, and you'd rather not be a bottleneck | In either mode the reasons, findings, and transcript are recorded, so an *Agent decides* stage is still fully auditable. ### Sharing a Stage's Decision A stage can name **additional approvers** alongside its owner — a second counsel who can sign off while the first is on leave, or a small team who share a queue. They're additive, not a replacement: | | Stage owner | Additional approver | | ----------------------------------------- | ----------- | -------------------------------------- | | Makes the decision | Yes | Yes | | The agent runs as them | **Yes** | No | | Configures the stage | Yes | No | | Notified when an item arrives | Yes | Yes | | Can read the agent's transcript and notes | Yes | Yes | | Sees the pipeline and its items | Yes | Yes — access comes with the assignment | Only the **pipeline owner** can change a stage's additional approvers, the same rule that governs reassigning the owner itself. {% hint style="info" %} **Additional approvers are set through Darcy or the API, not the stage editor.** The stage panel covers the owner; ask Darcy to add approvers to a stage, or use the API. See [Pipelines with Darcy](/build/pipelines/pipelines-with-darcy.md). {% endhint %} ### What a Stage Passes On By default, a later stage sees only that an earlier one approved, plus its one-line reason. * **Pass findings to later stages** — later reviewers' agents also see this stage's agent **notes** and any files it produced, quoted inline where they're text. Turn it on when a later stage's job builds on an earlier one's: legal reads what finance actually verified rather than re-deriving it. Leave it off when stages should judge independently, so one reviewer's read doesn't bias the next. Forwarding reaches *every* later stage, and only applies to stages that approved. * **Produces deliverables** — the agent writes files as well as deciding. The switch doesn't say *what* to write: describe the artifact in **Requirements** or **Extra agent guidance**. "A one-page risk memo as `risk-memo.md`, listing every exception you found" gets you a memo; "produce a memo" doesn't. See [Deliverables & Completion](/build/pipelines/deliverables-and-completion.md). ## Publishing, Archiving & Deleting | Action | Who | Effect | | ----------- | -------------- | ----------------------------------------------------------------------------------------------------------------------- | | **Publish** | Pipeline owner | Draft → **active**. Refused while any stage is missing an owner or an agent, and it names the stages that need fixing | | **Archive** | Pipeline owner | Active → **archived**. Intake closes; items already in flight keep moving to a verdict. Reversible — publish reopens it | | **Delete** | Pipeline owner | Removes the pipeline **and every item ever submitted to it**. Available from the pipelines roster | {% hint style="danger" %} **Archive, don't delete.** A pipeline owns every submission ever made to it, so deleting one destroys other people's work and the review history they were promised. Archiving closes intake reversibly and is almost always what "retire this pipeline" means. Deleting cannot be undone. {% endhint %} ## Changing a Live Pipeline Editing a published pipeline is allowed — reviewers tune their own requirements and guidance all the time — but structural changes are restricted: * Only the **pipeline owner** can reassign a stage owner, change its additional approvers, delete a stage, or reorder stages * A **stage owner** can configure their own stage without edit rights on the pipeline * **Reordering and deleting are refused while items sit at the stages involved**, because a moved stage would make an in-flight item skip or revisit a review. Resolve or cancel those items first * Reordering takes every stage into a new order, so the numbers you see on the board always match the order of review {% hint style="info" %} **An item stuck at a stage is not a structure problem.** Reordering won't unstick it — the fix is a decision at that stage, or a re-run if the agent errored. See [Reviewing & Deciding](/build/pipelines/reviewing-and-deciding.md). {% endhint %} ## Sharing & Access | Who | How they get access | | ------------------------ | ------------------------------------------------------------------------------------------------------------ | | **Pipeline owner** | The creator | | **Stage owners** | Assigned to a stage — they see the pipeline and its items automatically | | **Additional approvers** | Named on a stage — access comes with the assignment, same as an owner's | | **Submitters** | Anyone who can see the pipeline can submit to it, and always sees their own items | | **Shared viewers** | Added through **Share** on the pipeline, individually or via [Groups](/settings-and-configuration/groups.md) | Use **Share** in the pipeline header to give someone visibility — a sales manager who wants to watch the deal desk queue without owning a stage. ## Next Steps | Goal | Documentation | | ------------------------------------- | ---------------------------------------------------------------------------- | | Submit the first item | [Submitting & Revising Items](/build/pipelines/submitting-items.md) | | Work the review queue | [Reviewing & Deciding](/build/pipelines/reviewing-and-deciding.md) | | Configure a stage that produces files | [Deliverables & Completion](/build/pipelines/deliverables-and-completion.md) | | Build a pipeline by asking Darcy | [Pipelines with Darcy](/build/pipelines/pipelines-with-darcy.md) | | Configure the reviewing agents | [Agents](/core-features/agents.md) | | Manage access with groups | [Groups & Access Control](/settings-and-configuration/groups.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/building-a-pipeline.md?ask=&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.