> ## Documentation Index
> Fetch the complete documentation index at: https://docs.2501.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Agentic Flow

> Ticket → gateway → job → tasks → resolution, in one page

A ticket arrives in your ITSM and 2501 takes it through this lifecycle, end to end.

## The flow

**1. Ticket mirrored from the ITSM**

The gateway mirrors the incoming ticket (plus its comments) into 2501 as a [Ticket](https://docs.2501.ai/0.19/core-concepts/tickets.md) record. Nothing else changes in the ITSM yet.

**2. Gateway parses and judges feasibility**

The gateway uses the tenant's text LLM to read the ticket, parse attachments with the multimodal model, and decide whether the request is in scope. It looks at registered hosts, available agents, and applicable rules to figure out which agent should handle it.

**3. Job is created**

Once the gateway has a plan, it creates a [Job](https://docs.2501.ai/0.19/core-concepts/jobs.md) that wraps one or more tasks. A job is the unit of work tied back to the ticket.

**4. Tasks dispatched to agents**

Each [Task](https://docs.2501.ai/0.19/core-concepts/tasks.md) targets a single agent on a single host. The agent receives the task description plus dynamically injected operational rules, knowledge facts, and credentials. **One task = one agent. One job = N tasks, possibly across N agents.**

**5. Agent runs, observes, adapts, reports back**

The agent executes autonomously until it has a result. The orchestrator reads that result and decides whether the ticket is resolved or whether another task is needed.

**6. Job terminates**

On success: the gateway closes the ticket with a summary. On failure or partial: the gateway posts a work note. While the job runs, the gateway posts one comment after each turn - the tasks that the job starts together - with what they did, why any failed, and the results they saved.

## The 20-task ceiling

A job runs at most **20 tasks**. It runs them in turns: the tasks of a turn run at the same time, one per host, and the next turn starts when they have all ended. A patch on 20 hosts fits in one turn.

The results of every task go into the planning of the next turn and into the final answer, and 20 tasks keep that history within the model's context. If a job reaches 20 tasks while the ticket still needs work on more hosts, the job ends as partial.

## Where rules and knowledge come in

The gateway and the agent both inject context at runtime:

* **Operational Rules** are judged by their text against the task, then surface up front.
* **Knowledge facts** about the host get attached automatically.
* **Credentials** scoped to the agent's host are made available for tool calls.
* Mid-task, the agent can pull additional rules or facts on demand if the situation evolves.

For the deeper mechanics, see [Dynamic Context Injection](https://docs.2501.ai/0.19/best-practices/dynamic-context.md).

## Where each piece is configured

| Piece | Where |
| - | - |
| Who can be picked | [Agents](https://docs.2501.ai/0.19/core-concepts/agents.md) + [Hosts](https://docs.2501.ai/0.19/core-concepts/hosts.md) inventory |
| How an agent thinks | [Specialty](https://docs.2501.ai/0.19/configure/specialties.md) attached to the agent |
| What must always be true | [Operational Rules](https://docs.2501.ai/0.19/configure/operational-rules.md) |
| What must never be run | [Blacklist](https://docs.2501.ai/0.19/configure/blacklist.md) |
| What the agent knows about your env | [Knowledge](https://docs.2501.ai/0.19/configure/knowledge.md) |
| How tickets become tasks | [Gateway inbound prompt](https://docs.2501.ai/0.19/core-concepts/gateways.md#inbound-prompt) |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.