What a Production-Ready AI Coding-Agent Workflow Needs

What does a production-ready AI coding-agent workflow need?

It needs eight things: a repository context file the agent reads every session, written team conventions, reusable skills or commands for repeated procedures, MCP servers that give scoped access to outside tools, tests and CI as the agent's verification loop, an isolated workspace such as a sandbox or worktree, permission rules that deny risky actions, and human approval before anything merges. Each one is cheap to start with. Skipping any of them is where most agent-related messes come from in our experience.

Why the setup matters more than the model

Coding agents such as Claude Code, OpenAI Codex, GitHub Copilot's cloud agent and Cursor's Agent can read a repository, edit files, run commands and open pull requests. Interest is clearly high: a third-party tracker of open-source AI developer tools, awesome-ai-dev-tools, ranks 42 projects by GitHub stars, and when we checked it on 20 October 2026 its top five were all coding agents or agent harnesses. Stars measure attention, not quality or satisfaction, so treat that as a signal of adoption pressure rather than proof that any tool works well.

What separates a useful agent from a risky one is rarely the model. It is whether the agent knows how your project works, whether it can prove its changes are correct, and whether it is physically unable to do the things you never want it to do. Those are tooling problems, and they have tooling answers.

1. Repository context files

Every session starts with an empty context window, so the agent needs a file it reads at the start of each one. The main formats today:

• `CLAUDE.md` for Claude Code. Anthropic's documentation says a project file is shared with the team through version control and should hold build and test commands, coding standards, architectural decisions, naming conventions and common workflows. It recommends targeting under 200 lines per file, because longer files consume more context and reduce adherence.
• `AGENTS.md`, an open format described as a README for agents and now stewarded by the Agentic AI Foundation under the Linux Foundation. Its site suggests sections for project overview, build and test commands, code style, testing and security, and says the closest AGENTS.md to the edited file wins in a monorepo. Claude Code's documentation says it reads AGENTS.md when no CLAUDE.md is present, and can import it from a CLAUDE.md.
• Cursor rules, stored as .mdc files in .cursor/rules and version-controlled. Cursor's documentation describes rules that always apply, apply to matching files, are pulled in by the agent when relevant, or are applied manually, and recommends keeping rules under 500 lines. Cursor also reads AGENTS.md.

If your team uses more than one agent, we recommend keeping one source of truth, usually AGENTS.md, and pointing the tool-specific files at it rather than maintaining three copies that drift apart. Keep it to facts the agent needs every time: how to install, build, test and lint, where things live, and the handful of rules people keep getting wrong.

2. Team rules and conventions

Context files are for facts; rules are for the conventions you want applied in specific places. Both Claude Code and Cursor support rules scoped to file paths, so your API conventions load only when the agent touches API code and your test conventions only when it touches tests. That keeps the always-loaded context short. Two points from the documentation are worth knowing. Anthropic notes that Claude treats these files as context, not enforced configuration, so anything that must never happen belongs in permissions or hooks, not in prose. And contradictory instructions lead to one being picked arbitrarily, so review them periodically.

3. Reusable skills and commands

When you notice you keep pasting the same checklist into chat ("add a migration", "cut a release", "write an end-to-end test for this flow"), turn it into a skill. In Claude Code a skill is a SKILL.md file in .claude/skills/ with a name and a description, committed so the whole team gets it. Claude can load it automatically when the description matches, or you can run it as a slash command. The documentation explains that a skill's body loads only when used, so long procedures cost almost nothing until needed, and that a disable-model-invocation setting restricts a skill with side effects, such as a deploy, to manual use only.

From a tooling point of view, a good skill looks like a good CLI command: one job, a clear name, explicit inputs, and a defined finish line such as "tests pass and the diff is summarised".

4. MCP servers for scoped tool access

The Model Context Protocol is an open standard for connecting AI applications to outside tools and data. Servers expose tools, resources and prompts; the agent's host application connects to them. Typical uses in a web team are an issue tracker, read access to error monitoring, documentation search and a browser for testing the running app.

The specification is blunt about the risk: tools represent arbitrary code execution, tool descriptions should be treated as untrusted unless they come from a trusted server, and hosts must obtain explicit user consent before invoking any tool. In Claude Code, project-scoped servers live in a .mcp.json file checked into version control, and the documentation says Claude Code asks for approval in interactive sessions before using them, while non-interactive runs load them without asking. It also warns that servers fetching external content can expose you to prompt injection. Our rule: add a server only when there is a specific job for it, prefer read-only access, and give it its own narrowly scoped credentials.

5. Tests and CI as the verification loop

An agent without a way to check its work produces plausible code; an agent with fast tests produces verified code. The AGENTS.md site notes that agents will try to run the checks listed in the file and fix failures before finishing. That only works if the commands exist, run quickly and are documented. We recommend a single command for the fast loop (type check, lint, unit tests) that finishes in well under a minute, plus the full CI suite on every pull request. How that CI fits into the day-to-day Git workflow is covered in our modern web development workflow guide.

6. Sandboxes and worktrees

Isolation answers two questions: what can the agent damage, and can two agents work without colliding? Git worktrees give each agent session its own checkout on its own branch, so parallel tasks never edit the same files. Sandboxes limit what shell commands can reach. Anthropic describes Claude Code's sandbox as OS-level enforcement on shell commands' filesystem and network access, and recommends using it alongside permission rules for defence in depth, because sandbox restrictions still apply even if a prompt injection bypasses the agent's own judgement. Hosted agents provide their own isolation: GitHub says Copilot's cloud agent can push only to a single branch and restricts its internet access by default with a firewall.

7. Scoped tool permissions

Permissions are where "please don't" becomes "can't". In Claude Code, rules in .claude/settings.json can allow, ask or deny specific tools and command patterns, and the documentation says they are evaluated deny first, then ask, then allow, so an allow rule cannot carve an exception out of a deny rule. A sensible starting point is to deny reading secret files such as .env, deny production deploy and database commands, ask before network calls and installs, and allow the read-only commands and test runner you trust. Commit the shared rules so every developer and every CI run gets the same boundary.

8. Human approval before merge

The final control is a person. Protect the main branch, require passing checks and at least one human approval, and make sure the person who asked the agent for the change is not the only reviewer. GitHub builds this into Copilot's cloud agent: the user who asked it to create a pull request cannot approve that pull request, and by default workflows do not run on its changes until someone with write access approves them. What to look for in an AI-written diff is covered in how much AI-generated code should ship.