The Control Plane, the GitOps Agent, and a New Way to Evaluate Enterprise Test Orchestration

The way teams ship has changed faster than the way they test.

Engineering teams now deploy across multiple clusters and regions, manage infrastructure as code through GitOps workflows, and trigger tests on Kubernetes events rather than just on commit. AI-assisted development has further accelerated the rate of change: more tests, more environments, more orchestration complexity than any pipeline was built to handle.

CI/CD tools were built to move artifacts through predefined stages. They can run a test as a step. What they can't do is orchestrate testing as a system: across clusters, environments, and teams, with consistent visibility and the resilience that production workloads actually require. If you've started to feel that distinction in your day-to-day, this release is worth your attention.

The February 2026 release does two things: it advances the Testkube architecture that makes enterprise-scale test orchestration possible, and it changes how you can evaluate whether Testkube is the right fit before you commit to deploying anything.

Evaluate the platform on its merits

For most teams assessing test orchestration tooling, evaluation has historically meant deployment first. You stood up the infrastructure, connected your clusters, and hoped the setup process gave you enough signal to make a decision.

With this release, that changes.

You can now sign up and work directly inside the full Testkube control plane: workflows, test catalogs, execution history, observability. Not a sandboxed demo. The actual platform, in an environment built for real assessment.

For engineering leaders doing due diligence on test orchestration, the hardest evaluation question is rarely about installation. It is about workflow modeling: how does the platform structure your test suites, what does execution history look like at scale, how does observability surface across environments. You can now answer those questions before the conversation becomes a deployment conversation.

Why does this matter to you

The tools most teams reach for were not designed for this problem. CI/CD tools execute workflows. Testing tools execute tests. Testkube orchestrates testing as a system, across clusters, environments, and teams.

Most teams do not have a shortage of testing tools. The gap is the orchestration layer: a unified system that connects those tools, makes execution observable across environments, and holds up as infrastructure scales. Without it, teams run tests in isolation, report in isolation, and spend more time tracing failures than resolving them.

The redesigned evaluation experience is a consequence of architectural work that has been in progress for the past year. Understanding it explains why this release represents a structural shift rather than a feature addition.

The architecture behind this release

When Testkube's original architecture was designed, testing resources were managed inside the cluster agent. That model works well for standalone deployments but creates dependencies that limit both flexibility and resilience in complex setups. Over the past months, we rebuilt the Testkube foundation in three phases to better cater to our enterprise customer needs.

Phase 1: Runner agents and multi-cluster execution

We introduced runner agents as our first major architectural shift. Instead of a single agent managing everything in one cluster, you can now place runner agents wherever you need to run tests: different clusters, different regions, different ephemeral environments. This was the foundation for multi-cluster test orchestration and unlocked a class of use cases that were not previously possible.

Phase 2: Listener agents and event-driven orchestration

We extracted more functionality into discrete, purpose-built agents. Listener agents observe Kubernetes events and trigger test workflows in response. When a deployment updates in one cluster, a Listener agent can automatically trigger a Runner Agent in another. Orchestration that reacts to your infrastructure, without manual intervention and without hardcoding trigger logic into pipeline configuration.

Phase 3: The Control Plane shift

The February release completes this evolution. Resource management has moved from the cluster agent into the Testkube control plane. Your test workflows, catalogs, and configurations are now owned and managed centrally. Three outcomes follow directly: improved performance and resilience, tighter security through consolidated resource control, and the structural foundation that makes automated testing in complex GitOps deployments possible.

What is new in the February release

The GitOps agent: multi-source resource syncing

For teams running GitOps workflows across multiple clusters, this release introduces a new agent type: the GitOps agent. It syncs test resources from multiple clusters directly into the Testkube control plane. In practice:

• No cluster-bound test definitions: your catalog lives in the control plane, not inside any individual cluster
• No manual sync: test resources update automatically as your Git-managed infrastructure changes
• Git as the single source of truth: testing configuration lives where the rest of your infrastructure configuration lives

For enterprise teams managing complex, multi-cluster environments, your automated testing infrastructure now behaves like the rest of your infrastructure.

Control plane improvements: performance, resilience, and security

The control plane no longer depends on a cluster agent to serve your data. Test results, workflow metadata, and execution history are reliably available regardless of the state of any individual cluster agent. For organizations running Testkube at scale, this translates to more consistent observability, tighter security, and reliable access to test data.

AI agent enhancements: OAuth with MCP and improved stability

The Testkube AI Agents feature, launched in January, now supports OAuth authentication with MCP servers. This makes it significantly easier to connect agents to external systems including GitHub and GitLab for remediation workflows and observability platforms for context-enriched failure analysis. Meaningful stability improvements also ship in this release across multi-agent workflows.

What this means for your orchestration strategy

Test orchestration is still a young category. Most teams are somewhere on the journey from tests embedded in CI pipelines to tests orchestrated as a system. The teams that have made that shift consistently identify the same bottleneck: not the testing tools, but the absence of a coordination layer that holds up as infrastructure scales.

The February release does two things: it strengthens that coordination layer for organizations already running Testkube at enterprise scale, and it removes the friction that has historically made it difficult for teams to assess whether it is the right fit.

If you are running tests across multiple clusters, your test infrastructure can now match the operational model of the rest of your infrastructure: GitOps-native, event-driven, and centrally visible. If you are evaluating Testkube for the first time, the platform is now fully available to you before any infrastructure commitment is required.

The architecture is no longer the constraint. Start your trial at testkube.io, or join us on March 18 where we will walk through the full architecture story and what is coming next.