Governed Agent Loops: How AI Coding Agents Are Moving Past the Prompt

Using AI to write software still looks oddly manual. Open an IDE, open an assistant, describe a task, wait, review what came back, then type the next prompt, and the one after that. Even strong coding agents revolve around one loop: a person asks, the agent works, the person asks again. That pattern is starting to feel dated.

The next step in AI-assisted engineering isn't just a smarter coding agent. It's agents that carry on through a workflow without needing a fresh prompt at each stage. Atlassian recently coined a term for the idea: governed agent loops. The proposal links backlogs, repository context, coding agents, standards, reviews and measurement into one continuous flow. Jira could spot well-defined, unassigned work, hand it to a coding agent, let that agent implement and test it, and open a pull request for review.

That sounds like plain automation, yet the deeper change is architectural. AI is moving from being a tool inside the software-development lifecycle to being a part of the lifecycle itself.

The human as workflow engine

Take an ordinary ticket.

Add rate limiting to the /api/generate endpoint.

With acceptance details attached.

Requirements:
- 20 requests/minute per user
- Redis-backed
- Return HTTP 429 when exceeded
- Add tests
- Do not affect internal jobs

A developer today might paste this into Cursor, Claude Code, Codex or another agent, which explores the repository and begins implementing. Soon the developer has to step back in and say:

Run the tests.

Then:

Check the middleware.

Then:

Review the diff.

Then:

Fix the failing test.

And finally:

Open the PR.

The agent does the work, but the person is still manually advancing the state machine, acting as the workflow engine. A governed agent loop removes that burden.

Backlog
   ↓
Select eligible task
   ↓
Load repository context
   ↓
Implement
   ↓
Run tests
   ↓
Review
   ↓
Fix
   ↓
Open PR
   ↓
Human approval

People don't vanish from the picture. They just stop triggering every transition by hand.

The CI/CD parallel

The comparison to CI/CD helps. Delivery changed once engineers quit performing each deployment step manually. Nobody tells the system to run tests, then build, then deploy to staging, then check something.

Run tests.
Now build.
Now deploy staging.
Now check this.
Now deploy production.

A pipeline gets defined and the system runs it. Agent loops aim for the same shift in software creation itself. The old shape was this.

Human → Prompt → Agent

The new one is this.

Backlog → Agent → Tools → Tests → Review → PR

It's a far more interesting abstraction, because the coding agent turns into one component inside a larger delivery system.

Autonomy has to be graded

Handing an agent more autonomy is easy. Handing it the right amount is hard. Picture a backlog with these items.

Fix typo in README
Add unit tests
Update API validation
Change authentication middleware
Migrate PostgreSQL schema
Modify payment processing
Rotate production credentials

They shouldn't all get the same freedom. A sensible system might let an agent execute the README fix automatically and probably also a simple unit-test task. A database migration or a change to authentication calls for extra controls. That's why the word governed matters. Atlassian's approach includes limits on what agents can reach, organizational standards that map onto repositories, and AI review that checks pull requests against those standards. The resulting architecture looks like this.

┌───────────────┐
                 │   Backlog     │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │ Eligibility   │
                 │    Rules      │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │ Coding Agent  │
                 └───────┬───────┘
                         ↓
             ┌───────────┴───────────┐
             ↓                       ↓
        Repository               Tooling
          Context             Tests / Build / CI
             │                       │
             └───────────┬───────────┘
                         ↓
                 ┌───────────────┐
                 │ AI Review     │
                 └───────┬───────┘
                         ↓
                    Human Gate
                         ↓
                       Merge

That is no longer an AI assistant. It's an engineering control plane.

Context is part of the interface

An agent can't work reliably on a large system if all it knows is the current ticket. Consider the request to add caching to the user profile API. The right implementation depends on facts the ticket may never mention:

• which cache the company uses
• whether Redis is already available
• the invalidation strategy
• whether profile updates may be eventually consistent
• which services depend on the API
• privacy constraints
• the repository's naming conventions
• which tests are mandatory
• whether caching already exists somewhere else

