> 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/connect-systems.md).

# Connect systems

Give an Agent authorised access to business systems and understand the boundary between Connection authority and Skill instructions.

An Agent becomes operationally useful when it can work with the systems where the business already keeps its records and communication.

Examples include email, CRM, ERP, calendars, spreadsheets, file stores and support systems.

## Connection authority is separate from Skills

A **Connection** is the authorised account or application access behind Agent and Workflow actions.

The Connection answers **what Lleverage is allowed to access or do**. A Skill answers **how the Agent should use that capability for a recurring task**.

A Skill does not grant the credential. Removing a Skill does not revoke the Connection, and adding a Skill should never be treated as granting new external-system authority.

![Skill and Project Connection authority paths.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2F5lrJ0JV0E4PV2QeGmOq6%2Fconnect-systems.svg?alt=media)

## Use the normal Connections flow

The canonical place to inspect and manage project Connections is [Control → Connections](/administer-and-govern/control/connections.md).

Before connecting a production account, decide:

* which external identity should authorise it;
* what data and actions that identity can access;
* which Lleverage actions should be enabled;
* whether sensitive actions should require additional approval;
* which Project the connection belongs to.

The connection's authority matters more than its label. A technically valid mailbox or ERP account can still have much broader access than the Agent actually needs.

## The Agent can initiate a supported connection

You can also ask the in-product Agent to connect a supported service. For supported OAuth providers, the Agent can initiate the authorisation flow and the user completes the provider's OAuth step.

The current Agent-initiated credential is project-bound. After the connection is complete, verify it in [Control → Connections](/administer-and-govern/control/connections.md) and test the exact read/write action needed for the operational task.

![The Agent initiating an Outlook connection from the conversation before the user completes sign-in.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2Fkz1pGAsOeeAx8ikVESgh%2Fagent-connect-outlook.png?alt=media)

## Never paste credentials into the conversation

Do not put passwords, API keys or other secrets in the Project description, Skills, chat messages, project files or Workflow payloads just to make a connection work.

Use the product's Connection, Secret or secure credential path. The Agent needs the resulting authorised capability, not the raw secret.

## If there is no native provider

Use a custom integration for systems that need a custom API connection.

The business instructions should still describe the operational action the Agent needs, not the mechanics of carrying credentials around.


---

# 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/connect-systems.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.