Always / Ask First / Never
When an AI agent carries out work, it is not enough to tell it what to build. You also have to tell it what boundaries it must respect.
Always / Ask First / Never organizes those boundaries into three categories.
Structure
| Category | Meaning | Example |
|---|---|---|
| Always | Rules the agent must always comply with. | "Always run tests before proposing the task as done." |
| Ask First | Actions that require prior human approval. | "Ask before adding a new dependency." |
| Never | Forbidden actions. | "Never modify migration files already applied in production." |
What it is for
It is useful for:
- reduce implicit decisions;
- protect architecture;
- prevent dangerous changes;
- limit permissions;
- make review clearer;
- improve human-AI collaboration;
- prevent the agent from "optimizing" something it should not have touched.
Example in SDD
Always: - Maintain compatibility with the existing public API. - Add tests for every new behavior. - Use the error patterns defined in the project. Ask First: - Before creating a new dependency. - Before changing the database schema. - Before modifying authentication behavior. Never: - Do not expose secrets in logs. - Do not change public contracts without approval. - Do not delete existing tests to make the suite pass.
Two scopes and evolution
Boundaries operate at two levels. In the project constitution they set the general rules that apply to everything built ("never commit secrets"); in each task they add the specific constraints of that implementation ("do not touch the existing entry points").
This distinction prevents the most common mistake: writing constraints into the constitution that only apply to a single task.
The system is not static. As the team builds trust, something that is Ask First today can move to Always, and something thought to be harmless can move up to Ask First after an incident. This is gradual autonomy, analogous to how more and more is delegated to a professional who demonstrates good judgement.
The format the ecosystem has converged on for writing the project constitution and boundaries is AGENTS.md, an instruction file at the root of the repository that some twenty coding tools read natively and whose specification has been overseen by the Agentic AI Foundation (Linux Foundation) since December 2025. Writing them once in that format avoids maintaining different versions for each tool. The format does not replace judgement: the team decides the content.
Relationship with the Definition of Done
Boundaries can feed the Definition of Done. If an "Always" rule is not met, the work is not done. If a "Never" rule is broken, the change must be rejected or reviewed urgently.
AI and governance
Always / Ask First / Never is a simple AI governance tool. It does not replace technical controls, but it makes explicit the rules that often remain implicit in the team's head.
Common mistake
Writing boundaries that are too generic. "Write clean code" or "be careful with security" are not useful boundaries. A good Always / Ask First / Never rule must be specific, observable, and applicable during review.
Resources
🏦 Harness EngineeringSkill Arena · Scrum Manager
🏦 Scrum in teams with AISkill Arena · Scrum Manager
🏦 SDD - Spec Driven Development in agile teamsSkill Arena · Scrum Manager
📊 SDD teaching guideResources · Scrum Manager
📊 Teaching guide: Scrum in teams with AIResources · Scrum Manager
See also
Want to move forward in agility? You can search for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.