Intake triggers
An intake trigger is the rule that decides whether an issue or comment starts a run. AgentSDE watches many events on your connected tools, but almost all of them pass by untouched · a run only begins when an event matches a trigger. Two triggers are always on and can never be turned off, and you can add up to twenty more of your own on top of them.
#What an intake trigger is
Connecting a tool subscribes AgentSDE to a stream of events · issues opened, labels changed, comments posted. Hearing an event is not the same as acting on it. An intake trigger is the test each event is measured against: if the event matches, a run starts on that issue; if nothing matches, the event is ignored and no work happens.
Triggers come in two shapes, because there are two natural ways to say “start now”:
- A label trigger fires when a named label is present on the issue (a Jira status on the Jira side). Labels are the ambient signal · you move an issue into a state and anything already sitting there qualifies.
- A command trigger fires when someone posts a comment whose text is a slash command, like
/agent start. Commands are the deliberate signal · a person points at one specific issue and says go.
#The two built-ins you can never turn off
Every tenant, on every platform, has two triggers that are always on. They are evaluated before any rule you configure, and there is no setting that disables them:
They are the floor everything else stands on. The in-refinement label is how the pipeline itself hands work forward · phases move an issue into refinement to continue it, so a tenant who could delete that trigger could accidentally stall their own runs. And /agent start is the guaranteed manual escape hatch · no matter how a tenant has configured their custom rules, there is always one command that starts a run. Because they are checked first, your own rules can only ever add ways to start · never take these away.
#Custom rules add to the built-ins
On top of the two built-ins you can define your own rules. They are additive · a custom rule gives you an extra way to start a run, it never replaces or narrows the built-ins. Each rule is three fields:
Two constraints are worth knowing before you write one:
- A
commandrule’svaluemust start with/. A rule that tried to trigger on a bare word is rejected, because commands are recognised by their leading slash. - You can have at most twenty custom rules per tenant. That is plenty for real workflows and keeps evaluation cheap · past twenty, the config is rejected.
A command trigger only fires when the command stands on its own · it must begin a line and be followed by a space or the end of the comment. So /agent start in a comment fires, but a command that merely appears inside a longer string · for example a link like github.com/agent-core-artefacts · never does. You cannot trip a trigger by pasting a URL.
#General rules and per-integration rules
A rule with no integrationId is a general rule · it applies to events from every connection you have. A rule with an integrationId is scoped to that one connection. Scoping lets a repository, or one Jira site, have its own start rule without imposing it on everything else.
When these overlap, the precedence is deliberate and easy to state. For any incoming event, AgentSDE decides in this order:
Check the built-ins first
Does the issue carry the in-refinement label, or is the comment /agent start? If yes, the run starts and nothing else is consulted. These always win.
If the event's connection has scoped rules, only those apply
When the connection the event arrived on has one or more rules of its own, AgentSDE evaluates only those scoped rules. The general rules are set aside for this event · a connection with its own rules is governed by its own rules.
Otherwise, fall back to the general rules
If the event’s connection has no scoped rules of its own, AgentSDE evaluates the general rules (the ones with no integrationId). A matching rule starts the run.
The subtle part is step two · scoped rules override rather than add to the general rules for the connection they cover. An example makes it concrete:
Suppose you have one general rule · start on the
readylabel · and, for one repository, a single scoped rule · start on theship-itlabel. In that one repository,readyno longer starts a run, because the connection has its own rules and only those are consulted. Everywhere else,readystill works. (And in both places the two built-ins still fire ·in-refinementand/agent startare never set aside.)
The moment a connection has even one scoped rule, your general rules stop applying to it. If you want a connection to keep the general behaviour and add something, re-state the general rules as scoped rules on that connection too · otherwise you will silently lose them for that connection.
#The decision, end to end
#One thing you never have to configure
You do not need a rule that says “ignore the agent’s own comments”. Runs post comments and move labels as they work, and those actions generate events too · but the runtime knows which events its own agents caused and drops them before triggers are ever evaluated. There is no feedback loop to guard against and no “not the bot” exception to write · a trigger only ever sees activity from real people and your tools, never the agent talking to itself.