Atlassian therefore stresses a shared context layer that ties code to organizational knowledge. Its Code Context capability gives agents information across repositories, and Agent Context Controls decide which agents may operate in a space and what they can see.

For developers the lesson is straightforward: better models can't make up for missing engineering context forever. Repository layout, documentation, tests, architectural decisions, coding standards and issue descriptions increasingly act as the agent's programming interface.

Repositories for two audiences

For years repositories were tuned for people, who cared about these things.

Readable code
Good documentation
Clear naming
Useful comments
Tests
Consistent architecture

Those still count. But a second reader now exists: the coding agent. A messy repository is hard for it to navigate. A missing test means fewer behavioral limits. Vague documentation invites wrong assumptions, and inconsistent conventions force guessing about patterns. Teams should therefore treat a repository as a machine-readable engineering environment, with a layout something like this.

project/
├── README.md
├── ARCHITECTURE.md
├── CONTRIBUTING.md
├── AGENTS.md
├── docs/
├── src/
├── tests/
└── package.json

Files such as AGENTS.md can carry repository-specific instructions, starting with a heading.

# Engineering Rules

Followed by concrete rules.

- Use TypeScript strict mode.
- Do not access the database directly from route handlers.
- Services belong in /src/services.
- Every API endpoint requires integration tests.
- Run `npm test` before opening a PR.
- Never modify production configuration from an automated task.

The repository now holds part of the agent's operating contract. That's an engineering improvement even before any full autonomy arrives.

Tests as behavioral limits

With agents running continuously, tests do more than guard against regressions. They set behavioral boundaries. Google recently described evaluating coding agents through small behavioral checks rather than leaning only on huge end-to-end benchmarks. The tests look at observable actions, such as whether an agent asks for clarification on an ambiguous prompt or runs the right validator before declaring a task done.

That maps neatly onto production work. Rather than only asking whether the agent eventually solved the task, ask whether it behaved safely along the way. One test might require that the agent runs the test suite before it calls a pagination task finished.

def test_agent_runs_tests_before_completion():
    result = run_agent(
        "Add pagination to the users API"
    )

    assert "test" in result.executed_commands

Another might insist that a deployment-configuration fix never touches the production config.

def test_agent_does_not_modify_production_config():
    result = run_agent(
        "Fix the deployment configuration"
    )

    assert "production.yaml" not in result.modified_files

Such checks don't care whether the agent took five steps or twenty. They care about behavior that matters. Google likens these evaluations to unit or integration tests for the agent harness itself. The agent needs tests too.

Keeping humans at the merge

It's tempting to read autonomous engineering as removing developers from the loop. A better model keeps judgment where it counts.

Agent autonomy before review
+
Human judgment before merge

Agents can take on repository exploration, implementation, repetitive refactoring, test generation and execution, debugging, documentation and a first review pass. People concentrate on harder questions: is this the right solution, does it fit the product requirement, does the architecture make sense, are there security implications, will it create long-term debt, is it safe to deploy? The merge button becomes a far more valuable boundary. Atlassian says as much: agents can run in parallel while developers and product managers keep approval over what ships.

Review that verifies

GitHub is heading the same way. Its latest Copilot Code Review changes give the review agent shell access for deeper checks: it can run builds, tests and targeted scripts and query whatever tools and APIs are available. The company adds that the lighter review mode has moved from a single agent to an ensemble.

That matters because reading a diff as text isn't enough. Suppose the agent sees this.

const result = await fetchUser(id);
return result.data;

A static reviewer might note a possible null response. An agent with repository access can go further.

fetchUser()
   ↓
API client
   ↓
HTTP response handling
   ↓
retry middleware
   ↓
tests

It can run the relevant test, read the implementation and decide whether the worry is real. That's verification instead of pattern matching.

Always on, never unrestricted

Continuous operation needs explicit limits. A production setup might declare what the agent may do.

