Step 0: Read the roster I have already written
Access to @Discord. Act as the coordinator for this server. Before you route anything, restate the roster below in your own words and tell me if any agent's scope overlaps another's. Overlapping scopes are the failure mode of this whole design, and they are much cheaper to find now than in week three.
Step 1: Read the roster back
[PASTE YOUR ROSTER - for each agent: name, channel, what it owns, what it must never do]
Step 2: Match incoming work to exactly one owner
For each message since the last run in the agent channels - on the first run, since [WINDOW] - decide which single agent owns it. Give the owner, a confidence from 0 to 100, and one sentence of why. If the confidence is under [ROUTING THRESHOLD], or two agents could reasonably own it, say so and stop - do not pick the more convenient one. An ambiguous route is where a handoff silently dies.
Step 3: Hand work over in a fixed shape
Every handoff carries the same five fields: from, to, the payload, a confidence, and the message id it came from. Post handoffs in the channel named in the roster. Never address a handoff to a person or an agent that is not in the roster, and never skip a field to save a line.
Step 4: Hold each agent to its own scope
An agent that receives work outside its scope returns it with the reason rather than attempting it. The researcher does not write. The writer does not edit its own draft. The moderator does not summarise. If an agent starts drifting, say which line of the roster it crossed.
Step 5: Watch for the queue that never drains
Report every handoff that is waiting more than [STALE HOURS], every message that received no route, and every route that bounced between agents twice. A workflow that routes everything on the first try is usually routing too few things correctly.
Step 6: Recommend the next split
Based on volume, time in queue, and bounce rate, tell me which agent is overloaded and which one is idle, and whether the next increment should be a new agent or a better handover.
Step 7: Propose it as an automation, so it runs again without me
You have just done this once, on this conversation. Now offer to repeat it. Call create_automation with:
name: three or four words for the task. frequency: daily, because routing wants a day's queue, not a trickle. content: this entire instruction, from Step 0 up to the step before this one, bracketed values already filled in. run_at: the first scheduled run, with today's date and my timezone. timezone: mine.
Two things. It is a proposal, not a creation - I get a card to confirm and nothing is scheduled until I press Confirm & Create, so put what this run found in your reply above the proposal, not inside it. And keep a first-run window in the scheduled content: a recurring run has no previous run to measure from, so say how far back to read the first time it fires.