Prepare the Agent 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.

Give people the right 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.

Decide where operators should meet the Agent

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.

Give operators recognisable starting work

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.

Explain what the Agent is allowed to do

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.

Show people how to verify the work

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.

Give feedback a clear route

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.

Watch the first real work

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.