Profiles look like a simple product feature. Pick “researcher,” “developer,” or “concise writer,” and the agent becomes the version of itself that fits the job.
That is the convenient story. But then the profile also chooses the model, enables tools, changes cost, or changes what the agent can touch. At that point, it is no longer a profile. It's a cleverly disguised preset.
palOMine should treat a profile as a composition boundary instead.
What should a profile describe?
It should describe how the agent approaches work.
Persona gives the role, priorities, and operating stance. Tone controls how that persona communicates. An implementation-focused engineer can use controlled English; a reviewer can be direct without becoming a different agent; a user can make an answer shorter without changing how the runtime executes it.
Those are separate system-prompt fields because they are separate ideas.
A profile should change the agent's approach, not conceal a change to the machine running it.
The distinction looks fussy until someone needs to explain a run. If a response is terse, the answer should be “the selected tone.” If it is slow or expensive, the answer should be “the resolved model.” A configuration system that makes those answers ambiguous is already failing its operator.
Why is one profile object not enough?
One object is fine. One undifferentiated blob is not.
A profile can contain separate fields for persona, tone, and an optional model preference. The point is not to scatter configuration. The point is to retain the meaning of each field as the product grows.
That changes ordinary editing semantics too. If a profile update omits tone, the user did not change it. If it sets tone to an empty value, the user asked to remove their override and return to the default. Those are different intentions and the API must preserve the difference.
Likewise, a named profile with no explicit custom fields is still a profile. It selects defaults and has a stable identity. Inferring that it is inactive because its configuration happens to be empty makes the system's state depend on implementation detail rather than user intent.
Can a profile prefer a model?
Sure, but we better know about it.
A research profile may prefer a stronger reasoning model. A low-latency profile may prefer a local one. Those are useful requests. They become runtime selection only when the session and configured policy resolve them:
explicit session model > profile preference > configured defaultThe admitted run should record which model won and why. If the preferred model is unavailable, the system can use the next permitted option and say so, or stop. It should not quietly substitute a different runtime while claiming the same profile is active.
This is the important division: profiles express intent; the runtime resolves execution.
What does this buy us?
It makes profiles safe to evolve. A new tone does not reopen the model policy. A model outage does not corrupt a user's working style. An operator can revise tool policy without changing every profile. And when something goes wrong, the system has a small, intelligible causal chain instead of one convenient label that hides several independent choices.
The next boundary follows naturally. A profile may recommend an approach, but it must not grant permission to execute it. Preferences are about the work the user wants. Permissions are about the blast radius the system will accept.
Previous: Discovery Is Not Enrollment
Next: A Preference Is Not Permission
The one-line version
A profile is a composition of visible behavioral choices; it is not a preset that silently redefines the runtime.