Skip to main content

Check out Port for yourself ➜ 

Routing decision

The routing decision is the key output of the ticket prep workflow's Plan stage. It answers one question: is this work item ready for AI delegation?

Getting this wrong in either direction is costly. Route too aggressively and an agent touches a critical service during an active incident. Route too conservatively and the workflow adds overhead without delivering value. The routing decision uses two layers to balance this.

Layer 1: Deterministic scorecards​

Your platform team defines a set of objective rules that must all pass before a work item is eligible for AI delegation. These run as a Port scorecard evaluated against the work item and its catalog relations.

The default criteria:

CriterionRuleReason
Service tierNot T1Highest-criticality services require human oversight.
Blast radiusCalculated and not highUnassessed or wide-impact changes are too risky to delegate fully.
Active incidentsNone openDelegating during an incident compounds risk.
PriorityNot high or criticalHigh and critical items need direct engineer attention.

All four must pass. A single failure routes the ticket to a human.

In practice:

TicketOutcome
✅"Fix token expiry edge case in auth-service" - T2 service, blast radius Low, priority Medium, no active incidentAI READY
❌"Update auth service" - blast radius Unknown (dependency graph not populated), priority CriticalNEEDS HUMAN

A single failing criterion blocks delegation. In the second example, even if the blast radius were resolved, the Critical priority would still route to a human.

These rules are intentionally blunt. They are your first line of defense, not a nuanced judgment. The AI narrative handles the nuance.

Layer 2: AI narrative assessment​

After the scorecards run, Port AI generates a written explanation of the routing decision. This is not a second gate - it is context for the engineer.

The narrative covers:

  • Why the work item passed or failed the scorecard rules.
  • An assessment of complexity and ambiguity in the PRD and tech spec.
  • A recommendation: proceed with AI delegation, iterate on the spec first, or escalate to a human.

The narrative is grounded in the PRD and tech spec generated earlier in the workflow. An agent that produced a vague tech spec will produce a routing narrative that flags the vagueness.

What the engineer sees​

After the workflow completes, the engineer receives a Slack message with:

  • Work item name and origin ticket link.
  • Links to the PRD, tech spec, and service in Port.
  • The routing decision (AI-ready or not).
  • The AI narrative summary.
  • Three action buttons: Delegate to Claude Code, Iterate on PRD, Continue in IDE.

The engineer does not need to open five tabs. One thread, one decision.

How the decision persists​

The routing decision is not stored only in Slack. It writes back to the work item entity in Port as structured data:

  • Routing scorecard result (pass/fail per criterion).
  • AI narrative text.
  • Timestamp.
  • Engineer response (which CTA they clicked).

This makes routing decisions measurable over time. The ROI dashboard reads from these entity properties to show agent vs human split, stage breakdowns, and trends. See ROI dashboard for details.

Customizing the rules​

The default scorecard criteria cover the most common risk factors. You can adapt them:

  • Add criteria - Require that the service has a runbook, that test coverage is above a threshold, or that the work item has no open blockers.
  • Adjust thresholds - Change what counts as "high" blast radius for your organization.
  • Layer by team - Apply stricter rules to teams that are newer to AI delegation and relax them as confidence grows.

See the work item blueprint implementation guide for the full scorecard configuration reference.

Common failure modes​

Blast radius comes back Unknown This is the most frequent reason tickets route to humans unexpectedly. It means the service's dependency graph in your catalog is not populated. Fix: ensure the service entity has its dependencies mapped before running ATR at scale. The Calculate blast radius with AI guide covers this.

Service tier not set If service_tier is missing on the related service entity, the scorecard cannot evaluate the T1 rule and will fail it. Fix: confirm all services in scope have a tier property set in your catalog.

Everything routes to critical If your team tags most work as Critical or High, the priority rule will block most delegation. Recalibrate what Critical means, or adjust the rule to exclude only Critical if High-priority items are routinely safe to delegate.

Next steps​