> 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.md). # What Lleverage is Understand what Lleverage does, where it sits in your operation, and how it carries recurring work across the systems your company already uses. Lleverage takes on recurring operational work that today depends on people moving information between email, documents, spreadsheets and business systems. That might mean processing an incoming sales order, chasing a supplier confirmation, checking an invoice against a purchase order and goods receipt, preparing a production-planning view, maintaining master data, or answering an operational request with evidence from several systems. The common pattern is that the work does not live neatly inside one application. The ERP may own the order. Email carries the exception. A PDF contains the supplier's commitment. A spreadsheet holds a planning rule. A person knows what to do when the data does not line up. **Lleverage sits across those systems and executes the work between them.** ![Lleverage as the execution layer across existing systems, with Agent for flexible foreground work, Workflows for repeatable background execution, and human handoffs where needed.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2FsvCeYnAFA51VJvcBPvSv%2Fdiagram-1-execution-layer.png?alt=media) ## From incoming work to a completed operation A useful way to understand Lleverage is to follow one piece of work from start to finish. For example, an emailed purchase order might require Lleverage to: 1. read and understand the order; 2. identify the customer, products, quantities and requested dates; 3. check relevant pricing or customer agreements; 4. resolve missing or ambiguous information; 5. create or update the order in the ERP; 6. ask a person when a real judgement or approval is required; 7. produce the confirmation or next action; 8. leave evidence of what happened. A supplier follow-up has the same shape in different language: notice the missing confirmation, contact the supplier, interpret the response, update the expected date, and surface the consequence to planning if it matters. An invoice-matching process is similar again: read the invoice, compare it with the purchase order and receipt, resolve the normal case automatically, and route the discrepancy when a person needs to decide. These examples are not a catalogue of what Lleverage can do. They are representative of the language and process shapes we repeatedly see in the companies Lleverage is built for. See Operational examples for more. ## Lleverage works with the systems you already run Lleverage is not the ERP, inbox, spreadsheet or document store. Those systems remain the places where business records and source material live. Lleverage connects to them so the work can move across system boundaries without a person manually stitching every step together. A sales-order flow might look like: **Email → interpret order → check customer/product/pricing context → ERP → human exception if needed → confirmation** An accounts-payable flow might look like: **Invoice → extract → compare with PO and receipt → resolve or escalate discrepancy → ERP → approval/payment preparation** The value is in carrying the operational job across the whole chain, not in adding another isolated system. ## The work can be executed in different ways Once the business process is clear, Lleverage can execute different parts of it in different ways. ### Agent Use the [Agent](/run-operations/agent.md) when the work is variable, messy or depends on what is discovered along the way. An operator can give it a goal in natural language and let it work with the files, systems, Skills and context available in the Project. Typical examples are investigating an exception, interpreting an inconsistent document, preparing a recommendation, or carrying out a multi-step task where the next action depends on the evidence. ### Workflow Use a [Workflow](/build-and-improve/automate.md) when enough of the path is known to define it in advance. Workflows are suited to repeatable execution and often run in the background without someone actively driving them. A Workflow can still use AI, call connected systems and stop for human input when necessary. ### Human handoffs Some work should remain with people. A running Workflow can create a Request when it reaches a configured point where a person needs to decide or provide information. Agent in-session questions are different: they belong to the foreground conversation rather than the Request Inbox. See Requests, exceptions and human attention for the conceptual distinction. ### Workflow apps A Workflow app gives operators a structured way to start or participate in a published Workflow without opening the builder. The point is not to choose one of these for an entire process. The same operation can combine flexible Agent work, repeatable background execution and deliberate human boundaries. See Humans, Agent and Workflows for that execution model in more detail. ## What sits underneath the execution The execution needs the right systems, instructions and context around it. Lleverage groups these inside a Project. A Project can contain: * Skills that capture how recurring work should be approached; * [Connections](/administer-and-govern/control/connections.md) to ERP, email, file stores and other business systems; * Tables for maintained structured working data; * Files used as input, evidence or output; * Knowledge for maintained reference material; * Memory for useful persistent project context; * [Workflows](/build-and-improve/automate.md) for defined execution paths; * the [Agent](/run-operations/agent.md) as the flexible foreground work surface. [Monitoring](/build-and-improve/monitoring.md) provides evidence of what ran. [Control](/administer-and-govern/control.md) manages access, connections, credentials and other configuration. [Governance](/administer-and-govern/governance.md) defines who remains responsible for the operation and how changes are owned. So the construction is straightforward: **A business process → executed across existing systems → through Agent, Workflows and human handoffs → using the Project's capabilities and context → with Monitoring and Control around it.** ## The level of automation can increase over time The same process can start with a person using the Agent, move toward supervised background execution as the rules become clearer, and eventually let the routine path run autonomously while people handle exceptions. `manual → assisted → supervised → autonomous` is a useful way to describe that progression, but it is not the product architecture and not every process needs to reach the final stage. See From manual to autonomous. The practical question is always the same: **What work does the business need done, how much of it can Lleverage safely take on today, and where should people still be involved?** ## Where to go next * If you use Lleverage day to day, start with [Run operations](/run-operations/overview.md). * If you build or improve the execution, go to [Build and improve](/build-and-improve/overview.md). * If you manage access, systems or credentials, go to [Control](/administer-and-govern/control.md). * If you want concrete process language first, browse Operational examples. --- # 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/understand-lleverage/readme.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.