There's a popular line right now that goes something like "agents make project-management tools obsolete." It usually comes from people who've watched a demo and not yet shipped a feature. We've shipped enough features through an agentic pipeline now to disagree, and the disagreement is specific: agents make a particular subset of project-management labour cheaper, but they make the artifacts project-management tools produce more valuable, not less. Below is a quick tour of what our pipeline looks like and which Atlassian product earns its place at each step.
The pipeline, in one diagram
The flow is roughly:
Idea (JPD) → Refinement (JPD Q&A) → Feature page (Confluence skeleton)
→ Design Spec + RFC (Confluence, co-authored)
→ Epic + Stories (Jira)
→ Implementation (GitHub PRs, agent-driven)
→ Trunk PR review (human)
→ Close (Jira → Done, Confluence → Closed Features)
Every arrow has a corresponding step in our agent harness — refinement, spec authoring, ticket creation, implementation, closeout — that we trigger when we're ready to move from one stage to the next. Most of the arrows are agent labour; most of the boxes are documents that humans still want to read.
The principle: agents are good at labour, not at remembering
The thing the agent isn't going to do is remember, six months from now, why the booking-slot service was extracted into its own file. That's because there's no agent memory in production — the next session that touches that code starts cold. What that next session will read is whatever survived in writing. So the question becomes: what writing actually survives a year, three engineers, two product pivots, and a tooling change?
That's the job description for a product-management toolset. It's not "track tasks." It's "produce durable artifacts that an LLM in 2027 can read and understand without their author present."
This is a higher bar than human engineers usually hold project-management tools to. And it's the bar Atlassian has been quietly meeting for fifteen years.
What each tool earns its place doing
Jira Product Discovery (JPD) — idea capture and refinement
We use a JPD project for the idea-stage work. Every potential feature starts as a single JPD card with a problem statement, a few notes about the people it would help, and a confidence score. There's no spec yet. There's not always a clear next step.
The agent runs a refinement pass against the JPD card and walks through a Q&A — ten or fifteen questions about audience, scope, success criteria, edge cases, what's in and what's out. It writes the answers back into the JPD card itself, into structured fields (Problem Statement, Requirements, User Stories, Out of Scope). At the end the card has enough definition that someone reading it cold could decide whether the work is worth doing.
JPD's value here is the shape it imposes on the conversation. It's not a free-form Confluence page. The fields are typed, the user stories live in their own list, the requirements are checkable boxes. The agent can be specific about where it's writing because the schema is already there. We tried this in a Confluence page once. It works, but the result is harder for the next reader to navigate because everything is one big text blob.
Confluence — design specs, RFCs, and the drift trail
Once a JPD card is refined, the next step in the harness produces two co-authored Confluence pages: a Design Spec and an RFC. The Design Spec covers visual decisions, copy, accessibility, layouts, and inherits from any Storybook mockups in our brand package. The RFC covers detailed design, data-model impact, security considerations, testing strategy, and a Proposed Ticket Breakdown.
Both pages are written by the agent, but they're written in a structured Confluence shape: the metadata table at the top (status, author, date, source links), a fixed set of sections in a fixed order, an Open Questions section at the end. The next time anyone — agent or human — opens these pages, the structure is the same. They know where to look.
There are also four other Confluence pages spawned per feature: a Summary (populated post-implementation), a Test Plan (populated post-implementation), a Review (populated when human review begins), and a Drift report (populated post-implementation if implementation deviated from the RFC). The Drift report is the one that matters most for an agentic workflow — it's the running confessional of every place the agent went off-spec, and why. After three months of work, this has become the most-referenced document type for new design decisions: "how often did we deviate, in which directions, for what reasons." It's a feedback loop on the RFC quality itself.
The point is: Confluence's value isn't that it's a wiki. Notion is also a wiki. The value is that the parent-child page hierarchy and the consistent metadata table give every artifact an identifiable shape, so the agent can read three RFCs from three different epics and reason about them with the same parser. Schema, not freeform.
Jira — epics, stories, and the auditable transition history
Once the Design Spec and RFC are stable, the next step reads the Proposed Ticket Breakdown out of the RFC and creates a Jira Epic with a Story under it for each item. The Stories include the description, acceptance criteria, dependencies, and risk classification — all derived from the RFC.
When the implementation step runs, it walks the stories in dependency order, transitions each to In Progress, opens a per-story PR, and on merge transitions the story to Done. The Epic moves to In Progress on first start and to Done when the trunk PR merges to main. Every transition is timestamped, attributable, and audit-logged in Jira.
This is the part where some teams ask: why not just do all of this in GitHub Projects? Two reasons.
First, GitHub Projects' relationship to issues is loose in a way that makes it hard to audit programmatically. Jira's Epic-Story-Subtask hierarchy is rigid; the agent can ask Jira "give me every story under this epic in dependency order" and get a deterministic answer with the dependencies parsed out of structured fields. We've tried doing the same against GitHub Projects and the answer requires reading prose.
Second — and this is the part that's specific to operating an enterprise SaaS — Jira is what our customers' compliance team and legal team trust. We handle PII and payments. The audit trail of "who decided to do this work, when did the change land in production, what review gates did it pass" needs to be in a tool that has a Statement of Applicability for SOC2 and ISO27001. Atlassian Cloud has both. GitHub does too, but the Jira audit trail is the one our customers' compliance officers ask about by name.
GitHub — code, PRs, CI, and the granular review surface
Code lives in GitHub. PRs target either a trunk branch (per-story) or main (epic-trunk). CI runs on every PR via Blacksmith runners. CodeRabbit runs an automated review pass on every PR. The agent polls both and reacts to the results — a CodeRabbit Major finding becomes a fix commit on the same PR, a CI failure becomes a re-run with the relevant fix, and a clean review + green CI becomes a squash merge to trunk.
The thing GitHub does that nothing else in this stack does is the granular review surface. CodeRabbit's inline comment threads, GitHub's diff view, the ability to reply to a specific suggested change with "agree, applied as commit X" or "disagree because Y" — that conversation is where the agent and the human reviewer actually meet. The agent can't post a review comment on a Confluence page; the conversation needs to live next to the line of code.
We have not been tempted to move this layer to anything else. GitHub's free-tier review tooling, with CodeRabbit on top, is the best-priced piece of our stack.
Why the integrations matter as much as the tools
The harness works because the integrations between Atlassian products and GitHub are good. Jira issues link to GitHub PRs and back. Confluence pages embed Jira issue lists that auto-update. JPD cards link to the Confluence pages they spawned. The agent can follow these links programmatically — it can fetch the RFC referenced in a Jira epic's description, find the Stories under the Epic, walk the GitHub PRs linked from each Story.
If you replaced JPD with a separate ideation tool, Confluence with Notion, and Jira with Linear, you'd have to rebuild the integration layer yourself. Some teams do, and that's fine — the cost is in the seam where the tools meet, not in any one tool. We chose Atlassian because the integrations were already there and the agent could lean on them.
What we'd say to other teams considering this shape
A few things from the last few months that we wish we'd known earlier:
- Pick the tool that has the best schema, not the prettiest UI. Notion and Linear are nicer to look at than Confluence and Jira. They're harder for an agent to write reliably against. The agent doesn't care about animation; it cares about whether the "Acceptance Criteria" field is a structured list it can iterate over.
- The Drift report is the most important artifact, and almost no team writes one. It's the document that tells the next agent why the implementation doesn't match the RFC. Skip it and you ship a codebase that nobody can reason about cold — agent or human.
- Audit trails are not optional once you handle real money or real PII. Atlassian's audit log is one of the reasons our enterprise customers' compliance teams stayed comfortable as we increased the share of work an agent does. "All implementation decisions are tracked in Jira; all design decisions are tracked in Confluence; all code changes are tracked in GitHub" is a sentence we can defend in writing.
- Pay for the seats. Don't be cute. This stack costs us roughly the price of one cup of coffee per engineer per day. The cost of the alternative — paying engineers to maintain a homegrown integration layer between three trendy tools — is much higher than that. A boring tool stack with good integrations is a competitive advantage when the rest of your engineering org is moving fast.
The thing that's changed in the last year is not which tools you use — it's how much labour each tool absorbs. JPD now absorbs more refinement work than it used to. Confluence absorbs a much higher density of design and review writing. Jira's transition history is a richer audit trail because the agent transitions tickets as it works. GitHub is where the agent's output meets human review.
The tools didn't get worse because we automated the labour around them. They got more useful, because the artifacts they hold are now an active substrate that an agent reads and writes against. That's the part the "agents replace project management" line gets wrong. Agents make project management infrastructure more valuable, not less. Pick yours accordingly.