Projects and solutions

Understand a Project as the maintained working environment around an Agent, and how that differs from channel routing and the customer-facing Solution.

A Project is the primary maintained working environment around an Agent and the operational area it supports.

For example, a Project might support sales-order intake, supplier follow-up, production planning, accounts payable or a broader operational area containing several related processes.

The Project brings together the methods, systems, context and execution evidence needed for that work.

What belongs in a Project

Depending on the work, a Project can bring together:

• the Agent for flexible foreground execution;

• Project description and Agent settings for persistent Project-specific behaviour;

• Workflows for defined repeatable execution;

• Skills for reusable operating methods;

• Connections to business systems;

• Tables, Files, Knowledge and Memory for different kinds of context;

• Monitoring for execution evidence;

• project access and administrative configuration under Control.

The question is not “which product objects have we filled in?” It is “does this working environment give the operation the methods, authority, context and evidence it needs?”

Project scope and channel routing are not the same thing

A web Agent session opened inside a Project has an explicit Project context. Do not assume that work in one Project automatically has access to another Project's Skills, Files or other maintained context.

Slack and Microsoft Teams can add a routing layer in front of the Agent. Depending on the channel configuration, a conversation may be pinned to a Project or run at organisation scope. Organisation-scoped routing still respects the user's authorised access; it is not a universal bypass across Projects.

Project-specific behaviour remains important even when a channel starts the conversation. When the work should use one Project's exact Skills, context and Connections, route or pin the channel accordingly.

See Agent in Slack and Agent in Microsoft Teams for the current channel behaviour.

What we mean by a Solution

You may also hear the word Solution when working with Lleverage.

A Solution describes the operational outcome being delivered rather than one specific technical object in the platform.

For example:

Process incoming sales orders from email into the ERP, asking a person only when product or pricing information cannot be resolved confidently.

Delivering that outcome may involve an Agent, Skills, Connections, Workflows, Requests and maintained context.

Solution is customer and delivery language. It is not currently a first-class configurable runtime object in the way a Project is.

The implementation can evolve

The business job can stay the same while its implementation changes.

A process might initially rely on the Agent and regular human review. Stable methods can become Skills. Defined high-volume paths can move into Workflows. Known exception points can become Requests.

See From manual to autonomous for that progression.

Where to go next

• Set up the working environment → Build an Agent

• Run flexible foreground work → Agent

• Understand execution boundaries → Humans, Agent and Workflows

• See representative business processes → Operational examples