Atlassian Wants to Govern Your Agent Loops: Running AI Coding Agents at Scale in the AI-Native SDLC

Atlassian opened its September 10, 2026 announcement with a number that should make any platform team uncomfortable. In its 2026 AI SDLC study, 94% of engineering leaders said they are using AI, but only 6% said they have the systems to scale it across the whole software lifecycle. Almost everyone is experimenting with agents; almost nobody can let them run at scale without things breaking. The new Jira features Atlassian shipped are an attempt to close that gap by adding context and governance to agent loops, not more autonomy. Here is what changed and how to run it in your own repository. The announcement is really a statement about where the agentic SDLC is heading: the bottleneck is no longer model capability, it is the context and governance plumbing around it. Teams that treat that plumbing as an afterthought will keep shipping demos; teams that build it will ship products.

From demo to hundreds of engineers

1. Why Agent Loops Fail Without Context

Atlassian's framing is blunt: agents fail when they do not understand your world, meaning your architecture, your decisions, your standards, and the institutional memory that lives in your team's heads. A coding agent that can read a single file but not the surrounding multi-repository context will confidently produce code that compiles and breaks your conventions. Code Context, built on Atlassian's Teamwork Graph, is designed to give Rovo and coding agents secure intelligence across multi-repo codebases so plans, triage, and root-cause discovery are grounded in how your system actually works. The practical signal is that context has become a platform concern rather than a prompt concern. Instead of pasting architecture notes into every agent session, you give the agent a secure, scoped view of the graph that already knows your repositories, decisions, and standards. That shift is what makes an agent's output reviewable instead of merely plausible.

# jira-work-item.yaml — an agent-ready work item with explicit acceptance criteria
key: APP-4821
type: Task
summary: "Add idempotency keys to POST /payments"
agent_eligible: true
context:
  repos: [payments-api, shared-lib]      # Code Context scopes what the agent can read
  standards: [api/error-handling.md, security/idempotency.md]
acceptance_criteria:
  - "Duplicate POSTs with the same Idempotency-Key return the original response"
  - "Keys expire after 24h and are stored in Redis, not Postgres"
  - "Unit tests cover the replay path and a concurrent-duplicate race"
definition_of_done:
  - "PR opened and linked to APP-4821"
  - "AI Review and CI both green"
# Only well-defined, unassigned items should be agent_eligible.
# Vague tickets are the #1 cause of agent loops that never converge.

2. Make Work Items Agent-Ready

The first practical lever is not a model, it is ticket hygiene. A Jira Coding Agent picks up well-defined, unassigned work items, performs the development work, and opens a pull request for human review. The key phrase is well-defined. Code sample 1 shows the shape of an agent-eligible work item: explicit acceptance criteria, the exact repos it may read, the standards it must follow, and a definition of done. Vague tickets are the single biggest cause of agent loops that never converge, because the agent cannot know when it is finished. A useful metric to track is your agent-eligibility ratio: the share of open tickets specific enough for an agent to action without a human round-trip. If that number is low, the problem is your backlog, not your model.

// agent-context-controls.json — who can run, where, and what they may see
{
  "space": "ENG-PLATFORM",
  "agents": {
    "jira-coding-agent": {
      "allowed_repos": ["payments-api", "shared-lib"],
      "denied_paths": ["**/secrets/**", "**/.env*", "infra/prod/**"],
      "data_classification_ceiling": "internal",
      "requires_human_approval_for": ["dependency-add", "schema-migration", "infra-change"]
    },
    "rovo-research-agent": {
      "allowed_repos": ["*"],
      "read_only": true,
      "data_classification_ceiling": "confidential"
    }
  },
  "default": "deny"
}
// Agent Context Controls let platform teams decide exactly which agents
// operate in a space and what each one is allowed to read.

3. Govern Which Agents Can Touch What

Autonomy without scoping is how you get an agent editing your production Terraform. Agent Context Controls let platform teams decide which agents operate in a space and exactly what they are allowed to see, with a default of deny. Code sample 2 is a governance policy: allow-listed repos, denied paths for secrets and production infrastructure, a data-classification ceiling, and a list of changes that always require human approval. This is the difference between a demo agent and an agent you would trust across hundreds of engineers. Governance also gives you a defensible audit trail. When an agent opens a pull request, you can answer exactly which context it saw, which tools it called, and which policy allowed it, which turns an incident review into a five-minute lookup instead of a week of forensics.

