Why issue tracking is breaking

Issue tracking still matters

For years, the issue tracker was where software work became real. A bug report, feature request, technical improvement, or customer problem eventually became a ticket with a title, owner, status, priority, due date, and enough structure to move through planning and delivery.

That model still matters. GitHub describes issues as a way to track ideas, feedback, tasks, and bugs, and that foundation is not going away.

The problem is that modern work now moves through calls, customer conversations, support threads, analytics, code reviews, Slack messages, documents, incidents, product decisions, AI summaries, and agent-assisted workflows. By the time something becomes an issue, much of the context that explains why it matters has already scattered across tools.

This is the problem Forge is being built to solve. As the companion article on why we created Forge explains, the tracker should evolve from a static task database into a context-rich workspace where teams can understand what matters, why it matters, what changed, and what can safely be automated.

The backlog was built for tasks, not context

The classic backlog is good at holding work items. It can show titles, labels, statuses, owners, dates, estimates, and comments. That makes it useful for coordination.

But a backlog is weaker at preserving meaning. Most teams have seen the pattern: an issue is created with reasonable intent, then a few weeks later the title still exists and the status still exists, but the surrounding meaning has faded.

The customer conversation that triggered the issue is somewhere else. The tradeoff discussed in a meeting is not attached. The reason this issue outranks another issue is unclear. The original assumptions may have changed, but the ticket does not show that clearly.

Atlassian's Jira documentation shows how issues and subtasks help teams break work into trackable units. Forge's view is that trackable units are necessary, but modern teams also need those units connected to signals, initiatives, decisions, conversations, and agent workflows.

This is the first way issue tracking is breaking: it records the item, but not enough of the story.

A task without context becomes a guess

A task is useful when the team understands its purpose. Without context, the same issue can mean different things to different people.

One person sees a quick bug fix. Another sees a customer retention risk. Another sees a dependency for a larger initiative. Another sees scope creep. Each interpretation may be reasonable, but the tracker often does not help the team resolve the difference.

An issue should be able to answer what triggered the work, which customer or signal it relates to, what decision has already been made, what is still undecided, which initiative it supports, what changed since it was created, and what an AI agent should be allowed to do with the information.

When those answers are missing, people have to reconstruct them manually every time the work resurfaces. The backlog may look organized from far away while feeling confusing up close.

AI makes weak issue tracking more visible

AI did not create the issue tracking problem. It exposed it.

Before AI, teams could survive messy work systems by relying on human memory and social glue. Someone remembered why a ticket mattered. Someone knew which Slack thread had the missing context. Someone had the customer call in their head.

AI changes the cost of that mess. If the tracker contains incomplete issues, stale statuses, weak descriptions, missing links, and unclear ownership, AI can summarize the mess faster, classify the mess faster, and even automate parts of the mess faster. Speed does not equal clarity.

Google's 2025 DORA report on AI-assisted software development makes the surrounding system conditions part of the AI story. That lesson matters for issue tracking: AI performs better when the work environment is clear enough to guide it.

Forge is being designed around a clearer work graph. Issues, signals, calls, projects, initiatives, teams, and insights should connect so agents can assist from structured context rather than isolated text.

The tracker is becoming a coordination tax

Issue trackers were meant to reduce coordination overhead. For many teams, they now create a coordination tax.

The tax appears in small moments: updating a status because the system cannot infer progress, rewriting context because the original issue was too thin, searching across tools to find the source of a request, asking who owns an issue because assignment no longer reflects responsibility, and holding meetings to clean the tracker instead of moving the work forward.

Google's Site Reliability Engineering book defines toil as work that is manual, repetitive, automatable, tactical, and grows with the system in its chapter on eliminating toil. Backlog maintenance can become a similar kind of toil when the product has not learned how to preserve and update context itself.

The deeper cost is decision quality. When context is scattered, teams prioritize from partial evidence, keep low-value issues alive because closing them feels risky, and confuse activity with progress because the tracker shows movement but not meaning.

Forge is positioned against that pain. The goal is not to make people better at feeding a tracker. The goal is to make the tracker better at carrying the context people need.

Signals are outgrowing tickets

Not every meaningful input should start as an issue.

Teams receive more signals than they can turn into tickets. A signal might be a customer complaint, usage pattern, sales objection, support escalation, incident theme, analytics change, or repeated question from internal teams.

Some signals should become issues. Some should attach to existing issues. Some should inform an initiative. Some should be watched over time. Some should be closed as noise. Traditional issue tracking often forces a premature choice: create a ticket or lose the input.

The Scrum Guide describes the Product Backlog as an emergent, ordered list of improvements. Forge keeps that backlog idea, but treats the inputs around the backlog as equally important because signals explain what should enter the backlog, what should change priority, and what needs more evidence.

