The Mediator

The problem

Ticket rules were too complex and chaotic for humans to apply consistently and fast enough.

• Scrum masters, project managers, and BSAs were the bottleneck: they couldn't create tickets correctly fast enough to keep up with the work.
• When individual contributors created tickets themselves, they were often wrong or missing dependencies, because nobody had fully trained them on the rules.
• The result: delayed sprints, work piling up, rework on malformed tickets, and sprint planning sessions that turned into ticket-fixing sessions.

The solution

An AI agent in Slack that acts as ticket manager, applying the same rules every time so the humans can get back to the work the rules were slowing down.

• Takes natural language requests ("I need a follow-up on this," "create a project from this work") and turns them into properly formatted tickets with dependencies attached.
• Suggests follow-up tickets when work closes, and flags sprint risk mid-sprint based on real metrics, not gut feel.
• Works as a one-stop shop in Slack: create tickets, add comments, nudge teammates, and check sprint health without leaving the conversation.

• Slack agent
• Rule-based ticket logic
• Dependency mapping
• Mid-sprint risk signals
• Modular rules file

What it does in Slack

• Understands plain requests instead of requiring a form or a specific syntax.
• Generates tickets with consistent formatting and dependencies already attached, the same way every time, regardless of who asked.
• Suggests a follow-up ticket the moment a ticket closes, instead of leaving that judgment call to whoever happens to notice.
• Surfaces mid-sprint risk alerts, tickets trending toward trouble based on the same metrics a scrum master would watch, before they become a surprise in standup.

Modular, not hardcoded

• The agent reads its rules from an external context file. The logic isn't buried in code nobody but us could touch.
• Ticket types, formats, and rules can be updated, added, or removed by the team directly, without redeploying or rewriting the agent itself.
• Sprint metrics are visible to the whole team, not just the scrum master, so everyone understands where the sprint actually stands.

They changed it almost immediately

• Added a new ticket type the agent didn't originally have.
• Removed a ticket type that wasn't working for them, without asking us to do it.
• Reformatted the user story ticket from the standard "I am a user, I want..." structure to their own "This is an idea, here is the request" format, and did it almost immediately after handoff.

Still hands-on, on purpose

• The agent still requires human oversight and management. We built it that way on purpose: the rules belong to the team, not to us.
• The team controls the rules, the metrics are transparent to everyone, and the whole sprint is working from the same picture of what's actually happening.
• A good build shows up in what the client does with it after we're gone. Here, they customized it to their real workflow within days, without calling us first.