AI agents need context, not just prompts

Prompts are visible. Context is structural.

Prompts are easy to rewrite. Context has to be captured, organized, permissioned, connected, and kept current. Prompts tell an agent what to do. Context helps the agent understand what the work means.

This is where many AI experiments in software teams begin to disappoint. The model is capable, the prompt is clever, and the demo is promising. Then the agent enters real product and engineering work and runs into stale issues, missing decision history, disconnected customer signals, meeting notes with no follow-up trail, initiatives that drift away from execution, and ownership that lives in memory instead of the system.

The problem is not that teams need better prompt libraries. The problem is that agents need a better workspace.

Forge is being built around that belief. As Why issue tracking is breaking argues, AI agents should not operate on a pile of disconnected tickets. They should work inside a structured system of issues, signals, calls, initiatives, teams, and insights.

OpenAI's Agents guide describes agents as systems that can use models, tools, and instructions to accomplish tasks. For software teams, the missing ingredient is often not another instruction. It is the workflow context that lets the agent act usefully and safely.

The prompt is not the product

Prompts are important. A vague instruction produces vague output, while a focused instruction can make an agent more useful, predictable, and easier to evaluate.

But prompts are only one layer of the system. If the underlying work context is weak, even a strong prompt has to compensate for missing information. It has to infer what should have been explicit.

A prompt may ask the agent to draft an issue, classify feedback, summarize a thread, propose a status update, or suggest related work. Context helps the agent know whether those actions are correct, relevant, and safe.

The OpenAI Agents SDK separates instructions, tools, and context in a way that mirrors the product problem. Instructions shape behavior, tools enable action, and context tells the agent what work it is actually doing.

Prompt-first workflows often hit a ceiling because they improve the interaction without repairing the environment around the interaction.

A better prompt cannot fix missing work memory

Most teams do not lack words. They lack shared memory.

An issue might describe what needs to be built, but not why it matters. A call might include the customer pain, but the follow-up issue may not link back to the conversation. An initiative might define a desired outcome, but the active projects may not clearly show how they support it.

When that memory is missing, agents struggle in ways that feel subtle at first. Summaries omit the original customer signal. Drafted issues repeat decisions that were already rejected. Suggested priorities ignore initiative context. Automations route work to the wrong team.

The prompt did not fail alone. The system failed to preserve meaning.

That is why the Forge thesis in Why we created Forge starts with the work system itself. Agents become more useful when the product carries the memory people otherwise reconstruct by hand.

Context is the new interface

For years, the main interface for work management was the task list. A team opened the tracker, viewed the backlog, filtered issues, updated statuses, and moved work across columns.

In the AI era, the interface is changing. Agents do not only need screens. They need structured access to the work: what objects exist, how those objects relate, what actions are allowed, and which sources support their outputs.

That does not mean replacing human interfaces with hidden automation. It means designing the product so both people and agents can understand the same work system.

Anthropic's Model Context Protocol documentation reflects a broader industry movement toward connecting AI systems to external tools and data sources. Forge applies that same context-first idea at the product level: agents need access to the right work context, not just a text box.

Issues, signals, calls, initiatives, teams, and insights give context a durable form. When these objects connect, the system becomes easier for people to navigate and easier for agents to assist.

Context has to be structured enough to trust

Not all context is equally useful. A long comment thread is context, but it may be noisy. A meeting transcript is context, but it may contain unresolved ideas. A customer quote is context, but it may represent one account rather than a broad pattern.

For agents, this matters. An agent needs to know not only what information exists, but what kind of information it is.

Forge gives context stronger shapes. A signal is different from an issue. A call is different from an initiative. A team is different from an assignee. An insight is different from raw activity.

Those distinctions help agents avoid flattening everything into undifferentiated text. They create the difference between summarize this pile and prepare a triage brief from these customer signals, related issues, and active initiatives for this team.

Issues are only the start

Issues are still necessary. They give work a place to live. They help teams assign owners, define status, discuss implementation, and track progress.

But an issue is only the start of the context an agent needs. A title like improve onboarding workspace setup gives the agent a topic. The agent still needs to know which users struggled, which calls mentioned the problem, which initiative onboarding supports, which team owns the setup experience, which related issues are open, and what should not change because of technical constraints.

GitHub's Issues documentation describes issues as places to track ideas, feedback, tasks, and bugs. Forge builds from that familiar unit, but treats the issue as one object inside a larger context network.

Useful relationships can include source signals, calls, initiatives, projects, teams, related issues, and insights. A small bug may need only a clear reproduction path. A strategic workflow change may need signals, calls, initiatives, and multiple team links.

Agent-ready issue tracking is not about adding ceremony. It is about making the important context available when the work requires it.

Signals show where work came from

One of the biggest weaknesses in traditional issue tracking is that it often loses the source of the work.

A product request becomes a ticket. A customer complaint becomes a bug. A sales objection becomes a roadmap item. An incident pattern becomes a reliability project. Once the issue exists, the original signal may fade.

Agents need those signals because signals provide evidence, urgency, repetition, and nuance. They help prevent the tracker from becoming a pile of isolated tasks with no visible origin.

The Scrum Guide describes the Product Backlog as an emergent, ordered list of improvements. Signals are one way to keep that list grounded in reality because they explain what should enter the backlog, what should change priority, and what deserves more investigation.

