> 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/prepare-the-agent-for-operators.md).

# Prepare the Project for operators

Hand the Agent to operators with the right access, channel routing, starting tasks, feedback path and human boundaries.

A technically capable Agent is not finished until the right people can use it in the right operational context and know what to do when the result is uncertain or wrong.

## Access

Use **Control → Members** to decide who can operate the Agent, who can build or change capabilities, and who owns administrative configuration.

Do not use navigation hiding as access control. Project and organisation permissions determine authority; layout only changes what is shown.

## Operator channels

Operators can work in the Lleverage web Agent and, where configured, through Slack or Microsoft Teams.

A web session opened inside a Project has an explicit Project context.

Slack and Teams can also run unpinned at organisation scope using the acting user's authorised Project scope for that run. Pin the conversation when the work belongs to one Project, capabilities overlap, or you want the clearest later inspection path.

Test the actual channel experience before treating rollout as complete.

## Starter tasks

Do not launch with only “ask me anything”.

Project builders can use **Edit page** on the Project Agent page to tailor its starter cards to the work operators should recognise immediately. Keep the cards outcome-led: they should help someone start useful work, not expose implementation jargon.

Give people a few concrete examples in their own language:

* “Check why order 4831 is blocked and tell me what is missing.”
* “Prepare supplier follow-up for purchase orders without a confirmed delivery date.”
* “Run the certificate check on these documents and show me the exceptions.”
* “Where is this week's production plan at risk?”

Good starter tasks communicate the Agent's operational responsibility better than a feature list.

## Agent authority

Operators should know:

* which systems and records are authoritative;
* which actions the Agent can execute;
* which actions require approval;
* when the Agent should ask rather than infer;
* what the person still owns.

If the Project also contains background Workflows, explain where explicit Workflow Requests appear and what happens after someone responds.

## Result verification

For important tasks, teach operators to inspect the result, not just the chat reply.

That may mean opening the generated document, checking the ERP record, reviewing the source file or looking at the session activity.

The Agent workspace is an evidence surface; the business system remains the system of record.

## Feedback

Project members can leave session outcome feedback after Agent work.

Ask for actionable feedback when something is wrong:

* what was wrong;
* where it appeared;
* which evidence should have been used;
* what the expected result was.

Builders can review this feedback with Activity and use recurring issues to improve and test the relevant Skill or setup.

## Initial production review

During rollout, review representative sessions and recurring corrections.

If operators repeatedly explain the same rule, make it durable. If a task becomes high-volume and predictable, consider moving its stable path into a Workflow while keeping the Agent for variable foreground work.

A successful handover leaves operators knowing three things:

**what work the Agent owns, when they should intervene, and how they can verify or report a bad result.**


---

# 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/prepare-the-agent-for-operators.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.