# standards/api-error-handling.md — the policy an AI Review actually enforces
rules:
  - id: ERR-1
    must: "All 4xx/5xx responses use the shared error envelope"
    pattern: 'res.status(4|5)\{2\}\).json\(\{ error: \{ code, message \} \}\)'
  - id: ERR-2
    must: "No raw stack traces returned to clients"
    forbid: "stackTrace"
  - id: IDEMP-1
    must: "Mutating endpoints accept an Idempotency-Key header"
    applies_to: ["POST", "PUT", "PATCH"]
severity:
  ERR-1: blocking
  ERR-2: blocking
  IDEMP-1: warning
# Store standards as files in the repo so every review is deterministic
# and every change to policy goes through a pull request.

4. Write Standards as Code So Review Is Deterministic

AI Review is only useful if the rules it enforces are written down and versioned. Code sample 3 makes standards a first-class artifact: each rule has an id, a must or forbid clause, a pattern, and a severity. Storing standards as files in the repo means every review is reproducible and every policy change is auditable through a pull request. When a reviewer disagrees with a blocking rule, the argument happens once, in the standards file, instead of in every pull request an agent ever opens. Keep the rule set small enough that a reviewer can hold it in their head. Ten precise, enforced rules change behaviour; a hundred aspirational ones get ignored, and an AI reviewer that flags everything is indistinguishable from one that flags nothing.

// mcp-agent.manifest.json — expose only the tools an agent needs
{
  "agent": "jira-coding-agent",
  "mcpServers": {
    "repo-tools": { "tools": ["read_file", "search_code", "open_pr"] },
    "test-runner": { "tools": ["run_unit_tests"] }
  },
  "token_budget": { "per_task_usd": 2.5, "per_task_minutes": 20 },
  "network": { "egress": "deny-by-default", "allow": ["registry.npmjs.org"] }
}
// Any agent works: Claude, Cursor, Codex, GitHub Copilot, or a custom MCP agent.
// Keep the manifest in version control next to the code it touches.

5. Scope Tools and Budget with a Manifest

The features work across any agent: Claude, Cursor, Codex, GitHub Copilot, or your own MCP agent. That means you need one place that declares what each agent may do. Code sample 4 is an agent manifest that lists MCP tools, a per-task token and time budget, and a deny-by-default network egress policy. This is where cost control and security meet: an agent that can only call read_file, search_code, open_pr, and run_unit_tests, with a two-dollar cap, cannot quietly do anything catastrophic. Manifests also make agents portable. Because the declaration is model-agnostic, you can swap Claude for Codex, or add a custom MCP agent, without re-auditing permissions from scratch.

# .github/workflows/agent-gate.yml — never merge agent output on trust alone
name: agent-gate
on: pull_request
jobs:
  gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - run: npm ci && npm test
      - name: Standards check
        run: npx evergreen-standards lint --standards standards/
      - name: Require human approval from CODEOWNERS
        if: contains(github.event.pull_request.labels.*.name, 'agent-authored')
        run: |
          echo "Agent-authored PR must be approved by a CODEOWNER."
# The Jira Coding Agent opens the PR; a human still merges it.
# Keep that gate explicit so autonomy never equals unreviewed code.

6. Keep the Human Gate Explicit

The most important design decision in Atlassian's model is the one it does not remove: the agent opens the pull request, and a human merges it. Code sample 5 wires that into CI by requiring a CODEOWNER approval on any PR labelled agent-authored, and by running your standards check and test suite first. Agent loops, Standards, and AI Review are in private early access, Code Context is rolling out in open beta to paid customers, and Atlassian is hosting a State of AI SDLC summit on September 22, 2026. The direction is clear: the winners will not be the teams with the most autonomy, but the teams with the best-governed loops. The 94% to 6% gap will not close on its own. It closes when context, standards, and approvals become defaults rather than heroic one-off efforts.