> 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/create-an-agent.md).

# Create an agent

An agent is one role: a set of instructions, a model to run on, and the tools that role is allowed to use.

Agents are found under **Intelligence (Preview)**, then **Agents**.

## Before you start

* A provider with a deployed model. Until a provider exists, Agents shows only a prompt to create one. See Set up a provider and deploy a model.
* The tools this role needs, already defined and tested. See Create a tool. An agent can be created without tools, but it can then only converse.

## Create the agent

An agent is created with a name, a description, and its instructions.

### Write the instructions

The instructions are the agent's system prompt. They bind it on every run, and they are the single largest influence on whether it is useful.

An instruction set that describes a role fully covers:

* What the agent is for, stated as its purpose rather than as one task.
* What it must not do.
* The rules it has to uphold, and any threshold or score it works to.
* How it uses the tools it holds.
* How it addresses whoever it is answering, whether that is a person or another agent.

An agent checking an insurance claim for fraud is told what counts as an indicator, which tools to consult for a client's history, the rules it may not depart from, and the score it has to justify. A vaguer instruction produces a vaguer answer, and no other setting compensates for it.

### Set the model and generation settings

| Setting                                     | What it does                                                                                                                               |
| ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| **Model**                                   | The deployed model the agent runs on.                                                                                                      |
| **Temperature**                             | How much variation the model is permitted. Near 0 is strict and repeatable, near 1 is creative. Most business work belongs at the low end. |
| **Top P**                                   | An alternative constraint on the range of candidates the model considers.                                                                  |
| **Maximum tokens**                          | The ceiling on a single run. The defaults are conservative, and a long instruction set with several tool calls can exceed them.            |
| **Reasoning effort**                        | How much work the model does before answering. Higher settings take longer, and suit work needing several steps of inference.              |
| **Frequency penalty**, **Presence penalty** | Tuning for repetition in what the model generates.                                                                                         |

## Attach tools

Attach the tools this agent may use. Built-in tools are offered alongside the ones you have defined, including web search.

Attach only what the role needs. A narrow set of tools is part of how an agent is kept to its role, and it is enforced where instructions are only persuasive.

## Triggers

Chat is on for every agent, and is what the playground uses.

All other triggers are defined separately rather than on the agent. What appears on the agent reflects the triggers defined against it. See Trigger an agent.

## Connect this agent to others

An agent can call others by handoff or by agent to agent. Handoff rules are defined under **Triggers**, as Agent Handoff Rules; agent to agent carries its own connection and authentication. See Connect agents for which of the two to use.

## Test the agent in the playground

Any agent can be exercised directly from its definition. This is a dry run: you converse with it, watch which tools it calls, and see how it arrived at an answer.

In production most agents are never conversed with. They are called from the back end, from a data service call, when a trigger fires. The playground exists to prove the instructions and tools before that happens.

## Review run history

Every run is recorded, whether it came from the playground or from a system call. A record shows what the agent did, which tools it called if any, and diagnostics for the run.

Where Azure AI Foundry could not be reached, the platform's agentic service completes the run in the platform core instead and marks the run as a fallback, so a run that never reached Foundry is distinguishable from one that did.

## Designing several agents

Agents can call other agents, so the pattern that works is a set of narrow agents rather than one broad one. Each is given one role, the tools that role needs, and instructions confined to it. A coordinating agent then calls whichever of them a piece of work requires.

Narrow agents are easier to instruct precisely, easier to test on their own, and easier to change without disturbing the rest.

## Where to go next

* Trigger an agent: make it run without the playground
* Connect agents: let this agent call another
* Monitor agent activity: see what this agent is doing once it is running