Should agent behavior be project-scoped or operator-scoped?

I'm starting to think some agent behavior should be operator-scoped, not project-scoped. Project files like CLAUDE.md are useful. Same with repo instructions, system prompts, and MCP-specific configs. But a lot of the behavior I keep repeating is not really about the project. It is about how I want agents to work with me. For example: * when the agent should state intent before acting * what counts as drifting into another task * which operations should always surface * when a read-only exploration has turned into mutation * which tool calls deserve extra scrutiny Those expectations do not really change from repo to repo. But today they often get re-installed into every new project, every new context window, and every new runtime. That feels like the wrong abstraction boundary. Maybe there are two layers: 1. Project instructions: what matters for this codebase or workflow 2. Operator posture: what I expect from any agent working on my machine I've been experimenting with this as a local profile file that gets evaluated at the execution boundary. Not enforcement yet, just flags in a local trace when the agent crosses a declared boundary. Something like: `session_intent: demand_at: first_write` `task_boundary: signals: - dir_change - file_type_shift - read_to_write_transition` `high_consequence: tools: - "Bash:.rm.-rf." - "fs.write:.\.env.*"` The interesting part is not the YAML. The interesting part is the boundary. Should some agent expectations live with the project, or should they live with the operator? Curious how others are thinking about this, especially if you're using multiple runtimes like Claude Code, Cursor, Codex, Windsurf, MCP tools, etc.