> For the complete documentation index, see [llms.txt](https://docs.lleverage.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lleverage.ai/build-and-improve/automate/human-handoffs.md). # Human handoffs Add deliberate human decisions or input to a running Workflow without confusing them with Agent conversation. Use a human handoff when a Workflow reaches a decision or missing piece of information that should not be guessed or executed without a person. The current builder exposes two human-handoff actions: * [Request Decision](/build-and-improve/automate/human-handoffs/request-approval.md) — ask an assigned person to choose from defined options. * [Request Input](/build-and-improve/automate/human-handoffs/request-input-page.md) — ask an assigned person to provide information through a configured form. ![Request Decision and Request Input side by side in the Workflow builder, showing their different configuration and output shapes.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2FZtVNA6FwPA7wv90HaTF7%2Frequest-decision-input-config.png?alt=media) A **Request Decision** produces one output path per option, so the canvas can branch on the person's answer. A **Request Input** collects configured form data and continues on one output path. Both remain explicit Workflow pauses rather than Agent conversation. In a live Workflow, either action pauses execution, creates a **Pending** item in [Requests](/run-operations/request-inbox.md) and stores the execution state needed to resume. When an authorised user completes the Request, the Workflow resumes from that saved point. ## Requests are Workflow handoffs Request items are created by Workflows. They are separate from the [Agent](/run-operations/agent.md)'s own human-interaction mechanisms. The Agent can ask a question in a session or require approval for an action without creating a Request item. See [Requests, exceptions and human attention](/understand-lleverage/readme/requests-exceptions-and-human-attention.md) for the conceptual distinction and the operator-facing [Requests](/run-operations/request-inbox.md) page for what the assigned person sees and does. ## Assignment is part of the boundary A live Request must be assigned. The current Request nodes expose **user assignment** in the builder, and the system verifies that the person completing the Request is authorised for that assignment. The exact wording, decision options, form fields, assignee and point in the process are specific to the Workflow your organisation has configured. For the wider ownership question — who should remain accountable for which decisions — see [Human boundaries and operational ownership](/administer-and-govern/governance/human-boundaries-and-operational-ownership.md). ## Requests pause, they do not retry A Request is a pause in the execution path, not an error. Node retry settings do not re-issue a Request. If the same Request node is encountered again while an identical pending Request already exists, Lleverage reuses that pending handoff rather than intentionally creating duplicate work. Completed Requests can be reopened in supported cases to replay from that point. Reopen the latest completed Request in a reopen chain; earlier superseded ancestors cannot be reopened independently. For retry and failure behaviour outside human handoffs, see [Error handling and validation](/build-and-improve/automate/test-and-publish/error-handling-and-validation.md). ## SLA fields are informational today A Request can record priority and an SLA deadline. Today that deadline can be used as Request data for sorting and filtering, but Lleverage does not automatically escalate Requests or transition them to at-risk/overdue states. Build any required escalation behaviour explicitly rather than assuming the SLA field enforces it. ## Where to go next * Configure a decision → [Request Decision](/build-and-improve/automate/human-handoffs/request-approval.md) * Collect structured input → [Request Input](/build-and-improve/automate/human-handoffs/request-input-page.md) * See the operator experience → [Requests](/run-operations/request-inbox.md) * Inspect how the handoff behaved in execution → [Monitoring](/build-and-improve/monitoring.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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.lleverage.ai/build-and-improve/automate/human-handoffs.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.