Conversation
First draft covering the introductory material and user journeys: record-level registry for AI agents with Agent/AgentVersion entities, composition (BOM) with definitional anchors, A2A card as canonical-when-present payload, protocol-typed access bindings, and agent-centric traces and evaluations via a new trace destination. Detailed design and later sections are TBD. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Plugins are referenced as composed units and expand through their RFC-0008-recorded members for cross-registry queries, so blast-radius lookups find agents that consume a skill via a plugin. Previously held as an open question; resolved by team direction and confirmed by the registry UI prototype's "Link plugin" flow. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Source provenance now covers Git repos, OCI images, and archives via the typed source pointers RFC-0008 defines, matching how agents are actually distributed, instead of Git-only. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Agent versions are registry-minted serial numbers, per the policy from the earlier registries: adopt the artifact's inherent version when its format defines one, mint serial numbers when it does not. No standard agent artifact defines one; an A2A card's provider-defined version string is preserved as metadata, not adopted as identity. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
A version's source provenance is now a list of typed pointers, so an
agent built from a Git repo and shipped as an OCI image records both,
and source entries join the queryable axes ("which agents ship image
X?"). Deliberate divergence from RFC-0008's one-source-per-version
rule, with the rationale (agents have no content digest to reconcile
per-source duplicates) stated in Open questions.
Prompted by Ann Marie's review question.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
An Agent chooses its version scheme at creation: monotonic (registry-assigned serial numbers, the default when no version is supplied), semver, or freeform, with possible autodetection from the first registration. Keeps the simple path as simple as the Skill Registry while letting provider-versioned agents keep their own versioning. Proposed by Matthew Prahl in review discussion. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The agent's endpoint is the card's system of record: registration imports descriptive metadata (card name seeds display_name) and creates the a2a binding, the UI renders the card read-only by fetching through the binding, and no card payload is persisted. This deliberately departs from the RFC-0004/0008 canonical-payload pattern. Endpoint-only registrations become interface-only records with no definitional anchor, marked as such. The canonicity open question is replaced by whether registration and lifecycle events should capture card copies as audit evidence. Direction from design-doc review comments, confirmed by Bill. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Both evaluate sketches now pass agent_version alongside agent_id; version-to-version eval comparison (J3) needs the version captured at evaluation time. From design-doc review feedback. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The case for capturing card copies as decision evidence was weak: no customer signal, promotion decisions rest on eval evidence, and registration already imports the card's claim surface into registry fields. The open question is now solely about how thin an interface-only record may be. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Two sentences in the versioning journey: the choice is the same judgment developers make for any software, the registry enforces no rule, and the consequence is that version comparison exists only within one agent. From design-doc review discussion. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
| destination today, and evaluation and trace-search APIs gain agent | ||
| identity alongside experiment identity. Traces and eval results | ||
| appear on the agent's registry page, filterable by version. The | ||
| change is additive: under the hood an agent owns a default |
There was a problem hiding this comment.
I believe you want a default experiment per agent-version rather than a default experiment per agent.
There was a problem hiding this comment.
This is now an explicit open question in the draft ("Is the default experiment per agent or per agent-version?") with both positions stated; reviewer input is welcome. The draft's current position is per agent: the version is recorded on every trace and evaluation run as metadata, so per-version filtering and comparison work within one experiment, and monitoring an agent's behavior across upgrades stays in one place. Whichever default is chosen, users who want the other behavior can override it per deployment, so the open question is which default serves most users best.
(From Bill Murdock with assistance with Claude Code.)
| the cause, cross-referencing the BOM diff from the previous | ||
| journey. | ||
|
|
||
| Backward compatibility is preserved by construction: an agent owns a |
There was a problem hiding this comment.
Here again it would be a default experiment ID per agent-version rather than per agent. The version would be a required argument for this to work.
There was a problem hiding this comment.
Same resolution as the thread above: this is now an open question in the draft with both positions stated. One note on "the version would be a required argument": that requirement is specific to the per-version model, and it is part of the cost weighed in the open question. Under the draft's current per-agent position, the destination resolves from the agent alone, and the version is a label recorded on traces and evaluation runs rather than an input to destination resolution; the latest draft spells out that separation in the trace journey.
(From Bill Murdock with assistance from Claude Code.)
| to that experiment's ID. Where MLflow already accepts a typed | ||
| destination or location (trace destinations, `search_traces` | ||
| locations), agent identity becomes a new accepted value; where it | ||
| does not (`evaluate`), `agent_id` is new, optional surface. Existing |
There was a problem hiding this comment.
The agent_id and agent_version constitutes two values where you used to pass one value, so you can't just pass an agent_id and silently map it to the experiment_id. I think this will probably require more API changes than this paragraph suggests.
There was a problem hiding this comment.
The latest draft addresses this in two ways. First, destination resolution takes one value: the agent maps to its default experiment, and the version is not part of that mapping (it is recorded on traces and evaluation runs as metadata). Needing both values to resolve a destination is a cost specific to the per-version model, which the new open question weighs. Second, fair point that the API surface was understated: the trace journey now spells out the pieces, including a public get_default_experiment_id lookup that takes only the agent, and the backward-compatibility paragraph is explicit about where agent identity becomes a new accepted value for existing parameters versus where it is new optional surface (evaluate).
(From Bill Murdock with assistance from Claude Code.)
There was a problem hiding this comment.
Thanks. That makes sense, now that everything is consistent.
|
|
||
| - **Should agent-centric traces and evaluations be a separate RFC?** | ||
| The experiments bridge (`agent_id` resolving to a default | ||
| experiment) touches tracing APIs, evaluation APIs, and UI surface |
There was a problem hiding this comment.
agent_id + agent_version resolving to a default experiment...
There was a problem hiding this comment.
The granularity of that mapping is now its own open question ("Is the default experiment per agent or per agent-version?") with both positions stated. The sentence here describes the draft's current per-agent position and would change if the per-version position wins out.
(From Bill Murdock with assistance from Claude Code.)
| scorers=[correctness_scorer], | ||
| agent_id="acme/billing-agent", | ||
| agent_version=3) | ||
| ``` |
There was a problem hiding this comment.
Here as well, I recommend keeping the experiment ID lookup separate rather than bundling it into one convenience API.
There was a problem hiding this comment.
Same resolution as the sibling thread: the lookup is now a public API, and the convenience wrapper is documented as exactly that lookup plus the metadata recording, so the two remain separable.
(From Bill Murdock with assistance from Claude Code.)
The journey no longer claims the diff reveals what broke and then
walks it back. The investigator is framed from the start as someone
other than the change author, the diff is a shared record of
declared changes ("what differs in the declarations for two
versions"), and it gives an investigation its starting facts rather
than answers. From design-doc review discussion.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
New J3 paragraph: the default experiment is a default, not a router. Deployments log wherever their own configuration points; scale-out replicas aggregate by sharing config; deployments needing separation override the destination (destinations, not tags, because permissions are experiment-scoped). Proposes, as not yet settled, that such deployments notify the registry so the experiment ID is recorded on their access binding. Sync bullet gains trace-location link upkeep. From the deployment/experiment-mapping review discussions. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
One sentence in the J3 deployment paragraph: a version is an analysis dimension recorded on every trace, not an access boundary, and per-version experiments would break the longitudinal view across upgrades. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The RFC keeps its per-agent position but now acknowledges the fork as an open question with both sides stated, since a reviewer holds the per-version position and the author is not settled. Whichever default is chosen, the other camp overrides per deployment, so the question is which behavior makes the better default. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The API sketches implied the version participates in choosing the default experiment. Now stated explicitly in the Summary, basic example, and trace journey: a destination identifies the agent only and resolves to its one default experiment; the version is recorded on every trace and evaluation run as metadata. set_active_agent is defined as convenience over two separable pieces, with get_default_experiment_id exposed as a public agent-only lookup (partially adopting Ann Marie's two-call review suggestion), and deployment overrides swap only the destination piece. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Cut redundancy that accreted across incremental revisions: rules stated in multiple places (server-never-fetches, card-not-persisted, default-experiment mechanics) now appear once where they matter most, the blast-radius rationale is consolidated, and digressions are trimmed. No design content changed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The Summary is now a summary: opening, lineage, a one-paragraph tour of the positions, and RFC relationships. The full position statements move intact to a Design positions subsection under Detailed design, where they seed the eventual full design. No content changed beyond the pointer sentences. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This comment was marked as duplicate.
This comment was marked as duplicate.
Sorry, something went wrong.
aakankshaduggal
left a comment
aakankshaduggal
left a comment
There was a problem hiding this comment.
Two inline comments on BOM coverage — asking whether these are RFC-scope or could be deferred.
Generated using Claude Code under Aakanksha's supervision.
| otherwise. Alternatives include structured | ||
| `{registry, name, version}` objects. Relatedly: should the BOM | ||
| also be able to reference other agents, to represent multi-agent | ||
| systems? |
There was a problem hiding this comment.
On the open question about agent-to-agent BOM references: curious whether this could be deferred as an implementation detail rather than an RFC-level concern.
The blast-radius journey assumes the BOM captures meaningful dependencies, but agent-to-agent delegation (especially via A2A) is arguably the highest-impact dependency an agent can have. Without an agents axis, search_agent_versions can't answer "which agents delegate to the compromised one?"
Could a lightweight agents soft-reference axis (same pattern as the other BOM axes) close this gap, or does this need its own design treatment?
There was a problem hiding this comment.
Yes, this seems like a good idea, so I made these updates: the draft has an agents BOM axis following the soft-reference pattern, so the blast-radius query can answer 'which agents call the compromised agent?' One departure from the other axes: the version pin depends on who controls the callee. Agents versioned and deployed together as one application pin each other's versions; a reference to an independently managed agent (another team's, a vendor's) is name-level, since the referencing team does not control which version is live.
(From Bill Murdock with assistance from Claude Code.)
| - **AgentVersion**: an immutable snapshot of the agent's composition, | ||
| its **bill of materials (BOM)**: skill references, agent plugin | ||
| references (a plugin is referenced as a composed unit and expands | ||
| through its registered members for queries), MCP server |
There was a problem hiding this comment.
The BOM references agent plugins and Journey 6 describes expanding through plugin members for blast-radius queries. Under merged RFC-0008, plugin membership is skills-only — MCP server and subagent membership requires RFC-0010 (PR #27).
Is this worth noting as a dependency, or is the plugin expansion behavior an implementation detail that doesn't need to be settled here?
There was a problem hiding this comment.
Worth noting, and the draft now notes it: the blast-radius journey scopes plugin expansion to the member types plugin versions actually record, which today means skill members per RFC-0008, with MCP server and subagent members extending it as RFC-0010 lands. The expansion mechanics themselves stay in detailed design, but the dependency is real and the text no longer implies more than merged RFC-0008 provides.
(From Bill Murdock with assistance from Claude Code.)
| There is no user source repository: the agent is the harness plus | ||
| its configuration, so the configuration snapshot serves as the | ||
| definitional anchor. `config_snapshot` names a file or directory on | ||
| the caller's local disk; the client reads it and uploads the |
There was a problem hiding this comment.
How does this get uploaded if MLflow is not serving artifacts and the agent is not associated with an experiment to inherit its artifact location?
There was a problem hiding this comment.
Good question, and it goes away with the change above: nothing is uploaded on the harness path anymore. Where a registrant does choose the mlflow source type, the skill registry's existing rule applies (supported only in deployments where MLflow serves artifacts), so the artifact-location question is answered the same way it is for skills.
(From Bill Murdock with assistance from Claude Code.)
| skills=["skills:/runbook-triage/2"], | ||
| mcp_servers=["mcp-servers:/acme.internal/pagerduty/1.2.0"], | ||
| models=["claude-sonnet-5"], | ||
| config_snapshot="./opencode.json", |
There was a problem hiding this comment.
Could we remove this and just rely on Git, zip, and OCI? I'm worried about Mlflow suddenly being a arbitrary packaging system and potentially secrets management...
There was a problem hiding this comment.
Yes, I agree, so I made this change: configuration snapshots are gone. A harness-based agent's configuration is now its source, referenced through the same typed source pointers the skill registry uses (git, oci, zip, and the existing mlflow artifact-storage type, which the skill registry already gates to deployments that serve artifacts). MLflow points at configuration rather than becoming its home, and secrets custody stays wherever the configuration lives.
(From Bill Murdock with assistance from Claude Code.)
| mlflow.genai.register_agent( | ||
| name="acme/oncall-helper", | ||
| description="On-call assistant run in OpenCode.", | ||
| harness="opencode", |
There was a problem hiding this comment.
Could we rename this to runtime? I worry that harness is too limiting.
There was a problem hiding this comment.
I think the concern behind this is right, but I went a different way than renaming. 'Runtime' collides with vocabulary this RFC already leans on for the other side of the record/runtime boundary (runtime state belongs to the serving platform), so naming a BOM axis 'runtime' would muddy sentences like 'the registry stores no runtime state'. I kept 'harness' because the skill tracing proposal defines it precisely (a packaged application you install things into, as opposed to a framework your code builds on). To address 'too limiting', I added the other half: an optional framework axis for agents built on a library such as LangGraph, so both kinds of thing-that-runs-the-agent are recorded. Does that cover what you had in mind?
(From Bill Murdock with assistance from Claude Code.)
| mlflow.genai.register_agent( | ||
| name="acme/oncall-helper", | ||
| description="On-call assistant run in OpenCode.", | ||
| harness="opencode", |
There was a problem hiding this comment.
I worry about this being entirely free form and getting variations of spelling of the same meaning. Could we have a hybrid approach where if it's a variation of a well known harness or framework like OpenCode or open-code we can reject it? Alternatively, we can add a concept of available harnesses at the workspace level (common ones preenabled) and this becomes an enum.
There was a problem hiding this comment.
Yes, good point, so I changed this: harness and framework values now come from a set of well-known identifiers shipped with MLflow, plus an 'other' value with a free-text name as the escape hatch, the same shape as the binding protocol field. Well-known values cannot fragment; only 'other' entries can, which is the escape hatch's job. A workspace-configurable list would be a reasonable refinement if release-managed extension turns out too slow.
(From Bill Murdock with assistance from Claude Code.)
| results should surface them alongside matches: "3 agents declare | ||
| the compromised skill; 12 more have undeclared composition." | ||
|
|
||
| ## Out of scope |
There was a problem hiding this comment.
Could we add a new command such as uvx mlflow@latest agent register (already an existing uvx mlflow@latest agent setup) that scans the source code and registers the skills, MCP registries, and agent? Then it'd add the MLflow lock files/coordinates files.
There was a problem hiding this comment.
That seems like it could be its own smaller RFC, couldn’t it?
There was a problem hiding this comment.
I think it could be kept at a high level here. No need for implementation details.
There was a problem hiding this comment.
Yes, good idea, and I agree with Matt that a simple version belongs in this RFC, so I brought it into scope as a third registration path (alongside manual and from-a-card), kept at journey level: mlflow agent register, run from the source tree, scans, proposes a BOM for review, registers unmatched skills and MCP servers on the spot through the existing import and create paths, registers the agent and version with the tree's Git commit as the source pointer, and writes a coordinates file back into the tree; the harness example now shows it. Two things are deliberately left out of this RFC: the scan is exact only for what MLflow itself wrote (the skills lock file and skills:/, prompts:/, models:/, and mcp-servers:/ references in code or configuration) and best-effort through per-harness adapters for harness-native configuration, so its precision for skills depends on the resolution lock the skill registry work defers to a separate RFC, and the coordinates file's format is specified there. Ann Marie's point stands, though: if the consensus is that even the high-level version should be its own RFC, I'd be fine dropping it from this one. (From Bill Murdock with assistance from Claude Code.)
| - **Automated notifications.** The blast-radius journey ends with the | ||
| registry naming owners; notifying them is left to the organization | ||
| in the MVP. | ||
| - **Agent-to-agent runtime discovery.** A programmatic "find me an |
There was a problem hiding this comment.
Doesn't an A2A access endpoint do this though? The agent can search for agents with A2A and grab the URL and continue.
There was a problem hiding this comment.
You're right, and the bullet claimed too much, so I rewrote it. Searching the registry and following an a2a or mcp binding to a live endpoint is in scope; the protocol then describes the rest (the Agent Card in one case, the MCP handshake in the other), and the binding journey now says so. What stays out is the runtime half: routing requests, choosing among live instances by health or load, and mediating authentication. (From Bill Murdock with assistance from Claude Code.)
|
|
||
| **The registry is record-level, not runtime-aware.** It stores what | ||
| an agent is, not whether it is running, healthy, or scaled. Runtime | ||
| state belongs to the serving platform, which can join its own |
There was a problem hiding this comment.
Have you considered at least storing an agent's capabilities if the agent was registered via an A2A card?
There was a problem hiding this comment.
Yes, that was already the intent, and your comment showed the text was not saying it, so I made it precise. Registering from a card stores three things in registry fields: the description, the free-form name (which seeds the display name), and the card's skills list with its tags, which is what lets an agent be searched for by what it does. Only the card as a document is fetched rather than stored. I also replaced 'capabilities' with 'skills list' throughout, since in A2A 'capabilities' is the small protocol-features object while 'skills' is what the agent can do, and added a sentence that A2A skills are not Skill Registry entries. (From Bill Murdock with assistance from Claude Code.)
| ("which agents use skill X?") answerable as registry queries | ||
| without constraining registration order. | ||
|
|
||
| **The BOM is a component inventory, not a complete recipe.** Its |
There was a problem hiding this comment.
Let's just make sure we have an API that exports the agent's BOM as JSON. In other words, just the agent definition but with the skills, MCP servers, prompts, and models all resolved, not pointers. This could be useful for other systems integrating with MLflow.
There was a problem hiding this comment.
Agreed, so I added it as a design position: any version's BOM can be fetched as a JSON document in resolved form, with each reference that matches a registry entry expanded to that entry's record, unmatched references kept as pointers and marked unresolved, aliases pinned to the concrete version with the resolution time recorded, plugins expanded to their members, and called agents resolved one level. It is exposed as an option on fetching a version in the SDK and REST API, and it is the same document the new scan-and-register command writes back into a source tree. (From Bill Murdock with assistance from Claude Code.)
| the live card from the endpoint's well-known path, and the registry | ||
| follows suit. Registering from an endpoint imports the card's | ||
| descriptive metadata (description, capabilities, and its free-form | ||
| name, which seeds the mutable MLflow-managed `display_name`) into |
There was a problem hiding this comment.
Do we want display name here? I think @B-Step62 had objections to that for skill registry.
There was a problem hiding this comment.
I kept it, and added the reasoning to the draft, because I think the skill registry argument does not carry over. Yuki's point there was that a raw skill name is already human-readable, and I agree, but that is because a skill name is a slash command users type, so whoever names a skill is naming something for humans. An agent's identity has no such guarantee: it comes from an A2A or MCP protocol name, or from an endpoint path that may be named for a purpose, an operation, or both. So agents need a display name more than skills do, and keeping it also matches the MCP registry implementation, which has one. (From Bill Murdock with assistance from Claude Code.)
| generally), and recording that URL lets the registry drive tracing | ||
| and evaluation for agents whose code the user cannot run. But | ||
| endpoints change independently of composition, and agent versions | ||
| are immutable. Following RFC-0004's `MCPAccessBinding` model, |
There was a problem hiding this comment.
This was renamed to "access endpoint" right?
There was a problem hiding this comment.
Yes, in the implementation (MCPAccessEndpoint, access_endpoints), so I switched the draft to 'access endpoint' throughout and made the SDK sketch create_agent_access_endpoint. One thing worth knowing: the MCP registry RFC's text was never amended, so it still says MCPAccessBinding everywhere; the draft notes that discrepancy where it cites the model. (From Bill Murdock with assistance from Claude Code.)
| per deployment, so the question is which behavior makes the better | ||
| default, not which is possible. | ||
|
|
||
| - **How thin may an interface-only record be?** A black-box A2A |
There was a problem hiding this comment.
I think as thin as possible but encourage a description so there is some human/agent readable field for what this agent is.
There was a problem hiding this comment.
Agreed, and a description is already required on every registration, so your condition is met. I closed the question by stating the position: an interface-only record is name, description, and endpoint, and nothing more is required to promote it to active, since whether a black-box agent is fit for use is a judgment the new vetting journey's evaluations inform rather than a schema gate. (From Bill Murdock with assistance from Claude Code.)
| should the registry require anything more of it before such a | ||
| record can be promoted to `active`? | ||
|
|
||
| - **Should agent-centric traces and evaluations be a separate RFC?** |
There was a problem hiding this comment.
Agreed, so I removed the question. Since the draft now makes the agent the entity GenAI users create, the traces and evaluations journey is the core of the RFC rather than a candidate for splitting off. (From Bill Murdock with assistance from Claude Code.)
| prefer a narrower registry RFC, the journey splits cleanly along | ||
| the RFC-0008/0009 seam. | ||
|
|
||
| - **Do endpoint records belong in MLflow at all?** The access binding |
There was a problem hiding this comment.
I'd like MLflow to be the glue for all different systems that define and serve agents. MLflow should be an authoritative source but a pointer to them like the A2A endpoint. Making this more customizable without persisting runtime data makes MLflow very valuable here.
There was a problem hiding this comment.
Thanks, that is a better statement of the position than the draft had, so I adopted it: the endpoint design position now says the registry is authoritative about which agents exist and where each is reached, while the systems that define and serve them stay authoritative about running them, with no runtime state persisted. With that, I closed the open question. (From Bill Murdock with assistance from Claude Code.)
| answers there" belongs to the platform, and that without endpoints | ||
| the registry cannot trace or evaluate agents whose code the user | ||
| cannot run. This boundary needs explicit review. A related | ||
| sub-question: when an agent is exposed as an MCP server, should an |
There was a problem hiding this comment.
Agreed, so I recorded it as out of scope for now: an agent exposed as an MCP server records its mcp endpoint on its own record, the same server may also be registered in the MCP Server Registry, and nothing links the two, with linking noted as a possible later addition if the duplication turns out to matter. (From Bill Murdock with assistance from Claude Code.)
| them, going beyond the source-centric design the journeys otherwise | ||
| follow: a harness reference axis in the BOM (an external | ||
| identifier, like external model references), an immutable | ||
| configuration snapshot stored as a version artifact to serve as the |
There was a problem hiding this comment.
As mentioned in a previous comment, I think this configuration is better stored in Git or another external system and not MLflow.
There was a problem hiding this comment.
Agreed, and I changed the draft accordingly: configuration is pointed at rather than uploaded, with Git as the expected common case; details in the reply on the harness example.
(From Bill Murdock with assistance from Claude Code.)
| - Does configuration-as-artifact belong in this RFC or a | ||
| follow-on? | ||
|
|
||
| - **Should a version record multiple sources?** This RFC says yes: a |
There was a problem hiding this comment.
Noted; that sub-question went away when configuration snapshots were replaced by source pointers (see the harness example thread).
(From Bill Murdock with assistance from Claude Code.)
Blast-radius expansion through plugin members covers what plugin versions record: skill members today, with more member types arriving via the extended agent plugins proposal. From review feedback. Numeric RFC cross-references avoided in new text pending the numbering-scheme clarification. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Agents an agent calls are now a BOM axis: pinned to a version when the referencing team controls the callee's deployment (agents versioned and deployed together as one application), name-level when the callee is independently managed. Blast radius gains "which agents call the compromised agent?". The trace journey states the convention for calls: annotated at the call site with the callee's identity; in-process callees nest in the caller's trace, remote callees produce linked traces. Replaces the multi-agent open sub-question. From review feedback. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Configuration snapshots are removed. A harness-based agent's configuration is now its source, referenced through any of the Skill Registry's source types (git, oci, zip, or mlflow artifact storage where the deployment serves artifacts) rather than uploaded by the registry. MLflow points at configuration instead of holding it, secrets custody stays where the configuration lives, and the harness open question loses two sub-questions. From review feedback. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Overrides remain (separate audiences need separate experiments), and discoverability is handled by rule rather than proposal: each agent has a registered set of trace locations (its fixed default experiment plus any a deployment registers when it overrides), the agent's page searches across them, and overriding deployments must register their location. The default is never re-pointed. Adds the OpenTelemetry export-header convention for agent identity. From review feedback. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Re-pointing the default would be redundant with the override mechanism, so trace locations are added rather than moved. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
What runs an agent is now recorded as either a harness reference (packaged application) or a framework reference (agent framework), each with a version. Values come from a set of well-known identifiers shipped with MLflow plus an "other" escape hatch with a free-text name, the same shape as the binding protocol field, so spelling variants cannot fragment queries. Resolves two harness open-question sub-questions. From review feedback. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Adopts the bolder positioning from review: for GenAI work an agent, not an experiment, is what users create and trace against, with experiments continuing for model training and, underneath, as the storage and permission unit. Mechanics stay additive. Multi-audience isolation is expressed as trace locations per deployment of the agent rather than as experiment overrides, with set_active_agent(..., deployment=...) resolving to a deployment's location. Renames the sketched destination type to MlflowAgentTraceLocation to avoid confusion with an agent's endpoint. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…ney, card fields Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
4 participants
First draft of RFC-0011: Agent Registry, a follow-on to RFC-0004 (MCP Server Registry) and RFC-0008 (Skill Registry).
This draft deliberately covers only the introductory material and user journeys, in the style of the RFC-0009 and RFC-0010 drafts (#37, #27). Detailed design, drawbacks, alternatives, and adoption strategy are TBD.
What the draft contains:
AgentandAgentVersionentities. Each version snapshots a composition (BOM: skill, MCP server, model, and proposed harness references) plus at least one definitional anchor (source provenance, configuration snapshot, or A2A Agent Card).MCPAccessBinding) carrying a URL plus protocol (a2a,mcp,other), never fields on immutable versions.MlflowAgentLocationtrace destination), lifecycle management, and cross-registry blast-radius queries.Authored by Bill Murdock with assistance from Claude Code.
🤖 Generated with Claude Code