AI triage is only as good as the evidence it can see. Signal-aware agents can cluster repeated feedback, identify related issues, attach new evidence to existing work, and prepare product and engineering triage notes for human review.

Calls carry decisions

Some of the most important product and engineering context lives in conversations.

Customer calls reveal pain in the customer's own words. Internal planning calls capture tradeoffs. Incident reviews explain why a system failed. Product reviews decide what should change. Engineering discussions define constraints that may never make it into the issue description.

If those calls are disconnected from the work, agents lose a major source of truth. A summary may include action items, but miss the decision behind them. It may list follow-ups, but fail to link them to the right initiative or team.

NIST's AI Risk Management Framework supports a practical product principle here: when agents act on conversation data, the source, purpose, and review path should be clear.

In Forge, calls are part of the structured work system because conversations often create or reshape work. The goal is to move from passive call notes to connected work memory.

Initiatives help agents understand outcomes

Issues explain tasks. Initiatives explain outcomes.

Without initiative context, agents may optimize for local completion rather than meaningful progress. They can help close tickets, but miss whether those tickets advance the outcome the team actually cares about.

The Project Management Institute describes projects as temporary efforts undertaken to create value. Forge uses similar practical reasoning: teams need structures that connect temporary work to durable outcomes.

With initiative context, a status update can move beyond three issues were completed and two remain in progress. It can explain that an onboarding initiative moved forward through workspace setup improvements, but activation measurement remains blocked because the event taxonomy issue has no owner.

Agents should help teams understand progress, risk, and next actions at the level where decisions are made.

Teams give agents boundaries

Agents also need to understand teams. In many trackers, ownership is reduced to an assignee. That is useful, but incomplete.

Real ownership often lives at the team level. A person may own the next task, but a team owns the domain, workflow, system, or outcome.

Team context tells agents where work belongs, who should be involved, which workflows matter, and which review path makes sense. Without it, agents route work to the wrong group, summarize issues without understanding priorities, or recommend automation that conflicts with how a team operates.

Team Topologies emphasizes clear team responsibilities and interaction patterns in its key concepts. Forge does not force one operating model, but it is being designed with the same respect for team ownership and collaboration boundaries.

In Forge, team spaces give projects, issues, signals, calls, and insights a shared operating home, making agent assistance more grounded because the agent can work within the team's visible context.

The real AI advantage is better coordination

There is a temptation to measure AI agents by how much work they can do alone. For software teams, the more valuable question is how much coordination they can remove.

A good agent does not need to replace a product review, engineering discussion, or prioritization decision. It can make those moments better by summarizing relevant signals, drafting issues from calls, linking related work, flagging missing ownership, preparing initiative updates, and identifying stale or duplicate issues.

Google's Site Reliability Engineering book defines toil as manual, repetitive, automatable work that scales with growth in its chapter on eliminating toil. Many coordination tasks in issue tracking have the same shape.

This is where AI becomes operationally valuable. It reduces the time people spend reconstructing context so they can spend more time making decisions.

The best agents make the system calmer. They remove repeated effort, surface what matters, explain their sources, and stay inside useful boundaries.

What an agent-ready workspace requires

An agent-ready workspace is not just a tracker with AI features added on top. It needs product foundations that make context durable and usable.

The system needs clear work objects, visible relationships, reviewable actions, team boundaries, and automation that starts small. Issues, signals, calls, initiatives, teams, and insights make context addressable. Relationships show what belongs together. Reviewable actions build trust.

GitHub's documentation for Copilot coding agent shows where the category is moving: agents are becoming participants in development workflows. As that happens, the surrounding work system needs clearer assignments, context, and boundaries.

The safest automation starts with repetitive, well-understood work: drafting triage summaries, linking obvious related work, preparing follow-ups, flagging missing owners, and summarizing initiative changes.

Over time, automation can become more powerful. But it should earn trust by reducing friction before it expands.

How Forge connects prompts to work context

Forge's product direction is built around the belief that agents need structured context before they can become reliable teammates.

That is why Forge is not only an issue tracker. It is being shaped as a workspace where issues hold work, signals explain where work came from, calls preserve conversations and decisions, initiatives connect work to outcomes, teams clarify ownership, and insights help turn activity into decisions.

This structure gives prompts something stronger to operate on. Instead of asking an agent to summarize this ticket, a team should be able to ask for a triage brief using new signals, related issues, recent calls, and active initiatives, with the items that need human review clearly highlighted.

The Forge product surface is being shaped around that kind of context-aware work orchestration: people make the important calls, and agents prepare the ground for better judgment.

Better prompts can improve an AI agent. Better context can change what the agent is capable of doing.

Context tells the agent what the work means

If agents only see isolated tasks, they will produce isolated assistance. If they can see issues, signals, calls, initiatives, teams, and insights as connected parts of the same work system, they can help teams triage, summarize, route, update, and decide with more confidence.

The future of AI agents in software work will not be won by prompt libraries alone. It will be won by products that understand the shape of the work.

A useful principle for this next phase is simple: the prompt tells the agent what to do. Context tells the agent what the work means.

Forge is being built from that principle. If a team is experimenting with AI agents but still struggling with stale tickets, scattered customer signals, meeting follow-ups, and unclear ownership, the missing layer may not be another prompt.

It may be the structured workspace that helps agents and people understand the work together.