Agent profiles are often designed as presets. Pick “researcher,” “developer,” or “concise writer,” and the system changes everything at once: prompt, model, tools, and access.
That feels convenient. It is also how a preference becomes an authority grant.
A user asking for terse answers has expressed a communication preference. They have not asked the system to choose a more expensive model, enable network access, or write files without confirmation. Those are different decisions, owned by different parts of the system.
palOMine should keep them separate.
What is a profile allowed to change?
A profile should describe how the agent approaches work.
That includes persona: the role, priorities, and operating stance used to interpret a request. It includes tone: how the agent communicates. A profile might ask for controlled English, concise answers, a cautious reviewer, or an implementation-focused engineer.
Those choices affect the system prompt. They should be visible, composable, and safe to change without altering runtime behavior.
A model is different. Tools are different. Filesystem and network access are different again.
A profile can influence how work is attempted. It cannot expand what work is authorized.
This is not a naming preference. It is a boundary that keeps ordinary configuration from changing the system's blast radius.
Why not make profiles complete presets?
Because the coupling fails under normal use.
Imagine a profile named research. It begins as a useful bundle: careful reasoning, longer answers, and a preference for a stronger model. Later, someone adds web access because research often needs sources. Then a file-write tool because research produces reports. The profile is still easy to select, but no longer means one thing.
A user chooses a writing style and receives a different authority set. An operator changes a tool policy and changes the behavior of every session using that profile. When a run is slower, more expensive, or unexpectedly mutates a workspace, nobody can tell which setting caused it.
The preset hid complexity. It did not remove it.
Can a profile prefer a model?
Yes, provided “prefer” does not mean “override.”
A profile may say that it normally works best with a particular model. The runtime resolves that preference when a run is admitted:
explicit session model > profile preference > configured defaultThe resolved model and the reason it was chosen should be recorded with the run. If the preferred model is unavailable, the system either selects the next permitted choice and reports the change, or stops.
It must not silently substitute a materially different runtime while claiming the same profile is active.
That is the useful compromise. Profiles express intent. The runtime owns enforcement and leaves evidence of the result.
Where do permissions belong?
Permissions belong with the session and runtime policy. They are evaluated where a request becomes an action, not where a user selects a working style.
This makes the authority path explainable:
profile -> persona + tone -> system prompt
runtime -> model + tool policy -> admitted runThe distinction matters most when the system evolves. A new profile can be introduced without reopening the security model. A new tool can be approved without changing every profile. A user can reset a tone preference without quietly changing the provider, model, or filesystem policy.
That is a system people can reason about when something goes wrong.
The better mental model
Profiles are composition boundaries, not bags of unrelated settings. They describe the agent's intended approach. Runtime policy decides which execution resources and authorities are actually available.
Convenience is still possible. The system can offer sensible defaults and visible recommendations. But recommendations should stay recommendations until the runtime resolves them under an explicit policy.
Previous: Discovery Is Not Enrollment
Next: Least Privilege Is an Operational Decision
The one-line version
A profile may describe how an agent should work, but only runtime policy may decide what the agent is allowed to do.