Skip to content

feat: subagent-as-tool — kagenti-driven dynamic registry #180

@rdwj

Description

@rdwj

Summary

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

  1. Cold-start dependency. kagenti must be reachable at agent startup for
    discovery to work. Do we fail-fast or fall back to static-only?
  2. Refresh. Is the registry frozen at startup, or do we re-resolve on
    some interval / event? Frozen is simpler; dynamic is more powerful.
  3. 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

Related

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions