Prompting a Gateway

A gateway 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 and Operational Rules.

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.

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.

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 or 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`)

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.

"This gateway only handles incidents about Linux web servers and their
databases. Skip tickets about network appliances, end-user workstations,
or Windows infrastructure."

Prompting

Best Practices

Risk & Safety

FAQ

Prompting a Gateway

What belongs in a gateway prompt

Task sequencing across multiple hosts

Routing conventions for special host classes

Host name mappings (only when needed)

What does NOT belong in a gateway prompt

Scope gating

​What belongs in a gateway prompt

​Task sequencing across multiple hosts

​Routing conventions for special host classes

​Host name mappings (only when needed)

​What does NOT belong in a gateway prompt

​Scope gating

What belongs in a gateway prompt

Task sequencing across multiple hosts

Routing conventions for special host classes

Host name mappings (only when needed)

What does NOT belong in a gateway prompt

Scope gating