April Product Update: Introducing Plural's Build-Your-Own Agents for DevOps
🔍 What's New in Plural
This month we’re announcing Plural Workbenches: the layer we’ve been building toward since the Agent Runtime landed in February. A Workbench is an always-on, configurable DevOps agent that investigates alerts, walks your infra, and opens reviewable PRs, grounded in your GitOps state and Plural’s semantic infra graph.
🤖 Introducing Plural Workbenches
Plural Workbenches are always-on, fully configurable DevOps agents you build to fit your environment. A Workbench bundles three things into one structured workspace: the tools your team uses (observability providers, SCM, ticket systems, arbitrary MCP servers), the skills that encode how you operate (runbooks, review practices, remediation patterns), and a set of purpose-built subagents that specialize in observability, infrastructure analysis, and code changes.
Configure a Workbench once, and from then on it can run three ways:
- On demand from a prompt
- On a cron schedule for recurring work
- Automatically in response to a webhook — an Alertmanager page, a GitHub issue, a Linear ticket, a Jira change
Every Workbench is grounded in the Plural semantic infra graph alongside your GitOps state, so the agent actually knows your environment. Work is split across subagents with isolated context windows: the observability subagent can sift through thousands of log lines and metric series without polluting the orchestrator’s reasoning; the infra subagent walks Terraform, Helm, and cluster state independently; the coding subagent clones the repo, validates the hypothesis, and produces a reviewable PR.
What comes out the other side is a written memo explaining what happened and why, a linked PR a human reviewer can evaluate in minutes, and a full audit trail of every tool call and subagent decision. Workbenches ship with native integrations for Datadog, Prometheus, Loki, Tempo, Elasticsearch, OpenSearch, and Sentry on the observability side; GitHub, GitLab, Linear, Jira, and Asana on the ticketing and SCM side; and generic MCP server support for anything else your team runs.
🛡️ Custom policies for Stacks
Stacks now support custom Rego / OPA policy checks. Drop policy files into .plural/policies at the root of your stack repo and the Deployment Operator's Trivy-based scanner will pick them up automatically — no separate configuration, no extra glue. Policies execute under a dedicated user namespace, so anything you write under data.user.terraform.custom.* (or the equivalent for your stack type) will be evaluated alongside Plural's built-in checks.
Violations flow back into the Console as StackPolicyViolationAttributes, so they show up in the same UI as the rest of your stack health: surface them as gating checks, route them into a Workbench for triage, or let them ride alongside your existing policy engine. You also retain the existing policyPaths / policyNamespaces knobs on PolicyEngineFragment if you want to layer in policies from outside the repo.
This closes a long-standing gap for teams that wanted to treat their Terraform and Ansible stacks the same way they treat their Kubernetes resources — written policy, enforced before apply.
🏢 Company Updates
We’ll be attending KCD Texas and Edge Computing Expo in May. Let us know if you plan on attending either!