Agent-native validation workflows that run against real dependencies in your Kubernetes cluster, built on a governed catalog of typed primitives your platform team controls.
Today we’re shipping Signadot Plans, the next major piece of our agent-native, skills-based platform expansion. A plan is a small, reusable validation workflow that an agent can author from natural language and run against a live Sandbox. Plans give coding agents a versioned vocabulary for what correct means in your system, built on typed primitives your platform team controls. Available now in beta for all Signadot users.
Plans build on Signadot’s ephemeral environment and local development solutions to provide a comprehensive, agent-native platform for building and validating microservices. They run inside your Kubernetes cluster, where the agent’s work session already lives, and are governed by the platform team.
Below, we walk through what plans are, why the workflow is split the way it is, what they look like in action, and what this changes for teams building with agents using Signadot.
A plan is a small, reusable validation workflow that runs against a live Signadot Sandbox. Plans are made up of two layers:
Actions are typed, deterministic building blocks. The catalog ships with request-http for API checks, playwright for browser flows, and k6 for load scenarios, with more on the way. Each action is documented inline in markdown, so an agent reading the catalog can compose unfamiliar ones correctly without you holding its hand.
The catalog lives at signadot/actions and accepts community contributions.
Plans wrap actions for specific validation use cases, each one scoped to a single user-visible behavior. They’re authored from natural language: a developer or agent describes what should be validated, drafts the plan, and commits it alongside the code as a versioned artifact. Every plan carries a selectionHint (a natural language description of what it validates), so the next agent can scan the library and pick the right one for the diff in front of it.
The value is in the breadth of the library. A team accumulates many small, focused plans over time, and agents choose the right ones for each change.
Plans are parameterized. The same plan can run against a sandbox or against the baseline cluster by toggling a routingKey, which means the same artifact serves both the agent validating its own change and a sanity check against the main branch. Plans can also be pinned to specific clusters, tagged for replay (signadot plan run --tag ride-request-flow), and browsed in the dashboard alongside their run history.
selectionHint · validates the end-to-end booking flow through the frontendCoding agents interact with Plans through skills. Skills are the right interface for this work because they let the agent discover capabilities at the moment it needs them, without the developer pre-wiring anything into a system prompt or the agent guessing at an API. When an agent is mid-session and looking at a diff, the skill tells it what’s available, when to reach for it, and how to use it correctly.
We built two skills for Plans because authoring and running are different jobs, and keeping them separate lets the agent pick the right tool without ambiguity.
signadot-plan is the authoring skill. The agent inspects the action catalog, drafts a plan from a natural-language description, runs it once against baseline to confirm it works, tags it, and commits it.
signadot-validate is the runner. It reads the diff, picks a plan via selectionHint, spins up a sandbox with the change wired in, runs the plan, propagates the fix to whichever consumer broke, and re-runs until the plan passes.
Underneath both skills is a deliberate division of responsibility. Platform teams own the action catalog, which is where governance lives: what kinds of validation are allowed, what infrastructure they touch, what each action is permitted to do inside the cluster. Developers and agents author plans on top of that catalog. The boundary stays where you want it, and the surface area agents can reach stays bounded to what your platform team has approved.
A worked example from the HotROD demo, four Go services on Kubernetes with Redis, MySQL, and Kafka.
You ask the agent to rename a field on the location service. Name becomes LocationName. The Go build is clean. Unit tests pass. Linters are happy. From inside the location service, everything looks done.
Before opening the PR, the agent invokes signadot-validate. The skill reads the diff, finds the existing ride-request plan via its selection hint (a Playwright check that walks the booking flow), spins a sandbox with the modified service wired in, and runs the plan against the real frontend, real database, and real downstream services.
The plan fails. The frontend still reads the old name field. The itinerary renders empty. The assertion times out.
The skill reads the failure, traces it to the contract, finds the four call sites in the React app that read the old field, updates each one, rebuilds, and adds the frontend to the sandbox as a second locally mapped workload. It re-runs the plan. It passes.
The PR that opens is already validated against the real cluster. The reviewer gets a diff plus a passing plan run they can click through and audit. The whole loop happened inside the agent’s session, before any human looked at the code.
The full walkthrough is in the plan-based validation quickstart.
For teams using Signadot, Plans turns per-change validation from a problem each agent has to solve from scratch into a reusable library that grows over time.
With Plans, Signadot becomes a comprehensive, agent-native platform for building and validating microservices on Kubernetes. Signadot Sandboxes give agents lightweight, ephemeral environments inside your Kubernetes cluster, ready in seconds for any change an agent wants to validate. Plans and skills give agents the validation vocabulary to run inside those environments, governed by your platform team. More pieces coming.
If you’re already on Signadot, Plans is available in your account today. If you’re not, sign up for free or book a demo.
Get the latest updates from Signadot
