What problem are you trying to solve?
eve currently makes authors choose between two bundled subagent shapes:
- The built-in
agent is a copy. It shares the parent's live sandbox, tools, connections, and instructions.
- A declared subagent can have different instructions, but it inherits none of the parent's authored slots. It receives its own sandbox and its own connection set.
That prevents a common orchestrator and reviewer design. A GitHub channel checks the repository out in the root sandbox, then delegates review to specialists with different prompts. Declared reviewers have the right prompts but cannot see that checkout or use the root's GitHub connection. Built-in copies can see the repository and credentials but cannot have reviewer-specific instructions.
The isolation is intentional and documented in the subagent slot table. Runtime input only shares parent sandbox state for the built-in agent copy (source). There is no opt-in middle ground.
Proposed solution
Allow a declared subagent to opt into selected capabilities from its immediate parent while retaining its own instructions and other authored slots. For example:
export default defineAgent({
description: "Review this change for security risks.",
inherit: {
sandbox: true,
connections: true,
},
});The exact syntax is open. Inheritance must remain explicit and per capability.
Required behavior:
- Declared subagents remain isolated by default.
- Authors can independently share at least the parent's live sandbox and connection definitions. Sharing either one does not implicitly share instructions, tools, skills, hooks, state, channels, or schedules.
- A shared sandbox is the same live filesystem session, not a copied seed or a second checkout. Parent and child writes become mutually visible, with concurrent-write guidance matching the built-in
agent contract.
- Shared connections reuse eve's normal auth resolution, approval rules, and current-session principal. Credentials must not be copied into prompts, durable JSON, or sandbox files.
- The child keeps its own
instructions.md and identity. It can still narrow its own tools and skills.
- Nested inheritance resolves from the immediate parent and has documented behavior when the parent already inherited a capability.
- Invalid or unsupported combinations fail at build time.
eve info shows each effective capability and whether it is owned or inherited.
- Security documentation calls out the larger trust boundary created by sandbox or connection sharing.
- Tests prove that a declared reviewer with distinct instructions can read a repository checked out by the GitHub channel and use an inherited connection. A control test proves the default isolated reviewer cannot.
Alternatives considered
- Use the built-in
agent copy. It shares everything, including the orchestrator's instructions, so it cannot define a distinct reviewer role.
- Duplicate sandbox and connection definitions under every reviewer. This creates separate workspaces, repeats configuration, and lets auth policy drift.
- Put repository contents or credentials in the subagent message. That is incomplete for real repositories and violates the capability boundary.
Related: #592 proposes shared defaults and connections in a fleet file, but the directory-based declared-subagent runtime still needs an explicit composition model.
What problem are you trying to solve?
eve currently makes authors choose between two bundled subagent shapes:
agentis a copy. It shares the parent's live sandbox, tools, connections, and instructions.That prevents a common orchestrator and reviewer design. A GitHub channel checks the repository out in the root sandbox, then delegates review to specialists with different prompts. Declared reviewers have the right prompts but cannot see that checkout or use the root's GitHub connection. Built-in copies can see the repository and credentials but cannot have reviewer-specific instructions.
The isolation is intentional and documented in the subagent slot table. Runtime input only shares parent sandbox state for the built-in
agentcopy (source). There is no opt-in middle ground.Proposed solution
Allow a declared subagent to opt into selected capabilities from its immediate parent while retaining its own instructions and other authored slots. For example:
The exact syntax is open. Inheritance must remain explicit and per capability.
Required behavior:
agentcontract.instructions.mdand identity. It can still narrow its own tools and skills.eve infoshows each effective capability and whether it is owned or inherited.Alternatives considered
agentcopy. It shares everything, including the orchestrator's instructions, so it cannot define a distinct reviewer role.Related: #592 proposes shared defaults and connections in a fleet file, but the directory-based declared-subagent runtime still needs an explicit composition model.