new_issue: agent → programmatic pipeline

The outbound work-order summary doesn't need an agent. It's a deterministic trigger that calls the model exactly once. This memo banks the decision — and the decision is: not yet.

May 31, 2026 · grounded in issue-poller.mjs, router.mjs, orchestrator.mjs, skills/process_work_order/SKILL.md

PARKED — low priorityrevisit on a concrete trigger (below), not a date

The insight Before → after Why it's a win Why it's parked

The new_issue phase (poller fires → summarize WO → suggest a vendor → text the PM) has no agent decision-making. Control flow is fixed; the model is only needed for one thing — turning a raw PMS title into a natural sentence. So it should be a programmatic pipeline with a single constrained model call, not an orchestrator turn with a 200-line skill. But it works today, and a refactor isn't the bottleneck — so park it.

The insight

The work order skill bundles two phases that are opposite in nature:

Phase	Nature	Needs the model?
`new_issue` poller fires, WO summary out	Workflow / state machine. Fixed sequence, templated output.	Once — to write one natural sentence. No agent loop.
`incoming_user_message` PM replies in the chat	Agent. Intent-reading over free-form human text.	Yes, fully — this is the real agent. Leave it alone.

The tell that new_issue was never agentic

Its "Hard rules" — "after send_text, STOP," "ONE send_text call," "always read_memory first," no greetings, no urgency prefix — are all the prompt fighting the model to behave like a state machine. When you need eight rules to force determinism, the flow should be code. Each rule becomes a line that structurally can't be violated.

Before → after

The intelligence moves out of "which step next" and into the memory ranking + one sentence.

Why it's a win (when we do it)

Reliability. The eight hard-rules become code — no skipped read_memory, no double send_text, no greeting/format drift. That's the cross-customer reliability the loop is judged on.
Cheaper + faster. One constrained completion (fine on mini) replaces a full gpt-5.4 multi-iteration turn.
Forces memory quality into the open. Today the model "picks the best vendor," which papers over the ranking. Drop to candidates[0] and a wrong top pick becomes a ranking bug you can see — the exact memory proof we want, not hidden by the LLM's judgment.

No conflict with the "one skill per domain, don't split by trigger" rule: we're not splitting the skill, we're removing a phase that was never agentic. process_work_order becomes purely the reply runbook — cleaner, not fragmented.

Why it's parked

It works today. A refactor of something that works swaps "works" for "works + cheaper + safer" — real, but marginal, and not the bottleneck. The scoreboard is paying PMs running the loop, not architectural cleanliness. The memory-quality check doesn't even require the refactor: grep the turn logs for cases where the model's vendor pick ≠ candidates[0] — an afternoon of analysis, not a rebuild.

Do it when one of these trips

the outbound summary misbehaves in prod (format break, double-send, skipped read_memory);
we're already editing new_issue for another reason;
we onboard customer #3 and want the outbound path bulletproof across PMSes.

Until one trips: it's polish. Build dispatch/follow-up instead.