> 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/overview/give-the-agent-context.md).

# Project context

Give the Agent durable working context using Files, Tables, Knowledge and Memory without blurring their different authority models.

A capable Agent needs more than instructions and system access. It also needs the right working context for the operational area.

The current Intelligence surfaces deliberately separate different kinds of context:

* **Files** — documents, spreadsheets, PDFs, images and other working material or outputs;
* **Tables** — maintained structured data and mappings;
* **Knowledge** — maintained reference material such as procedures and manuals;
* **Memory** — useful persistent context carried across Agent work;
* **Skills** — reusable methods for doing the work.

Use those distinctions rather than putting everything into one prompt or folder.

## Source authority

If the current sales order, stock balance or supplier commitment lives in an ERP, the ERP normally remains the authoritative source. Give the Agent a Connection to read it when needed.

Use Intelligence for context that genuinely belongs in the Project: mappings, working documents, approved reference material, task methods and persistent context.

## Files

Project Files can be used as durable material available to the Project, while session attachments and generated files belong to the work of a particular session unless deliberately retained elsewhere.

Do not document or design around planned repository/sync capabilities that are not yet current product behaviour. In particular, external folder synchronisation and richer writable-repository semantics should only be relied on once they are actually deployed.

## Tables

Use a Table for data that benefits from explicit fields and repeated lookup, such as customer aliases, product mappings, routing rules or maintained operational reference data.

Do not duplicate a live source system into a Table without a clear ownership and refresh model.

## Knowledge

Use Knowledge for policies, procedures, manuals and other material the Agent should retrieve as reference. Make provenance and approval status obvious where it matters.

Lleverage can also provide built-in industry and process guidance for common operational patterns. Treat that as general starting context. Customer-specific policies, mappings, terms and live facts still belong in the customer's maintained sources.

## Memory

Memory helps carry useful Project context across Agent work. Supported session processing can extract reusable facts and reflections after a conversation, and relevant Memory can be retrieved automatically for later runs.

That can make future sessions less repetitive, but it does not mean the whole transcript is copied into Memory or that every statement becomes a durable rule.

When a remembered fact conflicts with a source system, approved document or explicit Project instruction, fix the underlying context rather than teaching operators to work around the conflict in every session.

For the three current Memory layers and builder controls, see [Memory](/build-and-improve/intelligence/memory.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/build-and-improve/overview/give-the-agent-context.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.