Build an Agent

Set up an Agent for real operational work: define its role, let it build its Skills and Connections, give it context, test it and prepare it for operators.

For many Lleverage builders, the main job is not drawing a Workflow. It is setting up an Agent that can take responsibility for a real area of operational work.

The Agent is also part of the builder experience. You do not have to configure every capability through separate admin screens: the Agent can help build its own Skills and initiate Connections, with dedicated in-product review/setup UI around those actions.

Start with a process the business recognises: handling incoming orders, preparing tenders, chasing suppliers, checking invoices, investigating production exceptions, maintaining master data or answering operational questions. Then give the Agent the instructions, methods, systems and evidence it needs to do that work reliably.

A useful setup sequence is:

1. Build your first Agent end to end. Start with one real operational job and carry it through source authority, Connections, a reusable Skill, Tests and a fresh operator run.

2. Define the Agent's role and instructions. What work is it responsible for, what should it never guess, and when should it involve a person?

3. Build Skills with the Agent. Give it representative work and let it turn recurring methods into reviewed reusable Skills.

4. Connect the systems it needs. Ask the Agent to initiate supported Connections, or use a custom integration when there is no native provider.

5. Give it working context. Add the right Files, Tables, Knowledge and Memory without duplicating authoritative business records unnecessarily.

6. Test and improve it. Use representative cases and inspect the evidence around the result, not only the final response.

7. Prepare it for operators. Give the right people access and, where useful, expose the Agent through Slack or Microsoft Teams.

Agent setup is broader than prompting

A production Agent is a configured operating environment, not a clever system prompt.

Its behaviour can depend on several layers:

• Project description and Agent settings establish the Project, carry persistent Project-level direction and shape the Agent's general behaviour.

• Skills encode how recurring tasks should be handled — and can be authored/improved with the Agent itself.

• Connections give authorised access to external systems — and can be initiated from the Agent where supported.

• Files, Tables, Knowledge and Memory provide different kinds of context and working material.

• Members and Channels determine who can use the Agent and where they can reach it.

• Monitoring and session evidence help you see what actually happened and what should be improved.

Put a rule at the narrowest useful level. A company-wide fact should not be copied into every Skill. A rule that belongs only to invoice matching should not become a general Project instruction. A live ERP record should normally remain in the ERP rather than being copied into Memory.

The Agent is a builder interface

The in-product Agent is not only an operator surface. It can help configure its own working environment.

Two especially important examples are:

• Skills — the Agent can write a new Skill from the task, examples and constraints you provide, show the proposed Skill in the Skill-building UI, and later propose reviewed updates;

• Connections — the Agent can initiate supported OAuth Connections and guide custom-integration setup, while credential entry remains outside ordinary Agent context.

The explicit Intelligence and Control pages remain the canonical inventory and management surfaces. The Agent provides the guided building experience on top of them.

When to build a Workflow instead

Do not turn flexible Agent work into a Workflow just because a Workflow can be drawn.

Use Automate when a part of the operation has a sufficiently defined path that repeatability and explicit control matter more than open-ended interpretation. An Agent setup and Workflows commonly coexist: the Agent handles variable foreground work while repeatable parts run in the background.

Where to go next

For defined background execution, go to Automate. For the detailed project context surfaces, use Intelligence. To investigate actual executions, use Monitoring. Administrative mechanics such as Members, Connections and Channels are documented under Control.