Four boundaries to set before handing a repository to an AI agent
It is becoming natural to tell an AI agent, “Build this whole feature.” The difficult question is no longer whether the agent can write code. It is whether the team has defined what the agent is allowed to change, what evidence it must provide, and when it must stop.
Good agent use does not begin with a larger prompt. It begins by bounding the work and building a loop in which a human can verify the result.
Workflow and agent are not the same thing
Anthropic distinguishes a workflow that follows predefined code paths from an agent that dynamically directs its own process and tool use. Both are useful, but the risk is different. A workflow is more predictable and less flexible; an agent is more flexible because it makes more decisions.
The common mistake is to give an agent autonomy without the workflow’s contract. “Handle it” is not a goal. The repository needs allowed actions and observable completion evidence.
Boundary one — scope
Give the agent an exit condition, not only a feature name.
This task covers email-form validation only.
Allowed paths: src/auth and its test files.
Done means three tests pass: empty email, malformed email, and valid input.
Do not change the database schema, deployment settings, or dependencies.
Smaller scope reduces how clever the agent needs to be. There are fewer files to roll back, and the human cost of reading the diff stays manageable.
Boundary two — context
An agent is not a teammate who already understands the repository. Give it the rules and examples it needs. Cursor documents project rules in .cursor/rules and offers AGENTS.md as a simpler project-instruction file. The CLI also reads project AGENTS.md and rule files.
I usually start with four short sections:
# AGENTS.md
## Goal
- Make the smallest change that satisfies the request.
## Before editing
- Read the relevant module and tests.
- State the files you plan to change.
## Verification
- Run the narrowest relevant test first.
- Report failures; never hide or bypass them.
## Boundaries
- Do not change secrets, production data, or deployment settings.
- Do not add dependencies without explaining why.
- Stop when the request conflicts with the existing architecture.
A short rule file is not an attempt to predict every situation. It is a checklist for decisions the agent tends to forget.
Boundary three — authority
Rules tell an agent what not to do; they are not operating-system access control. Cursor’s documentation also cautions against treating rules as the only security control.
Separate these in practice:
- code-editing authority from production access
- draft creation from publication authority
- test credentials from production secrets
- read-only research from writes to external systems
With that separation, an agent can create a draft and call a narrow API without having direct database access or the ability to change publication state. This does not remove autonomy; it reduces the blast radius.
Boundary four — verification
“The agent says it is done” is not verification. Turn done into observable evidence.
Define goal
↓
Read relevant files
↓
Make a small change
↓
Run tests and lint
↓
Review diff and side effects
↓
Report done or stop
Tests should not be decoration at the end. If they do not exist, ask the agent to add them or make a manual verification procedure part of the completion contract. Never collapse a failing test into “probably an environment issue”; record what failed and what the next person must decide.
One practical Cursor cycle
For repository work, this sequence is reliable:
- Plan: Ask for proposed files and completion conditions before edits.
- Read: Have the agent inspect the implementation and tests first.
- Edit: Change one small slice at a time.
- Verify: Run the narrow test, then expand to the full check suite.
- Review: Read the diff and remove unrelated changes.
- Stop: Once the contract is met, do not widen the scope for “improvements.”
The last step is surprisingly hard. Agents are good at finding reasons to improve one more thing. In production automation, the best result is not the one that touches the most files; it is the one that satisfies the request with the smallest understandable change.
A senior-engineer view
Teams that use agents well are not teams that skip review because they trust the model. They design the system so humans can cheaply verify changes made quickly by the agent.
That is why I prioritize recoverability over autonomy. Small changes, readable diffs, tests, and separated secrets and publication authority mean a wrong agent turn can be recovered from. A giant prompt that touches code, databases, and deployment at once may succeed, but it becomes hard to explain what actually changed.
FAQ
Is one AGENTS.md enough?
For a small repository or a first step, often yes. Split domain rules into .cursor/rules as the project grows, but never treat them as a security boundary.
Should every task start with a plan?
That is overkill for a one-line fix. Planning and explicit completion conditions pay off when several files, data changes, or external APIs are involved.
Should an agent be allowed to run tests?
It depends on the repository and execution environment. Test execution should not automatically imply permission to deploy or change production data.
What should I do first?
Write one sentence for the success condition and one for the allowed change area. Good boundaries often help before a better model does.
Closing
Agents are moving from code-typing tools toward partners that plan, act, observe, and adjust. The key question is not how much we can hand over. It is where the work stops and how we verify it.
In your next Cursor task, add just four lines to AGENTS.md: goal, scope, verification, and stop condition. The most realistic test of an agent is not asking it to do something bigger. It is making a small task reproducible.