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.

For a supported provider the Agent initiates and a human authorises before the Connection holds authority; for a custom integration the secret is entered securely outside Agent context and later runtime uses the Connection.

Use the normal Connections flow

The canonical place to inspect and manage project Connections is Control → Connections.

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 and test the exact read/write action needed for the operational task.

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.