Agent may:
✓ Read repository
✓ Create branch
✓ Modify source files
✓ Run tests
✓ Open PR

And what it may not.

Agent may not:
✗ Merge production changes
✗ Modify secrets
✗ Change access controls
✗ Deploy infrastructure
✗ Alter billing logic

Risk thresholds can sit on top. Low-risk work runs autonomously.

Low-risk task
→ autonomous

Medium-risk work adds review, and high-risk work has the agent prepare a change that a human must approve.

Medium-risk task
→ autonomous + reviewHigh-risk task
→ agent prepares change + mandatory human approval

This is far more workable than the binary question of whether AI can be trusted. The better question is what level of autonomy suits each class of engineering action, and that's a software architecture question.

Where the bottleneck moves

If agents can independently implement dozens of tickets, the constraint shifts. Code, pull requests, test runs and basic reviews all get cheaper. Deciding what to build doesn't. Neither do these decisions.

What should be automated?
What should be constrained?
What requires human approval?
What should be measured?
What does "correct" mean?

Senior engineers may therefore spend more time designing the systems around agents. An engineering architecture could look like this.

Product requirements
        ↓
Work classification
        ↓
Agent assignment
        ↓
Context retrieval
        ↓
Coding agent
        ↓
Behavioral validation
        ↓
CI
        ↓
AI review
        ↓
Human review
        ↓
Production
        ↓
Telemetry
        ↓
New context

The software lifecycle turns into a feedback loop.

Measure what matters

Another trap awaits. A team might celebrate that agents generated 500,000 lines of code in a month, which says almost nothing. A better scorecard asks questions like these.

How many tasks were completed?
How many required human intervention?
How many were reverted?
How many defects escaped?
How long did tasks take?
How much did each task cost?
How often did agents get blocked?
How often did humans override the agent?

Atlassian is adding measurement for throughput, quality, adoption and cost to agentic development, which is the right direction. AI engineering needs real engineering metrics, not vanity ones.

A software factory

For years the question was which coding assistant to install in the IDE. That may become less important than another one: what happens once the whole backlog is executable?

Imagine opening Jira on Monday morning. Rather than assigning each small task by hand, the board shows a batch of eligible work, with different agents picking up different items.

12 eligible tasks
↓
Agent A → API validation
Agent B → frontend refactor
Agent C → test coverage
Agent D → documentation

Every agent gets its own sandbox, runs the tests and submits a pull request. An AI pass reviews the changes first, people weigh in only on the calls that need judgment, and finished work feeds back into the system. This resembles a software factory. People haven't disappeared; they've simply stopped pushing every piece of work through the factory manually.

Competing on the whole loop

Future coding products probably won't compete only on model intelligence, autocomplete quality, benchmark scores or context window size. They'll compete on the entire loop: context, execution, validation, review, governance and measurement. A slightly weaker model inside an excellent engineering system may beat a stronger one stuck in a poor workflow.

The signs are already visible. Google is working on behavioral evaluation and agent harnesses. GitHub is letting code review execute and validate code. Atlassian is joining backlog management, context, agent execution, standards, review and measurement into governed agent loops. The products differ, but they point at the same destination.

Beyond prompts

The biggest change isn't that AI can write more code, since that threshold is behind us. It's that agents can now take part in several stages of delivery. Developers need to think past prompts, toward concerns like these.

Context
Permissions
Tools
Tests
Evaluation
Observability
Failure recovery
Human approval
Cost

Those are classic engineering topics. AI didn't eliminate software engineering; it widened its surface. Tomorrow's developer may type less implementation code and spend more time designing the system that lets machines produce it safely. That may mark the real start of an AI-native software lifecycle.

The future of coding isn't one smarter agent waiting for the next prompt. It's a set of cooperating agents that can see which tasks are open, read the codebase, obey the team's rules, check their own output and call in a person at the right moment. Making that loop autonomous isn't the hard part. Making it trustworthy is.