> ## 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.

# Prompting a Gateway

> Route and sequence — how tickets become the right tasks on the right hosts

A [gateway](/0.7/core-concepts/gateways) prompt is a **routing and orchestration** instruction. It bridges the vocabulary of your ticketing system to your internal infrastructure, and defines how a ticket turns into a sequence of tasks.

The gateway prompt has **no influence on how the agent behaves once assigned**. Its job ends when a task is created. Behavioral shaping lives in [Specialties](/0.7/prompting/specialty) and [Operational Rules](/0.7/prompting/operational-rule).

## What belongs in a gateway prompt

### Task sequencing across multiple hosts

This is where the gateway earns its value: defining the flow when resolving a ticket needs more than one task.

```text theme={null}
Good:
"For tickets about a crashed worker, first create a task on the MGMT host
to restart the worker process. Once that task completes successfully,
create a follow-up task on the worker host itself to verify all services
have restarted and are healthy. The ticket is resolved only when both
tasks succeed."

Good:
"Hosts nyc1-app-jvm-01 and nyc1-app-jvm-02 are a master-slave pair and
must remain in sync. For any ticket affecting one of them, duplicate the
task to both hosts and do not mark the ticket complete until both tasks
report success."
```

A well-written orchestration sequence is the difference between a ticket that is *superficially* resolved and one that is actually fixed across the full topology.

### Routing conventions for special host classes

Some concerns are always handled by a dedicated host or group, regardless of how the ticket is worded.

```text theme={null}
Good:
"All firewall-related tickets — port openings, rule changes, traffic
blocks — must be handled through a host matching SRV-FW-*. Do not
attempt firewall rule changes directly on application hosts."

Good:
"Database issue tickets should be routed to the DB control node
db-mgmt-01, not to individual replica nodes."
```

### Host name mappings (only when needed)

The gateway is usually smart enough to map external names to your inventory by itself. Add explicit mappings only for **non-obvious** cases — when external names don't share any naming convention with your internal hostnames.

## What does NOT belong in a gateway prompt

| Out                                                          | Belongs in                                                                                   |
| ------------------------------------------------------------ | -------------------------------------------------------------------------------------------- |
| How to fix a crashed worker (commands to run, logs to check) | [Specialty](/0.7/prompting/specialty) or [Operational Rule](/0.7/prompting/operational-rule) |
| "Never modify these hosts directly" or "require approval"    | Operational Rule — the gateway routes, it doesn't enforce behavior                           |
| Boundary rules like read-only vs remediate                   | Specialty + ticket tag (`@2501:investigate`)                                                 |

```text theme={null}
Bad in a gateway prompt:
"To fix a crashed worker, SSH in and run `systemctl restart worker`,
then check `journalctl -u worker` for errors."

That's a procedure — it belongs in an Operational Rule.
```

## Scope gating

A gateway prompt also acts as a **scope gate**. Defining which kinds of requests the gateway should or should not handle means tickets outside that scope are dropped silently — no comment, no status change, no ownership change. See [Routing and Scope](/0.7/core-concepts/gateways#routing-and-scope).

```text theme={null}
"This gateway only handles incidents about Linux web servers and their
databases. Skip tickets about network appliances, end-user workstations,
or Windows infrastructure."
```