> 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/reference/faq.md). # FAQ ## What is Lleverage? Lleverage helps companies take recurring operational work out of people's queues. It works across the systems the business already uses and combines Humans, Agents and Workflows to execute the work with the right level of control. See **Understand Lleverage → What Lleverage is** for the fuller model. ## When should I use the Agent versus a Workflow? Use the **Agent** when the work needs interpretation, judgement or adaptation. Use a **Workflow** when the execution path should be defined and repeatable. They can also work together: a Workflow can provide deterministic structure around an Agent, and the Agent can use configured Workflows as capabilities. ## What are Skills? Skills are reusable Agent capabilities. They encode how a recurring task should be done: the outcome, relevant tools and systems, rules/checks, supporting context and when to involve a person. ## Where does the Agent get its context? Depending on project configuration, the Agent can work with Skills, connected systems, Knowledge, Files, Tables, Memory and results from tools or Workflows. These sources do not all have the same authority. Exact business records should normally come from the relevant source system rather than Memory or model inference. ## Where do human approvals and missing-information requests appear? Workflow handoffs appear in **Requests**. Current visible Workflow request actions are **Request Decision** and **Request Input**. In a live run they pause the Workflow and create a pending Request for an assigned user. The Workflow resumes after that Request is resolved. The Agent has separate in-conversation and action-approval mechanisms; those do not create Request Inbox rows. ## Can I test a Workflow before publishing it? Yes, but Test is a **real execution**, not a dry run. It uses real connections and can perform real third-party writes. Test runs also consume execution quota and concurrency. Use representative fixtures and be careful with side-effecting integrations. ## What does publishing a Workflow do? The builder edits a Draft. Publishing promotes it into a Published version. Production traffic uses a version that is Published, active and the default. Publishing can also deploy live trigger or schedule configuration, so it is more than a label change. ## Can I schedule Workflows? Yes. Current scheduling supports interval presets and specific times on selected weekdays, with a configured timezone. Current limitations include no sub-minute schedule, no one-off run-at-date schedule and no day-of-month/month picker in the builder. See **Automate → Test and publish → Scheduling workflows** for the current details. ## What happens when a Workflow action fails? By default, the run stops on an error. Retry is opt-in per supported node. A builder can also configure a node to continue after retries, carrying an explicit error value downstream. There is no general fallback branch/model feature. If you continue after an error, the overall run can still finish with an error status. ## Where do I manage integrations, members and project configuration? Use **Control**. The docs mirror the current Control menu: Connections, Channels, Schedules, Members, Settings, API Tokens, AI Models, Databases, Secrets, Variables, Metrics and Data Sets. ## Where should I store credentials or API keys? Use the dedicated **Secrets**, **API Tokens** or provider connection configuration as appropriate. Do not put credentials in ordinary project files, shared Drive documents, prompts, Workflow instructions or Skill text. ## How do I see what ran and what happened? Use **Monitoring** to inspect executions and traces. A successful technical run is not automatically proof that the operational outcome was correct, so inspect the relevant evidence when quality matters. ## Are Requests a failure state? No. A Request is a designed human boundary. Use one when a decision requires human authority, information is missing, or the Workflow should not safely guess. ## Where do I go next? * Doing operational work: **Run operations** * Building or improving execution: **Build and improve** * Managing project configuration and access: **Administer and govern → Control** * Looking up support/technical details: **Reference** --- # 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/reference/faq.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.