Skip to content

Add first-class model and tools fields to AgentCustomization #286

Description

Summary

A custom agent typically carries two pieces of behavior that AgentCustomization can't represent natively today: a model override (the model the agent runs on) and a tool scope (the tools the agent is allowed to use). Because there's no native field for either, a host has to drop them or stuff them into AgentCustomization._meta. Both are general agent concepts and deserve first-class fields.

Current state in the spec (0.4.0)

AgentCustomization carries id / uri / name / icons / range / description and a generic _meta, but nothing for the agent's model or tool scope. By contrast, RuleCustomization models its behavior with first-class, type-specific fields (alwaysApply, globs) rather than _meta — that's the spec's established style for general, non-vendor concepts.

Proposal

Add to AgentCustomization:

  • model?: string — the model the agent is pinned to (absent ⇒ inherit the session/default model).
  • tools?: … — the agent's tool allowlist / scope. Shape TBD; the simplest is a list of tool names (string[]), but a structured scope (e.g. allow/deny, globs over tool ids) may be worth considering if other consumers want it. Absent ⇒ no restriction beyond the session default.
{
  "id": "",
  "uri": "",
  "name": "",
  "description": "",
  "model": "",            // NEW, optional
  "tools": ["", ""]      // NEW, optional (shape TBD)
}

Why first-class fields, not _meta

A model override and a tool scope are general agent-host concepts, not vendor-specific residue. Routing them through _meta would fragment the same concept across every vendor's _meta namespace and defeat the purpose of having a native AgentCustomization type. _meta should stay reserved for genuinely provider-specific data; a custom agent's model and tools aren't that.

Until these land, AgentCustomization._meta is the legitimate interim carrier — that's what the slot is for. This issue is about giving the data a durable, native home.

Concrete grounding (public, vendor SDK example)

A representative agent SDK already reports both per agent on its discovery event: session.custom_agents_updated agent entries carry model and tools (alongside userInvocable). So the data exists at the source; only the AHP carrier fields are missing.

Backwards compatibility

Both additions are optional, so existing producers and consumers are unaffected until they opt in.

Relationship to other proposals

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions