Outcome
The agent has a written method it follows every run, knows which instructions win when they disagree, and starts from the places your team already works in. It is ready for its first seeded case in step 5.Decide
What is the method? Write it down as a runbook before the agent runs once. If a human would follow five steps and consult one lookup table, the agent gets those five steps and that table as a skill. The alternative, a long system prompt, is harder to test and impossible to attach to a second agent.
Where does the agent live? Pick the trigger from where the work already arrives: Slack for questions, Email for forwarded cases, Linear or GitHub for tickets and pull requests, a cron schedule for queue sweeps and periodic reviews. Runtime has no inbound trigger from Zendesk, Intercom or Datadog today, so a support agent is reached through Slack, Email, or a scheduled sweep of the queue. For step 5, point the trigger at a test channel or use a manual run, not the live queue.
What must it never do? List the actions (refunds, status changes, customer-facing sends, account blocks). Put them in the system instructions and the runbook now as flat prohibitions. Do not write rules for them yet; that is step 6, after the agent has shown in step 5 that it can do the job with read-only credentials. A rule written now is a guess about behaviour you have not observed.
The three pages
Skills and runbooks
Write the procedure as a
SKILL.md bundle, require the tools it needs, attach it to the template, rebuild.Instructions
The nine layers written into every session, which one wins, and what belongs in each.
Triggers
Slack, Linear, GitHub, Email, WhatsApp, SMS, cron and the API: what each sends the agent and how it replies.
Order of work
1
Write the skill first
The runbook is the thing you will edit most. Get it into a skill and attached to the template before any trigger exists. Include the prohibitions and the approval step as runbook text.
2
Check the instruction layers
Read the agent’s system instructions next to the org and template instructions. The later layers win, so an org policy like “never paste card numbers” already applies and does not need repeating.
3
Rebuild the template once
Attachments made after the last build are not in the snapshot until you rebuild.
4
Connect a test trigger
Once the template proves it carries the skill, connect Slack, Email or a schedule, pointed at a test channel or created disabled so you can
run-now. A trigger connected before the template is ready runs a bare agent.5
Go prove it
Continue to Prove it works and iterate. Come back to guardrails only after the seeded cases pass.
Gotchas
- A skill attached after the last build is not in the sandbox.
template getshowsattachments_changed_since_build: true; rebuild. - Instructions do not enforce. The system prompt says “never refund”; only a deny rule makes it impossible. That rule belongs in step 6, once you know what the agent actually runs.
- Guardrails before the first run. An
askdefault on an unproven agent stalls on every unknown command, and you cannot tell a capability gap from a rule. Prove first. - A trigger on the live queue during step 5. Use a test channel, an allowlisted sender on the email inbox, or a disabled schedule with
run-now.