> For the complete documentation index, see [llms.txt](https://comunity.gitbook.io/learning.comunitynexus/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://comunity.gitbook.io/learning.comunitynexus/26.2/toolkit-guides/intelligence.md).

# Intelligence

{% hint style="info" %}
**You must be signed in as an Organisational Administrator.** Intelligence is not available to the Developer, Lead Developer, Operations or Viewer roles, which do not see the menu at all. See [Roles and Permissions](/learning.comunitynexus/26.2/getting-started/organisations/roles-and-permissions.md).
{% endhint %}

Intelligence adds AI agents to a project. The agents are configured in the Toolkit, run against the project's own data, and are called from the project once it is running.

This is not the same as building a project with AI. Agent Build creates and changes projects. Intelligence creates agents that work inside a project you have already built.

The capability is in preview, and appears in the Toolkit as **Intelligence (Preview)**.

## What Intelligence is for

An agent is not a way to express a rule. Where an outcome follows from a condition you can state, a rule in the data service is cheaper, faster and easier to reason about. An agent earns its place where a decision has to be inferred from data rather than derived from it.

That distinction settles most cases:

| Belongs in a rule                                       | Belongs in an agent                                                   |
| ------------------------------------------------------- | --------------------------------------------------------------------- |
| A fault older than 48 hours is escalated                | Free text on an inbound fault suggests it should be escalated         |
| A claim above a set value needs a second approval       | A claim carries several weak indicators that together suggest fraud   |
| A user without a verified email address cannot transact | A newly registered user resembles someone worth contacting personally |

## Worked examples

* **Screening inbound faults.** Every fault logged is passed to an agent, which reads the free text and flags profanity, or a description warranting escalation beyond the category the reporter chose.
* **Noticing concentration.** An agent watching faults as they arrive identifies an unusual volume of electricity faults in one area over a short period, and raises it with the responsible team.
* **Recognising who is reporting.** A fault logged by someone of political or commercial significance is brought to a senior manager's attention rather than queued normally.
* **Assessing a claim.** An insurance claim is checked against several sources at once, and the indicators are weighed the way an assessor would weigh them, to produce a view on whether the claim merits investigation.
* **Summarising a period.** A scheduled agent reviews the previous day's claims each morning and sends the responsible manager a summary.

The common thread is that none of them can be written as a condition. Each requires reading something unstructured, or weighing several signals at once, and returning a judgement.

## The parts

| Part          | What it is                                                                                                   |
| ------------- | ------------------------------------------------------------------------------------------------------------ |
| **Provider**  | The Azure AI Foundry infrastructure your project's agents run on.                                            |
| **Model**     | A model deployed under a provider, with its capacity, provisioning type and content filters.                 |
| **Tool**      | Access an agent is given to something beyond the conversation: project data, a function, an index, a server. |
| **Agent**     | The instructions, model settings and tools that define one role.                                             |
| **Trigger**   | What causes an agent to run: a schedule, or a change to project data.                                        |
| **Knowledge** | The documents and indexes an agent reasons against.                                                          |

Those parts connect in one direction: an agent draws on a model and on the tools it holds, and a trigger is what runs the agent. The [Overview](/learning.comunitynexus/26.2/toolkit-guides/intelligence/monitor-agent-activity.md) graph draws exactly those relationships.

## The order of work

The pieces depend on each other, so they are built in this order:

1. [Set up a provider and deploy a model](/learning.comunitynexus/26.2/toolkit-guides/intelligence/set-up-a-provider-and-deploy-a-model.md). Nothing else runs until a model is available.
2. [Create a tool](/learning.comunitynexus/26.2/toolkit-guides/intelligence/create-a-tool.md) for each thing the agent must reach. An agent without tools can only converse.
3. [Create an agent](/learning.comunitynexus/26.2/toolkit-guides/intelligence/create-an-agent.md), write its instructions, and attach its tools.
4. [Trigger an agent](/learning.comunitynexus/26.2/toolkit-guides/intelligence/trigger-an-agent.md), then build the project.

Chat is available on every agent from the moment it exists, so an agent can be exercised in the playground before any trigger is defined.

## Everything is scoped to an environment

Intelligence is organised by environment, as most project configuration is. The Providers screen asks you to select an environment in order to configure that environment's models, tools and agents, and Triggers reports that no environments are configured until one exists.

Within an environment the provider comes first. Until one exists, Models, Tools, Agents and Knowledge Management each show only a prompt to create one.

## Where an agent runs

Agents are configured in the Toolkit and published to Azure AI Foundry. Calling an agent, whether from the playground or from your project, is a call to Foundry.

Where Foundry cannot be reached, the agent still runs. The platform's agentic service completes the run in the platform core instead, and marks it as a fallback in the run history. A run that never reached Foundry is therefore distinguishable from one that did, rather than presenting as a failure.

## Where to go next

* [Set up a provider and deploy a model](/learning.comunitynexus/26.2/toolkit-guides/intelligence/set-up-a-provider-and-deploy-a-model.md): the infrastructure, and the one prerequisite for everything else
* [Create a tool](/learning.comunitynexus/26.2/toolkit-guides/intelligence/create-a-tool.md): give an agent something to act with
* [Create an agent](/learning.comunitynexus/26.2/toolkit-guides/intelligence/create-an-agent.md): instructions, model settings, and the playground
* [Trigger an agent](/learning.comunitynexus/26.2/toolkit-guides/intelligence/trigger-an-agent.md): run it on a schedule or on a change to your data
* [Connect agents](/learning.comunitynexus/26.2/toolkit-guides/intelligence/connect-agents.md): handoff within a project, and agent to agent beyond it
* [Add knowledge to an agent](/learning.comunitynexus/26.2/toolkit-guides/intelligence/add-knowledge-to-an-agent.md): the material an agent reasons against
* [Monitor agent activity](/learning.comunitynexus/26.2/toolkit-guides/intelligence/monitor-agent-activity.md): the Overview graph, its metrics, and provider health