Guardrails for Autonomous Coding Agents

By Rogier Muller06.23.26

This research library uses AI-assisted source research and drafting. Linked sources support product claims; analysis and proposed exercises are our interpretation. Unless an article documents a test and its results, do not read it as a hands-on review or an independently verified benchmark.

AI coding agents write code autonomously by turning a goal into a loop: inspect context, plan, edit files, run tools, read errors, and repeat until they produce a reviewable diff. Teams make that safe by constraining the loop with repository rules, tool boundaries, and a required review path.

Cursor gives that loop a reviewable home inside the IDE. Agentic coding governance is the set of team rules that decides what an agent may read, change, run, and submit without surprising the humans around it.

Give the agent a state machine

Start by making the workflow explicit. A state-machine workflow is a small set of allowed states, such as plan, edit, test, review, and blocked, plus the transitions that let an agent move between them.

This matters because autonomous coding is not magic. Most of what people mean when they ask how AI coding agents write code autonomously is a controlled loop with memory, tools, and feedback. Your job is to decide which parts of that loop are safe to automate.

As of June 2026, small experiments around OpenAI Codex have made this pattern easier to see: the agent should not just keep trying things forever. It should move through named checkpoints and stop when it needs missing context, risky credentials, or human judgment.

Don't treat a state machine as heavy process. Keep it boring. Five states that engineers actually follow beat a beautiful diagram nobody checks during review.

Put repo boundaries where the agent reads them

Put durable rules in files that coding agents can see before they edit. For Cursor users, that usually means a mix of AGENTS.md for repository-wide conventions and .cursor/rules/*.mdc for Cursor-specific behavior.

Use nested rules when the repo has different local truths. A billing service, a mobile app, and a migration folder should not share one vague root instruction. Local scope keeps agentic coding precise.

If your team also uses Claude Code keep CLAUDE.md aligned with the same conventions instead of inventing a second operating model. The names differ, but the team skill is the same: durable rules belong in the repo, while task-specific prompts belong in the chat.

Don't write rules like policy posters. Avoid long principles such as be careful with security. Give the agent concrete behavior: do not modify generated files, run this test command, ask before changing public API, and include risk notes in the PR summary.

For a deeper boundary pattern, see How Coding Agents Stay Inside Bounds.

Make MCP access explicit

MCP is the Model Context Protocol, a standard way for agents to connect to external tools and data sources. In practice, an MCP server can expose GitHub, docs, tickets, databases, design files, or internal systems to an AI coding agent.

That access is useful, but it changes the risk profile. Reading a ticket is different from writing to production data. Opening a pull request is different from merging one.

For engineering team training, make a small tool matrix before you enable broad access. Cursor can be the place where the developer sees the agent’s plan, accepts edits, and reviews tool use, but your team still needs to decide which servers are read-only, which are write-capable, and which require approval.

Don't give every mcp server the same trust level because setup is easier. Default to read-only. Add write access only when the review path is clear and the blast radius is small.

Paste this workflow convention

Use this as a starter convention. It is intentionally small enough to paste into a repo, review in a pull request, and improve after the first week.

# Agentic coding convention

## File: AGENTS.md

This repository allows coding agents to assist with implementation, tests, refactors, and documentation.

Agents must follow this workflow:

1. PLAN
   - Restate the task in one paragraph.
   - List files likely to change.
   - Call out missing context or risky areas.
   - Do not edit files yet if the task touches auth, billing, data deletion, migrations, or public API behavior.

2. EDIT
   - Make the smallest coherent change.
   - Do not modify generated files, lockfiles, or migrations unless the task explicitly asks for it.
   - Preserve existing architecture boundaries.
   - Prefer existing helpers over new abstractions.

3. TEST
   - Run the narrowest relevant test first.
   - If tests cannot run, record the exact command and failure reason.
   - Do not claim tests passed unless they were actually run.

4. REVIEW
   - Summarize behavior changes, files changed, and known risks.
   - Include any skipped tests.
   - Ask for human review before merge.

5. BLOCKED
   - Stop and ask when credentials, production data, unclear product intent, or broad rewrites are required.

## File: .cursor/rules/agent-workflow.mdc

---
description: Enforce the repository workflow for AI coding agents
alwaysApply: true
---

Before editing, produce a short plan.
During editing, stay inside the task scope and the nearest AGENTS.md rules.
Before finishing, provide a review checklist with tests run, risks, and follow-up work.
Stop instead of guessing when the change affects security, billing, data loss, migrations, or public APIs.

## Pull request review checklist

- [ ] The agent produced a plan before editing.
- [ ] The diff stays inside the requested scope.
- [ ] Repository rules and local AGENTS.md boundaries were followed.
- [ ] MCP/tool use was appropriate for the task.
- [ ] Tests were run, or skipped tests include an exact reason.
- [ ] Risky areas received human review before merge.

Adopt it like code, not a memo

Have a tech lead propose the convention as a normal pull request. Ask two reviewers to check it: one person who uses Cursor daily and one person who owns the repo’s release or incident risk.

Keep the convention in the repo, not in a slide deck. The AGENTS.md file should carry shared boundaries, while .cursor/rules/agent-workflow.mdc should make the same behavior visible in Cursor’s reviewable IDE workflow.

The enforcement rule is simple: no agent-authored PR merges without the checklist. This is not about slowing people down. It is about making developer productivity legible enough that reviewers can trust it.

For a broader AI coding workshop path across teams, pair this convention with AI coding governance.

Common questions

Do we need one workflow for Cursor, Codex, and Claude Code?

Yes, use one team workflow and adapt the surface area per product. The repo convention should stay stable, while Cursor rules, Codex instructions, and Claude Code memory files translate the same states into each tool’s native format.

Start with one repo

Pick one active repo, add the convention in a pull request, and require the review checklist for one sprint. After that, keep what helped and delete anything your engineers did not actually use.