How work starts

What actually happens between an event on your tracker and a run beginning. This is the mechanical model behind intake · one level below the how-to, so you can reason about why a given issue did, or did not, start work.

#An event arrives, and is measured against your rules

Connecting a tracker or repository subscribes AgentSDE to a stream of activity · issues opened, labels changed, statuses moved, comments posted, and peer signals raised by your own workflow. Most of that stream passes by untouched. Hearing an event is not the same as acting on it.

For each event that arrives, AgentSDE asks one question: does this match a trigger this workspace has in effect? A trigger is the test an event is measured against · a named label appearing on an issue, or a comment whose text is a slash command. If the event matches, work can start on that issue. If nothing matches, the event is ignored and no run is created.

#Two built-ins cover the common case

Every workspace, on every platform, starts with two triggers that are always on and cannot be turned off:

• the issue entering the in-refinement label or status · the ambient signal, where moving an issue into that state qualifies it, and
• the literal /agent start comment · the deliberate signal, where a person points at one issue and says go.

These are the floor everything else stands on. in-refinement is how the pipeline hands work forward · phases move an issue into refinement to continue it, so a workspace that could delete that trigger could stall its own runs. And /agent start is the guaranteed manual escape hatch · no matter how you configure the rest, there is always one command that starts a run. Your own rules layer on top of these; they can only ever add ways to start, never take these two away.

#Matching resolves which agent and which repository

A match is not just a yes · it also answers where the work goes. AgentSDE evaluates in a deliberate order, and the first thing to match decides the outcome:

The built-ins are checked first and always win. After them come your own rules · and here scoping matters. A rule can apply to every connection you have, or be scoped to one. When the connection an event arrived on has its own scoped rules, only those are consulted for that event; a connection with its own rules is governed by its own rules. This is a per-integration override, not an addition · scoping a connection sets its general behaviour aside. The precedence and a worked example live in the how-to.

Once a trigger matches, AgentSDE resolves the agent and repository the work belongs to and dispatches a run · a single pass of that one issue through that agent’s pinned design. What happens from there is covered in how a run executes.

#What intake guarantees

A handful of behaviours are worth stating plainly, because reasoning about intake is mostly reasoning about these:

• Nothing starts without a match. An issue with no matching label and no start command sits still · forever, if you never touch it. There is no default that picks up work you did not ask it to.
• Every run records who and what started it. A run carries the event that triggered it · the label that landed, the comment that was posted, the person who posted it. You can always trace a run back to the thing that began it.
• Out of scope means no run. An event on a repository this workspace is not configured for, or a label that no rule names, simply produces nothing. Negative cases are silent by design · the absence of a run is the correct outcome, not an error.
• There is a ceiling on rules. You can add up to twenty trigger rules of your own per workspace, on top of the two built-ins. That is ample for real workflows and keeps evaluation cheap and predictable.

#Where this fits