Add RFC-0011: Agent Improvement - #38
Conversation
Trace-aware webhook events (Part 1) and an improvement workflow built on issue detection and a pluggable fix pipeline (Part 2). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
jwm4
left a comment
jwm4
left a comment
There was a problem hiding this comment.
This all seems like a good idea. I have a bunch of comments mostly relating to the illustrative examples and the presentation. But I'm approving it because I think it's fine the way it is to. Personally, I would split this up into two RFCs, but I have no objection to it moving forward as a single RFC.
|
|
||
| **UI path:** both webhooks can also be created in the UI — see the [UI section](#ui) below. | ||
|
|
||
| 2. **The incident.** At 2am, a provider deprecates the model identifier one of the agent's tools uses. Runs start failing, and each failed trace arrives at the server with state `ERROR`. The first one fires the error webhook: |
There was a problem hiding this comment.
This specific example incident seems like not a particularly exciting one, and I don't think it sells the technology very well. Getting an alert because a dependency is unavailable and everything is failing all the time is very mundane technology that's been around for many years. I think a more exciting example would be one where the quality of the results has declined and one of the scores that assesses whether a result is good is able to detect that drop in quality. There are a lot of reasons why an agent quality might suddenly drop at 2 AM even when no change has been made to the agent. So it's probably worth trying to come up with a compelling example here.
| # Open questions | ||
|
|
||
| 1. Should alert rules be configured on each webhook (the smallest change, matching how webhooks work today), or become their own concept that a user defines once and points at several destinations — Slack and PagerDuty from one rule? Compound conditions push strongly toward the latter: an experiment runs multiple scorers, and a team may want to alert only when several conditions hold together or when any one of them does (AND/OR across conditions, each with its own aggregate and window — count-based or time-based). That no longer fits naturally in a single webhook's filter, so the initial proposal keeps single-condition rules and leaves the rule primitive to the detailed design. | ||
| 2. Should an alert also fire when data stops arriving entirely? An agent that produces no traces at all is arguably the worst failure, and a rule that only evaluates when scores are written stays silent through it. |
There was a problem hiding this comment.
It's a good question. Obviously one reason why an agent might not be producing any traces is that whatever triggers that agent isn't happening. For example, a chat agent isn't going to emit any traces if nobody's chatting with it. Similarly an agent that what is the temperature in a data center and takes action when it gets too hot he's only going to emit traces when the data center is too hot. With that said you could still alert on unusually long gaps in the trace (based on statistical analysis of how often the agent tends to do things). Or you could track a separate events for the agent triggering and then only alert when the agent does trigger but no reasoning occurs. Some agents might have a good reason for triggering, but not doing any reasoning if for example, they have a deterministic check at the start of the agent that decides whether to do any reasoning, but users could just not turn on this alert for those kinds of agents.
|
|
||
| The fix is written by a coding agent, not by MLflow itself. MLflow bundles [OpenCode](https://github.com/sst/opencode), an MIT-licensed open-source coding agent, as the default harness so the workflow works out of the box — and the harness is pluggable, so teams that already use Claude Code, Codex, or their own tooling can point the workflow at that instead. Inference always runs on the user's own model access, through an AI Gateway endpoint or their provider keys. MLflow never runs managed inference for fixes, and nothing merges without a human review. | ||
|
|
||
| The building blocks are things MLflow already has: [automatic issue detection](https://mlflow.org/docs/latest/genai/eval-monitor/ai-insights/detect-issues/) produces the findings, Part 1's events provide the trigger, the job executor framework ([RFC-0002](https://github.com/mlflow/rfcs/blob/main/rfcs/0002-job-executor-plugins/0002-job-executor-plugins.md)) provides the execution model, the prompt registry and `optimize_prompts()` cover prompt fixes, and evaluation datasets turn fixed failures into regression tests. The new state this adds is small, and inventoried in "What MLflow stores." |
There was a problem hiding this comment.
Technically Part 1 isn't something MLflow already has. It's something MLflow would have by the time we got to Part 2. So I might rephrase "already has" a tiny bit.
|
|
||
| #### Fix prompt drift without touching code | ||
|
|
||
| A sales assistant's correctness average slides from 0.9 to 0.7 over three weeks. Nothing errors — the prompt references product information that went stale, and the agent fills the gaps by guessing. |
There was a problem hiding this comment.
This example is better than the model-not-found example in part one. But I think it's a little confusing. The section heading says that it's about prompt drift, but the prompt hasn't drifted at all. It's just not as relevant to reality as it used to be. It's not totally obvious why that would cause the correctness average to go down because the correctness scorer probably wouldn't know the change in reality unless it had access to sources that the agent doesn't and if it did then, why doesn't the agent have those sources? I do think something along these lines would make for a good example. And maybe for the purpose of RFC you don't really need a good example because this is good enough to get the point across. But I think it would be a better RFC if the example of a little bit more compelling.
|
|
||
| #### Fix the component, not just the repo (future) | ||
|
|
||
| A production agent is really several components: its own code, the MCP servers it calls, the skills it loads. As MLflow's registry work lands — the [MCP Registry (RFC-0004)](https://github.com/mlflow/rfcs/blob/main/rfcs/0004-mcp-registry/0004-mcp-registry.md), the [Skill Registry (PR #26)](https://github.com/mlflow/rfcs/pull/26), and [Extended Skill Bundles (PR #27)](https://github.com/mlflow/rfcs/pull/27) — MLflow will know an agent's composition and where each component's source lives. A diagnosis can then name the component, and fixes become registry updates, not just pull requests: a failing tool call produces a fix against that MCP server's source and an updated registry definition; a broken skill produces a new registered version, propagated to every agent that uses it with the registry's review and rollback semantics. The workflow starts with one connected repository and gains this precision as each registry ships. |
There was a problem hiding this comment.
I think this is implied, but I kind of like to make it more explicit: if I have an agent that is some harness plus a group of skills, often times I will not have the ability to actually change the harness itself, especially if the harness is closed-source proprietary (e.g., Claude Code). For those agents, the only fix might be in the components and there might not be a repo for the agent itself. Or if there is a repo for the agent itself, it might just be the components plus reference out to the harness. So we might want to clarify that this is a supported configuration and that the agent fixing will still work in this scenario.
|
|
||
| # Open questions | ||
|
|
||
| 1. How should the cost of detection runs and fix generation be estimated and shown before the user commits to them? |
There was a problem hiding this comment.
This seems hard to do well. I would question whether this should even be in scope.
| # Open questions | ||
|
|
||
| 1. How should the cost of detection runs and fix generation be estimated and shown before the user commits to them? | ||
| 2. When the same underlying problem is detected again in a later run, should the user see one ongoing diagnosis or a new entry each time? |
There was a problem hiding this comment.
This also seems hard to do at scale, but probably worth investing in. Maybe I would take it out of a scope for the MVP just because it feels like something that could be added on later. I think it's difficult because "same underlying problem" it's not something that can reliably be detected through simple deterministic rules. So if I've had 15,000 problems detected on my agent so far, and I get a new problem figuring out whether it is the same as one of those existing 15,000 problems would probably involve first doing some sort of dense vector search over the existing 15,000 problems to find ones that are superficially similar to the new problem and then having a model go through one at a time and reason about the causes of each of the top candidates and how they relate to the current problem. I think in practice sometimes whether something is the same underlying problem is a matter of degree and not just a boolean yes or no.
2 participants
This RFC proposes closing the loop between MLflow observing an agent degrade and the agent getting fixed, in two parts:
Reading order: 0011-agent-improvement.md for the overview, then Part 1 and Part 2.
Following the journeys-first submission model, implementation detail is kept to a minimum; detailed design will be layered in once the problem framing and journeys are settled.