You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
v1 of subagent-as-tool (#165, PR #173) uses a static subagents: block in agent.yaml. This matches the immutable-image model but precludes per-tenant
or runtime-dynamic subagent rosters. This issue adds an opt-in discovery: kagenti mode that resolves the subagent registry from kagenti at startup
(or lazily on first use).
What lands
New discovery field on the subagents: block:
subagents:
discovery: kagenti # or `static` (default)filter:
tenant: ${TENANT_ID}capability: research
KagentiSubagentResolver that calls kagenti's agent-listing API and
populates SubagentConfig entries at setup
Identity scope-down: when identity: service_account: <name> is declared,
the framework looks up the service account from kagenti and issues calls
under that identity (already specced in design doc, gated on this issue)
Static + kagenti coexist: kagenti-discovered subagents merge with any
hard-coded subagents: entries; name collisions are an error
Open design questions
Cold-start dependency. kagenti must be reachable at agent startup for
discovery to work. Do we fail-fast or fall back to static-only?
Refresh. Is the registry frozen at startup, or do we re-resolve on
some interval / event? Frozen is simpler; dynamic is more powerful.
Inprocess identity scope-down (open Q6 from feat: subagent-as-tool — composable agent delegation #165). When transport is inprocess, the subagent inherits the parent process's identity. Should
kagenti-mediated discovery enforce a scope-down even for inprocess
subagents? Likely no — inprocess is a tight-coupling escape hatch — but
document the contract.
Out of scope
Cross-tenant subagent routing (kagenti's job, not the framework's)
A subagent marketplace
Dependencies
kagenti API surface for agent listing + service-account lookup
Summary
v1 of subagent-as-tool (#165, PR #173) uses a static
subagents:block inagent.yaml. This matches the immutable-image model but precludes per-tenantor runtime-dynamic subagent rosters. This issue adds an opt-in
discovery: kagentimode that resolves the subagent registry from kagenti at startup(or lazily on first use).
What lands
New
discoveryfield on thesubagents:block:KagentiSubagentResolverthat calls kagenti's agent-listing API andpopulates
SubagentConfigentries at setupIdentity scope-down: when
identity: service_account: <name>is declared,the framework looks up the service account from kagenti and issues calls
under that identity (already specced in design doc, gated on this issue)
Static + kagenti coexist: kagenti-discovered subagents merge with any
hard-coded
subagents:entries; name collisions are an errorOpen design questions
discovery to work. Do we fail-fast or fall back to static-only?
some interval / event? Frozen is simpler; dynamic is more powerful.
inprocess, the subagent inherits the parent process's identity. Shouldkagenti-mediated discovery enforce a scope-down even for inprocess
subagents? Likely no — inprocess is a tight-coupling escape hatch — but
document the contract.
Out of scope
Dependencies
inherit the right permission ceiling)
Related
planning/subagent-tool-design.md("Static config vs.kagenti-discovered registry" section)