> 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/how-lleverage-gets-its-context.md). # Agent context Understand the different layers of instructions, context and system authority that shape Agent work. Lleverage becomes more useful when it can work with the same evidence and context people use to do the job. That context rarely lives in one place. Some of it may be in an ERP. Other parts may live in email, spreadsheets, shared documents, internal guidance, historical examples or the experience of the people doing the work. The important part is not to put all of that into one prompt. Lleverage has different layers for different kinds of context and authority. ## Instruction layers A practical way to think about the setup is: 1. **Organisation and user context** — broad background about the company or person. 2. **Project description** — what this Project is for **and the persistent Project-level directions that should apply across Agent work**. 3. **Skills** — task-specific operating methods for recurring work. 4. **Live session context** — the current conversation, attachments, tool results and evidence gathered for this piece of work. There is not a separate current Agent Instructions field in the deployed Project settings surface. The Project description is the current Project-level instruction channel. Alongside those instruction layers, **Connections, Files, Tables, Knowledge and Memory** provide different kinds of system authority and supporting context. They are not a universal precedence stack: which source is authoritative depends on the question. ![Instruction scope narrows from organisation and user context through Project description, Skill method and live session context, alongside a flat set of evidence sources whose authority depends on the question.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2FWN48P6uHQ97oAWM6H407%2Fdiagram-3-instruction-and-evidence.png?alt=media) Put information at the narrowest durable level where it belongs. This reduces contradictory instructions and makes corrections easier. ### Project scope In a web Agent session, the Project is explicit. A Slack or Microsoft Teams conversation can instead be unpinned and run against the acting user's authorised Project scope. In that case, Project-specific capabilities retain their Project provenance and the Agent may need to disambiguate when several Projects provide plausible context or tools. Pin the conversation when the work should be constrained to one Project. ## Connection authority [Connections](/administer-and-govern/control/connections.md) give Agents and Workflows authorised access to external systems. Depending on the provider and permissions, that can include reading, searching, creating, updating or triggering actions. **The Connection owns the authority. A Skill does not grant the credential.** A Skill can tell the Agent when and how to use a connected system, but removing the Skill does not itself revoke the Connection, and adding a Skill should not be treated as granting new system access. Connecting an ERP therefore does not teach Lleverage how your order process works. It gives Lleverage a way to interact with the ERP as part of that work. ## Knowledge Knowledge contains maintained reference material such as policies, procedures, manuals, product information and internal guidance. Lleverage can also provide built-in industry and process guidance that the Agent loads when relevant. Treat that as a useful starting point for common operational patterns, not as authority over customer-specific rules, policies, master data or live system records. Use it when the Agent needs to retrieve information from a larger body of approved or maintained reference content. ## Files Files can be part of the work itself: an incoming spreadsheet, a PDF, an image, a generated report or another working artefact. Use files for task-specific evidence and working material. A file is not automatically authoritative just because it is available to the Agent. ## Tables Some operational knowledge is better represented as structured data than as documents. Tables provide persistent row-and-column information that Agents and Workflows can use, such as mappings, routing rules, supplier reference data or maintained lookup values. ## Memory Memory carries useful project context across Agent work. It is not a replacement for authoritative business systems or maintained documentation. Information that must be exact, governed or systematically updated should normally live in the appropriate source system, Knowledge, Table or Skill. ## Skills Skills bring instructions and supporting capability together around a reusable Agent task. A Skill can define the outcome, rules, checks, tools to use, relevant context, human boundary and evidence required for recurring work. It can use a Connection, but it does not own the Connection's credential or authority. ## Source authority An ERP record, an approved policy, a user's correction and an Agent inference are different kinds of evidence. Good configuration makes those boundaries explicit: which source is authoritative, which is supporting context, and when uncertainty should be handed back to a person rather than guessed. For the practical setup path, see [Build an Agent](/build-and-improve/overview.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/how-lleverage-gets-its-context.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.