[codyhartsook]

Description

Builds on #3604, which lets references name a group and kind but resolves only the built-in kinds. app.Options.ReferenceKinds lets an embedding controller register more, each as a collection of its objects projected to RemoteMCPServer or ModelConfig. With example.com/ToolServer registered, a template can name one:

tools:
- mcp:
    server: {group: example.com, kind: ToolServer, name: search}

server	Resolves to
{name: search}	The RemoteMCPServer named search, as today
{group: example.com, kind: ToolServer, name: search}	The registered ToolServer named search, projected to a RemoteMCPServer
Any other kind	InvalidKind, as today

Compilers, egress and revisions only see the projected object, and provenance records ToolServer because the projection sets TypeMeta. Registering a built-in kind fails at startup. It's a callback because the collections need kagent's kube client and krt options, which exist only inside Run.

How a registered kind resolves

flowchart LR
    embedder["Embedding controller"] -->|ReferenceKinds| runtime["NewRuntime"]
    runtime -->|collections by group and kind| fetch["fetchModel / fetchMCPServer"]
    template["AgentTemplate reference"] -->|group, kind, name| fetch
    fetch -->|built-in kind| builtin["Built-in collection"]
    fetch -->|registered kind| projected["Projected collection"]
    fetch -->|other kind| invalid["InvalidKind"]
    builtin --> compile["Compilers, egress, revisions"]
    projected --> compile

Loading

Change Type

/kind feature

Changelog

Controllers that embed kagent can register their own model and MCP server kinds for references through `app.Options.ReferenceKinds`.

Validation

• make lint, and the translator and controller suites, including envtest.
• New tests cover registered MCP server and model kinds, their provenance, and the built-in key check.

[shashankram]

Different MCP kinds with the same namespace/name produce identical runtime names, causing Codex and Claude compilation to fail. This needs to distinguish registered kinds while preserving built-in names.

[shashankram]

these updates do not belong to the cross-namespace-ref arch doc. we can drop the noise

[shashankram]

why do we need to preserve the older ref type through an alias? it's also odd for a generic ObjectReference to alias to a Model specific type

[shashankram]

nit: Move optional fields to the bottom, and deprecated to the very end

[shashankram]

should use a const for status values

[codyhartsook]

Closing for now. Nothing in this repo needs the extension point yet, so the typed references in #3604 stand on their own.