[BUG] Agent with replicas > 1 disappears from MCP when any single pod is disrupted, even if healthy replicas remain

[HDBandit]

📋 Prerequisites

• I have searched the existing issues to avoid creating a duplicate
• By submitting this issue, you agree to follow our Code of Conduct
• I am using the latest version of the software
• I have tried to clear cache/cookies or used incognito mode (if ui-related)
• I can consistently reproduce this issue

🎯 Affected Service(s)

Controller Service

🚦 Impact/Severity

Blocker

🐛 Bug Description

When an Agent is configured with replicas > 1, the agent becomes undiscoverable via the MCP server (list_agents, invoke_agent, kagent://agents resource) as soon as any single pod is disrupted , even when other healthy replicas are still running and serving traffic.

This causes a complete MCP visibility outage during normal Kubernetes operations that involve pod disruption, such as node drains, rolling updates, Kyverno policy enforcement, or OOM kills.

🔄 Steps To Reproduce

1. Deploy an Agent with replicas: 2
2. Verify the agent appears in list_agents and is accessible via MCP
3. Delete or disrupt one of the two agent pods (e.g. kubectl delete pod )
4. While the remaining pod is still Running and Ready, query list_agents via MCP

🤔 Expected Behavior

The agent should remain discoverable via MCP as long as at least one healthy replica is available and serving traffic. The MCP Ready condition should reflect availability (i.e., AvailableReplicas >= 1), not whether all desired replicas are simultaneously available.

📱 Actual Behavior

The agent immediately disappears from list_agents, invoke_agent, and the kagent://agents resource as soon as AvailableReplicas < desiredReplicas.
This is caused by a hardcoded strict equality check in the reconciler:
// go/core/internal/controller/reconciler/reconciler.go:300
if deployment.Status.AvailableReplicas >= replicas {
// Ready = True, Reason = "DeploymentReady"
} else {
// Ready = False → agent disappears from MCP
}

Where replicas = deployment.Spec.Replicas (e.g., 2). There is no grace period, debounce, or minAvailable threshold — the condition flips immediately.
The MCP handler in go/core/internal/mcp/mcp_handler.go:133–159 (listReadyAgents) requires Ready=True with Reason=DeploymentReady to include an agent in the list, so the agent vanishes entirely until all desired replicas are back.

💻 Environment

• Kubernetes provider: EKS
• Kubernetes version: 1.33
• kagent version: 0.10.0-beta6
• Agent replicas: 2
• Pod disruption trigger: Kyverno policy enforcement (direct pod DELETE for compacting resources or regular deployment)

🔧 CLI Bug Report

No response

🔍 Additional Context

• This is a regression risk for any production deployment using replicas > 1 with any form of voluntary or involuntary disruption (node drain, Kyverno, PodDisruptionBudget evictions, rolling restarts).
• The closest existing issue is [BUG] MCP list_agents / invoke_agent exclude all SandboxAgents (only lists Agent CRs, hardcodes reason=="DeploymentReady") #2123 ([BUG] MCP list_agents / invoke_agent exclude all SandboxAgents (only lists Agent CRs, hardcodes reason=="DeploymentReady") #2123) which touches the same readiness filtering code but for a different scenario (SandboxAgents).
• A PodDisruptionBudget with minAvailable: 1 does not fully mitigate this because the kagent readiness check still requires all desiredReplicas to be available.
• Suggested fix: Change the readiness threshold from AvailableReplicas >= desiredReplicas to AvailableReplicas >= 1 (or introduce a configurable spec.minAvailable field on the Agent CRD), so that the agent remains MCP-discoverable as long as at least one replica is healthy.

📋 Logs

📷 Screenshots

No response

🙋 Are you willing to contribute?

• I am willing to submit a PR to fix this issue

[muskiteer]

I would like to take this one if someone is not working on this already.