Question
Looking at #3, #4 and #5 together, I think there is an architectural question worth resolving before multi-provider + sub-agent orchestration gets deeper:
What owns the authority of an agent session: the model, the agent, or the workspace/runtime?
For example, imagine a workspace starts with Claude:
Claude
-> can read files
-> can modify src/**
-> cannot access secrets
-> requires approval for shell/network effects
Then the user switches the same running agent/session to GPT or a local model.
Ideally, nothing about the authority should change.
The new model should inherit neither more nor less power simply because the reasoning provider changed.
Likewise with sub-agents: if a manager delegates a task to another model, I don't think the delegated model should implicitly inherit the manager's entire tool surface.
That suggests separating three things that are easy to accidentally couple:
- Reasoning identity — which model/provider is currently producing proposals.
- Agent/session identity — the persistent logical actor/workspace.
- Authority — the capabilities/effects that actor is currently allowed to exercise.
Something roughly like:
model/provider
|
v
agent proposal
|
v
session/workspace authority
|
v
capability check
|
v
tool effect
The model can change above that boundary without changing anything below it.
This also makes manager/sub-agent delegation interesting: delegation could narrow authority for a child task rather than copying the parent's complete tool access.
Is OpenGravity already heading toward a separation like this, or is tool authority currently attached directly to the active agent/model session?
Question
Looking at #3, #4 and #5 together, I think there is an architectural question worth resolving before multi-provider + sub-agent orchestration gets deeper:
What owns the authority of an agent session: the model, the agent, or the workspace/runtime?
For example, imagine a workspace starts with Claude:
Claude
-> can read files
-> can modify src/**
-> cannot access secrets
-> requires approval for shell/network effects
Then the user switches the same running agent/session to GPT or a local model.
Ideally, nothing about the authority should change.
The new model should inherit neither more nor less power simply because the reasoning provider changed.
Likewise with sub-agents: if a manager delegates a task to another model, I don't think the delegated model should implicitly inherit the manager's entire tool surface.
That suggests separating three things that are easy to accidentally couple:
Something roughly like:
model/provider
|
v
agent proposal
|
v
session/workspace authority
|
v
capability check
|
v
tool effect
The model can change above that boundary without changing anything below it.
This also makes manager/sub-agent delegation interesting: delegation could narrow authority for a child task rather than copying the parent's complete tool access.
Is OpenGravity already heading toward a separation like this, or is tool authority currently attached directly to the active agent/model session?