That is why Forge includes signals as a first-class product area rather than treating them as comments buried inside tickets.

Agents need a work graph

The AI era is bringing agents into software work. These agents can use tools, follow instructions, summarize information, and perform bounded actions. But an agent pointed at a flat backlog is limited.

A backlog can tell an agent what tasks exist. It may not tell the agent which tasks are connected, which signals matter, which decisions are final, which initiatives are active, or which team owns the outcome.

Agents need a work graph: issues, projects, initiatives, teams, members, signals, calls, insights, decisions, and automations connected in ways the product can understand.

OpenAI describes agents as systems that can accomplish tasks using models, tools, and workflow context. That phrase is central to Forge. Agents become more useful when the product gives them structured context to work with.

With a work graph, an agent can summarize an initiative from its underlying projects, identify issues with related signals, prepare a triage view for a team, flag missing ownership, draft follow-ups from calls, and explain what changed since the last review.

Automation without context creates noise

Automation is powerful when the rules are clear and the context is reliable. It becomes noisy when the system does not understand the meaning behind the work.

Auto-labeling issues is helpful only if labels reflect how the team actually works. Auto-prioritization is risky if the system cannot see customer impact or initiative context. Auto-closing stale issues is dangerous if old issues still represent unresolved commitments.

This is why Forge approaches automation as context-aware assistance, not blind action. The product should help agents prepare, summarize, connect, and suggest.

When automation changes something meaningful, the change should be reviewable and explainable. That same principle is visible on the Forge product surface, where agents and automation sit inside the operating workspace instead of outside it.

Traditional fields are not enough

Issue trackers often try to solve complexity by adding fields: priority, severity, component, team, initiative, confidence, source, deadline, effort, impact, status, stage, labels, custom labels, and more custom labels.

Fields can help, but they also have limits. A field can capture a value. It cannot always explain the relationship behind the value.

GitHub's Issues feature overview highlights metadata such as dates, priorities, iterations, labels, and task lists. These are useful coordination primitives, but the next layer is relationship-aware context: not just fields on issues, but connections between the work and the evidence around it.

A signal connected to an issue can explain priority better than a priority field alone. A call connected to a project can explain follow-up work better than a comment. An initiative connected to active issues can explain why a small task matters.

The future of issue tracking is not infinite metadata. It is meaningful context.

What better issue tracking looks like

Better issue tracking does not mean abandoning the fundamentals. Teams still need issues, ownership, statuses, priorities, and projects.

But in the AI era, the system needs additional capabilities: context captured at the source, continuous triage, bounded agents, automation that removes toil, and insights that support decisions.

Martin Fowler's article on Continuous Integration offers a useful parallel for work management. The more continuously a system keeps context current, the less painful it becomes to make decisions.

Context should remain connected when a call creates follow-up work, a support trend triggers a bug, or an initiative creates several projects. Triage should be part of the daily flow, not a monthly rescue operation.

Agents should have clear roles: summarize signals, draft issues from a call, suggest related work, flag stale ownership, prepare a triage brief, or generate an initiative update for review. The value comes from bounded, reviewable work connected to context.

How Forge responds to the shift

Forge is being built around a simple belief: modern teams need issue tracking that carries context well enough for people and agents to collaborate.

That belief shows up in the product direction: Inbox for fresh work and triage, My Issues for owned execution, Initiatives for long-running outcomes, Projects for structured delivery streams, Signals for meaningful inputs, Calls for conversations and follow-ups, Insights for decision-ready observations, Team spaces for shared operating context, and an Agent workspace for AI-assisted workflows.

This structure gives Forge more than a task list. It gives the product the beginnings of a work graph.

NIST's AI Risk Management Framework emphasizes governance, mapping, measurement, and management for AI systems. Forge's direction fits that spirit: AI assistance should be traceable, bounded, and understandable inside the workflow where it operates.

The goal is not to make AI decide everything. It is to reduce the manual work around judgment so people can make better decisions with less friction.

The future is context-rich issue tracking

Issue tracking is breaking because the old model is under too much pressure. The work is more distributed. The signals are more numerous. The tools are more fragmented. The expectation for speed is higher.

AI can generate more output, but it also increases the need for clarity, review, and control. Agents can help, but only if the work system gives them the context to act responsibly.

The tracker that only holds tasks will feel increasingly incomplete. The tracker that holds context will become the operating layer for modern software work.

Forge is being built for teams that want issue tracking to become more than a backlog: a place where signals become understandable, issues remain connected to their purpose, initiatives stay tied to execution, agents can assist safely, and automation removes the repetitive work that slows everyone down.

The operating principle is simple: do not just track the work. Preserve the context that makes the work worth doing.