Context engineering for coding agents
Context engineering is the work of deciding what a coding agent sees before it acts. It's the biggest lever you have on output quality because a capable model is only as good as what you put in front of it.
In Jira, the context an agent needs is already part of the work. The work item carries the goal and the acceptance criteria, and the Teamwork Graph connects it to the code, the decisions, and the docs around it, so an agent acts on real intent instead of a blank prompt. That context stays shared across your team, not stuck in local files on one machine.
This guide covers what context engineering is, why the context window is the real constraint on coding agents, and how you engineer context in Jira so agents get what they need without you hand-feeding it through every prompt. In practice that comes down to a few moves you make in the work you already run:
Give the agent the goal, not just a prompt. Write the Jira work item as the spec, with acceptance criteria the agent is judged against.
Let the graph supply the surrounding context. By using the work item as the starting point for the prompt, the Teamwork Graph expands it into the docs, decisions, and related context around the task.
Keep standards shared and current. Conventions live in Confluence, drawn from the same source by every agent and teammate.
Feed any agent the same context layer. The same organizational context reaches every coding agent, like Claude Code, Cursor, Codex, GitHub Copilot, the Jira Coding Agent, and more.
What is context engineering?
Context engineering is the practice of deliberately deciding what information a model sees at each step, so a coding agent has what it needs to do the work correctly. That information is more than the prompt: it's the codebase, your standards, dependencies, git history, tool definitions, goals, and acceptance criteria. Curating that set for each task is the new job.
Prompt engineering means you curate the information and feed it into a single instruction yourself. Context engineering means the system supplies what the agent needs across a multi-step task: what goes in, what gets retrieved, what gets summarized, and what gets left out, so the agent can find the rest on demand.
It’s important to note that more context is not necessarily better context:
High-signal context is the information that actually helps with the task at hand
Low-signal context is the stale, off-topic, or duplicated content the model still has to read
As a context window fills with low-signal tokens, answers get slower and less accurate even though the model hasn't changed. That degradation is called context rot: the gradual decline in output as the context window fills with stale, low-signal, or contradictory tokens. Good context engineering is as much about removing stale context as adding the right context.
Why is the context window the constraint on coding agents?
A coding model can only reason over what fits inside the context window, which is small compared to your codebase, your docs, and your team's history. A capable agent still ships wrong or unsafe code when your conventions, your architecture, or the decision behind a task never made it into the window.
When context is left to the agent to gather, a few failure modes show up again and again:
The agent drifts on a long task because the decision it made early gets pushed out of the context window as newer, lower-signal tokens crowd in.
It over-retrieves, pulling far more into the window than it uses and spending the token budget on noise.
It never sees a standard you didn't put in front of it, then ships code that breaks a pattern the rest of the team follows.
It works fine solo but has no idea what the rest of the team, or another agent, is doing in the same area.
Instead, making the right context easily accessible lets the agent surface what it needs on its own as it goes along, so your prompts can stay high-level instead of having to spell out every convention and decision manually.
How do you engineer context for coding agents in Jira?
In Jira, you make the work itself the context: the intent lives in the work item, the surrounding knowledge is connected through the Teamwork Graph, and durable standards and decisions are pulled in from Confluence and Loom, where every agent and teammate draws from the same source. Jira extends beyond local files on a single machine to the goals, the ongoing decisions and conversations, and the history across your work. It keeps all of that information shared, so the context an agent acts on is structured, current, and consistent for the whole team.
Context engineering rests on three principles:
Selecting the right information
Keeping it structured
Making it persist
1. Selection and retrieval: write the work item as the spec
Selection is choosing the smallest high-signal set of context for a task; retrieval is pulling the right facts on demand instead of dumping everything into the window up front. In Jira, both start with the work item.
How it works in Jira: Put the goal in the description and the acceptance criteria in a checklist. That gives the agent the intent and the bar it will be judged against, in a structure it can read. Then assign the work item to a connected agent. It starts from the work item and its linked context, not the whole codebase. Sparring with the agent to sharpen that spec is part of the work: it reads volumes fast and helps you find the gaps before it starts.
Coming soon: Jira Planner turns ideas into agent-ready plans and work items with the context already attached. Join the waitlist.
2. Shared context: link the work, don't paste it
Structure and format is key: shape context so an agent can find its way around it, and keep it connected rather than copied. The Teamwork Graph is what makes the surrounding context available without the need to assemble it by hand each time.
How it works in Jira: Link the work item to related work items, the code, and the Confluence pages that hold the spec, the RFC, or the decision record. The agent inherits the context around the task, not just the ticket text. A Loom walkthrough counts too: a recorded bug repro or design rationale carries its transcript and summary into the graph, so an explanation you'd have given a teammate becomes context an agent can read. This serves the "right retrieved facts" from your actual work, not a separate vector store you have to build and maintain.
3. Persistence: keep standards and decisions where they compound
Persistence, or memory, is keeping durable facts available across sessions so the agent doesn't start from zero every time. The three buckets to think about: what the agent holds during a task, what it should keep between tasks, and what it can look up when needed.
How it works in Jira: Conventions, architecture decisions, and preferred patterns live in the shared Confluence space, where the whole team and every agent draw from the same source through the graph, rather than a copy on one person's machine that no one else can see. As work runs through the system, the graph gets richer, so the next agent has more to draw on. Context accumulates as work gets done, with no extra manual step for the developer.
Two things keep those working across a team: one context layer every agent can use, and governance that keeps it reliable and permitted.
One context layer for any agent
The context you engineer is only worth it if every tool can use it. Re-teaching each agent your standards is the fastest way to let context rot back in.
How it works in Jira: Give any coding agent the same organizational context through two paths. The Teamwork Graph CLI gives your coding agent direct access to that context and its tools from the terminal; set it up once and your agent can query the graph as it works. The Atlassian Rovo MCP Server does the same for MCP clients like Claude, Cursor, Codex, and GitHub Copilot. The Teamwork Graph is what carries it either way: work items, decisions, docs, and code connected as one queryable layer. You engineer context once and use it with whichever model does the work.
Governance: keep the context reliable and permitted
Context is only useful if it's current and the agent is allowed to see it. Governance keeps the shared layer trustworthy as more agents draw on it.
How it works in Jira: Agents inherit the same permissions your team already uses as the baseline, so an agent sees what the person behind it can see, and no more, and can be scoped further with agent-specific rules. For how access, approval, and audit fit together, see Agentic engineering guardrails and safety in Jira.
How does Jira fit with the rest of your context stack?
Most of a coding agent's context today lives on one machine: the repo it has open, a few local files, and whatever the developer typed into the prompt. That works solo, but it's scattered, per-person, and it forgets. Jira and the Teamwork Graph pull the context that matters into one shared, current, governable layer the whole team and its agents draw from.
Context dimension | Where it lives without Jira | What Jira and the Teamwork Graph add |
The goal and acceptance criteria | A developer's prompt, a chat thread, someone's memory | The work item carries the goal and the bar it'll be judged against, shared with everyone |
Codebase and history | The repo open on one machine | Work items linked to the branches, commits, and PRs that carry them out, so anyone can trace a task to its change |
Standards and conventions | Local config files (CLAUDE.md, AGENTS.md), a README, tribal knowledge | Durable, shared standards in Confluence that every agent and teammate draws from |
Related docs and decisions | Scattered across docs, work items, and people's heads | The graph connects specs, RFCs, and decision records to the work automatically |
Memory across sessions | Per-agent, in-window, gone when the window clears | Decisions and history persist, so context compounds as work runs through the system |
Token and cost efficiency | Whole files and repos referenced in the window, paid for every run | The agent works from a high-signal set linked to the task |
None of this replaces your coding agent, your IDE, or your local config. Those still do the per-repo detail and the actual code. Jira is the shared layer on top, so the context they all work from is structured, current, and the same across your team.
How to give your first agent real context in Jira
Context engineering is ultimately about giving an agent the tools and information to find what it needs on its own. Jira and the Teamwork Graph are the shared context layer it reaches through MCP or CLI, so the work is keeping that layer accurate and connected.
Start with one well-formed work item to see the difference between an agent guessing and an agent working from intent.
Give the agent a bar to be judged against. Pick one scoped, low-risk task that's easy to undo, like a self-contained refactor or a small bug fix, and write the goal in the description with acceptance criteria in a checklist.
Let the agent inherit context instead of pasting it. Connect the work item to its code by referencing the work item key in your branch, commit, or PR, and link the doc or decision behind it. The agent picks up the linked context around the task, not just the ticket text.
Point to a shared standard. Link the convention it should follow to a Confluence page so the next agent and teammate use the same source.
Assign it to an agent. The agent starts from the work item and its linked context, a more focused starting point than the whole codebase or a blank prompt.
Review against the criteria that seeded it. Check the pull request against the acceptance criteria you wrote in the work item, so the output is judged against the original bar you gave the agent.
Have the agent close the loop. Prompt it to update the work item at the end with a session summary, the key decisions and tradeoffs, and the linked PR, so the next teammate or agent can pick up where it left off through the Teamwork Graph.
Run a few work items this way and the graph fills in as you go: each agent leaves a summary, its key decisions, and the linked PR on the work item, so the next one starts from a fuller picture than the last. That's context engineering that compounds instead of resetting every run.
Frequently asked questions about context engineering
What is the difference between context engineering and prompt engineering?
Prompt engineering is the discipline of manually curating relevant information for a single prompt. Context engineering is the discipline of implementing a system that supplies information for an agent across a multi-step task, including retrieval, structure, memory, and the goal itself, so it surfaces the details on demand as needed.
How do AI coding agents get context from Jira?
Agents draw context from the work item, its description and acceptance criteria, and from the Teamwork Graph, which connects related work, docs, and code, so the agent acts on real intent, not a blank prompt.
Why do coding agents produce wrong code even with a good prompt?
A prompt rarely carries your conventions, architecture, or the decision behind a task. Most agent failures are context failures, not model failures, and better context fixes more than better wording.
Do I still need context engineering if my agent already reads my repo?
Yes. A repo tells an agent what the code is, but not why it was built that way, which standards to follow, or what else is happening across the team. Context engineering supplies the rest.
What is context rot?
Context rot is the gradual degradation of an agent's output as its context window fills with stale, low-signal, or contradictory tokens. Answers get slower and less accurate even though the model hasn't changed.