Skip to main content
A gateway is governed by two independent prompts, each an optional override you toggle on:
  • The inbound prompt is a routing and orchestration instruction. It bridges the vocabulary of your ticketing system to your internal infrastructure, decides which tickets are in scope, and defines how a ticket turns into a sequence of tasks.
  • The outbound prompt governs what 2501 writes back to the ticket once a job finishes — the status it sets, whether it posts a comment, and whether it escalates.
Each side is independent: you can enable one, both, or neither. When a side’s override is off, the gateway falls back to its built-in default handling for that side.

​
The inbound prompt

The inbound 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 2501 writes back at the end of a job is the outbound prompt, not the inbound prompt.)

​
What belongs in an inbound 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 an inbound prompt

OutBelongs 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 remediateSpecialty + ticket tag (@2501:investigate)
What status/comment to write when the job finishesThe outbound prompt
Bad in an inbound 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

The inbound 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 skipped and marked with a distinct “Skipped” status. 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."
A skip never posts a comment and never changes the ticket’s status. Its only possible side effect on the ticket is reassignment: your prompt may instruct that an out-of-scope ticket be escalated to another assignment group instead of dropped silently. 
"Skip tickets about Windows infrastructure, and reassign them to the
'Windows Operations' group rather than leaving them unrouted."

​
The outbound prompt

The outbound prompt acts at the end of a job, when work has finished. It governs what 2501 writes back to the ticket. With the outbound override off, the gateway’s built-in default mapping applies (for example, a successful incident is resolved). Enable the override to let the agent decide the write-back from your instructions. Because the gateway is the only writer to the ticket, the status, comment, and any reassignment land together as one coherent update.

​
What belongs in an outbound prompt

​
Status and close-code rules

Tell the gateway which external state to set for each kind of outcome. The agent maps the internal result to your ticketing system’s real states and close codes, and the gateway validates the choice against the legal states for that ticket type. 
Good:
"When an incident is fully resolved, set it to Resolved with close code
'Solved (Permanently)'. If the work only partially succeeded, leave the
incident open so a human can finish it."

​
Comment style and visibility

Control whether 2501 posts a public comment (visible to the requester) or an internal work note, and the tone or detail of what it writes. 
Good:
"On success, post a brief public comment summarizing what was fixed, in
plain non-technical language. On failure, post an internal work note with
the technical details for the on-call engineer."

​
Escalation and reassignment rules

Decide when a finished job should be handed off — reassigned to another assignment group — rather than left with its current owner. 
Good:
"If a database incident could not be resolved automatically, reassign it
to the 'DBA On-Call' group and leave it open."
If your gateway handles more than one ticket type, write these rules per ticket type where they differ (for example, incidents resolve to a closed state, while change requests move to Review).

​
Version History

Both the inbound and outbound prompts maintain a full version history. Each save creates a new version — you can view previous versions and restore any of them directly from the gateway settings in Command Center.