> 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/understand-lleverage/readme/humans-agent-and-workflows.md).

# People, Agents and Workflows

Understand how people, the Agent and Workflows divide the execution of a real operational process in Lleverage.

Use Agents, Workflows and human decisions according to the structure of the operational work.

A sales order may need interpretation, ERP writes and an exception decision. Supplier follow-up may need a scheduled check, an email exchange and an update to planning. Invoice matching may run automatically until a discrepancy genuinely needs finance judgement.

Lleverage lets those parts be executed differently rather than forcing one interaction model across the whole process.

![One operational process split between variable Agent foreground work, repeatable Workflow background chunks and deliberate human attention. Agent in-session questions return to the Agent session; only configured Workflow Request boundaries feed the Request Inbox.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2Fgit-blob-4cdd15e33962b986c62d8d5c016d8f1442bf6777%2Fdiagram-7-foreground-background-human-attention.png?alt=media)

## Agent: flexible foreground work

The [Agent](/run-operations/agent.md) is useful when the route through the work depends on what it finds.

Examples include interpreting inconsistent documents, investigating an exception across systems, preparing a recommendation or completing a multi-step task where the next action is not known in advance.

The person is actively involved in the foreground, even if the Agent performs many of the individual steps.

## Workflows: repeatable execution

A [Workflow](/build-and-improve/automate.md) is useful when enough of the path is known to define it in advance.

A Workflow may start from a system event, schedule or operator action, use external systems, run AI steps, and continue without someone driving each action. It can also pause when a human decision is required.

The operator may never see most of that background execution.

## Human decisions

People stay involved where authority, judgement or missing information genuinely requires them.

In a configured Workflow, that handoff appears as a Request. The Workflow pauses, an assigned person responds, and the execution can continue using that response.

Agent questions inside an Agent session are different. They belong to that foreground conversation and do not automatically create Request Inbox items. See Requests, exceptions and human attention.

## Workflow apps: structured operator entry points

A Workflow app exposes a published Workflow to an operator without requiring them to use the builder. It may collect a form, guide a conversation or start background work.

## Combined execution

A single process can move between these modes.

For example:

**Agent investigation → repeatable Workflow path → Request for an exception → Workflow continues → result returned to the operator**

Over time, a process can also shift toward more background execution as rules and exception boundaries become clearer. See From manual to autonomous.

## Related documentation

* Use the [Agent](/run-operations/agent.md) for flexible foreground work.
* Use Workflow apps when a published process has an operator interface.
* Handle assigned exceptions in Requests.
* Build the background path in [Automate](/build-and-improve/automate.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.lleverage.ai/understand-lleverage/readme/humans-agent-and-workflows.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.