[FEATURE] Allow agents to run independently without kagent controller runtime communication

[ma-tie]

📋 Prerequisites

• I have searched the existing issues to avoid creating a duplicate
• By submitting this issue, you agree to follow our Code of Conduct

📝 Feature Summary

Implement a fully decoupled deployment mode where the running Multi-Agent System (MAS) is isolated from all Kagent infrastructure components, removing all potential scaling bottlenecks.

❓ Problem Statement / Motivation

Problem

When deploying and scale-testing agents with Kagent, the kagent-controller becomes a scalability bottleneck that limits the agent system's capacity.

For example, the kagent-controller logs all agent activities (tasks, events, sessions) to its database by default, with no disable option:

• go/internal/httpserver/handlers/tasks.go:56 - Task persistence

• go/internal/httpserver/handlers/sessions.go:145,385 - Session & event persistence:

What's worse is, the default storage is only 500 MiB in-memory, causing disk exhaustion during load tests:

• helm/kagent/templates/controller-deployment.yaml:32

And I am not sure if it is the only connection between kagent-controller and the agents I deployed.

Why This is Problematic

Agent system scalability should not be constrained by Kagent's central components. The controller becomes a single point of failure for:

• High-concurrency scenarios
• Long-running deployments

Proposed Feature

Is it possible to deploy a Multi-Agent System where Kagent is utilized for setup, but the Kagent components are disconnected from the agent system during operation, thus eliminating this specific bottleneck? In other words, after containerized deployment, the agent system should be fully decoupled from KAgent infrastructure

💡 Proposed Solution

Support a decoupled/standalone deployment mode: After containerized deployment, agents operate independently without runtime kagent communication

🔄 Alternatives Considered

No response

🎯 Affected Service(s)

Multiple services / System-wide

📚 Additional Context

No response

🙋 Are you willing to contribute?

• I am willing to submit a PR for this feature

[EItanya]

Sorry for the late reply, but i have some questions here

What exactly are you looking for out of kagent if there's no controller communication, then the majority of features of kagent will not work. I totally understand the worries here, but I think we should figure out how to make sure the kagent services scale, rather than disabling them entirely.

For example, you can already use postgres today as opposed to sqlite for storage limits.

We can separate out the httpserver into a dedicated pod to ensure we can horizontally scale it.

let me know what you think?

[joshadambell]

I like this proposal. A decoupled execution model—similar to Argo Workflows—would let Kagent handle deployment and lifecycle management while allowing agents to run independently once scheduled. This could support both ephemeral, workflow-style executions and the existing long-running, interactive agents without a controller dependency during operation. It would allow simpler memory sharing between agents as they would run in a single pod.

[EItanya]

I like this proposal. A decoupled execution model—similar to Argo Workflows—would let Kagent handle deployment and lifecycle management while allowing agents to run independently once scheduled. This could support both ephemeral, workflow-style executions and the existing long-running, interactive agents without a controller dependency during operation. It would allow simpler memory sharing between agents as they would run in a single pod.

Very interesting, can i get some clarification and use-cases.

First off, what are some examples of agents which don't need to check into the control-plane at all? And if they are not checking in at all, what do they need from kagent. I'm genuinely curious here

In terms of workflows, they are by nature stateful, so something has to be tracking their state as they run. I think an integration with argo workflows could be super cool, but I'm not sure exactly what we would add there.

Again, I think I may be misunderstanding the use-case here so looking forward to hearing more

[joshadambell]

Very interesting, can i get some clarification and use-cases.

First off, what are some examples of agents which don't need to check into the control-plane at all? And if they are not checking in at all, what do they need from kagent. I'm genuinely curious here

In terms of workflows, they are by nature stateful, so something has to be tracking their state as they run. I think an integration with argo workflows could be super cool, but I'm not sure exactly what we would add there.

Again, I think I may be misunderstanding the use-case here so looking forward to hearing more

Thanks for the follow-up! Happy to clarify. Still working through this in my head.

For use cases, I'm thinking about ephemeral, workflow-style executions:

• Root cause analysis, batch jobs, PR reviews, architecture reviews
• Multi-agent workflows where specialized agents collaborate on larger tasks
• One-shot operations that don't need always-on infrastructure

The Idea
Agents still defined as kagent CRDs and deployed by the controller. Task tracking and event logging still flow back to kagent for UI visibility and history.

The difference: agent pods run as Pods that are self-contained after triggering. The controller provisions them and tracks their status, but doesn't actively manage execution. Similar to how Argo Workflows handles workflow pods—deploy, let them run independently with status updates, clean up when done. Not an integration with Argo Workflows but similar architectural patterns.

For multi-agent workflows, co-locating agents in a single pod simplifies coordination through shared local storage instead of network calls.

Reduces operational overhead for ephemeral workloads while your PostgreSQL/horizontal scaling suggestions handle the interactive agent use cases. Both approaches are complementary.

Make sense?

[waveywaves]

Hi, I found the same gap while working on integrating kagent with Tekton Pipelines for CI/CD agent workflows. I would like to contribute a fix.

My use case: I am building an AgentRun controller that orchestrates one-shot agent executions within Tekton Pipeline DAGs. Code review gates, test generation, cluster diagnostics, deployment decisions. Each execution runs once, produces structured results, and exits. I have a TEP (Tekton Enhancement Proposal) up for this.

I want to use kagent's ModelConfig and RemoteMCPServer CRDs for configuration and the ADK image as the agent container. The ADK already handles 8 LLM providers, MCP tool protocol, and the agent loop. I do not want to rebuild that.

The gap is the same as what @ma-tie and @joshadambell described: the controller creates a Deployment + Service per Agent CR. For CI/CD, a Deployment per pipeline step just adds overhead.

The kagent-adk test command already supports one-shot execution with InMemorySessionService. I think this can be extended into a proper batch mode.

I would like to contribute one of these:

1. A Job/Pod execution mode on the Agent CR (e.g., spec.executionMode: Job vs Service) where the controller creates a Job instead of a Deployment
2. Or: a batch entrypoint in the ADK that reads config.json + a task, runs to completion, writes structured results to a file, and exits. Something like kagent-adk batch --task "..." --filepath /config --output /results/output.json

Which approach would you prefer? Happy to start on either.

cc @EItanya @joshadambell