Wispr Flow: Dictation That Works EverywhereStop typing. Start speaking. 4x faster.
Udal
Your agents. Your ground.
14 followers
Your agents. Your ground.
14 followers
Udal is a self-hosted, governed platform for building and running AI agents entirely inside your own environment. The whole lifecycle — author, check, promote, govern, observe — on infrastructure you own. Built for regulated finance and government.
Self-hosted agent platform with proper governance baked in is genuinely rare, glad someone finally tackled this for regulated teams. Curious how the promotion workflow holds up in practice.
@kayraupf5 Thanks, that's exactly the gap we kept falling into ourselves, so it's good to hear it lands.
On promotion holding up in practice: the core idea is that an agent is defined in a readable manifest, and moving it from dev to staging to prod is a Git operation, not a person clicking through a console and hoping. So the workflow inherits everything your team already trusts about GitOps: reviews, approvals, and a full history of who promoted what and when.
What makes it hold up rather than just look tidy is the gates between stages. Before an agent moves up, it has to pass eval gates which can be defined, e.g. behavioural evals, regression suites, cost and latency thresholds, and the policy screening that runs in prod also runs in the lower environments, so you're testing against real guardrails the whole way rather than discovering them at the end. If something fails a gate, it doesn't get promoted, same as a failing test blocks a merge.
The honest bit: promotion is only as strong as the evals you put in front of it, so a chunk of the value is that Udal gives you the place to hang those gates rather than every team reinventing them. We learned that the hard way delivering for our own customers.
For teams already knee-deep in Kubernetes, how painful is the initial setup, and does it play nicely with existing CI/CD pipelines like GitLab or Argo?
@doanlwbr Good question, and it's the one Kubernetes teams always ask first.
If you're already running clusters, setup is meant to feel familiar rather than like a new religion. Udal installs into your existing cluster (via Helm / your standard manifests), runs on EKS, AKS, GKE, OpenShift or bare metal, and doesn't ask you to hand anything off to us. There's no vendor control plane phoning home, so most of the "initial pain" is the usual namespace, RBAC and secrets wiring you already do for anything you deploy. A team comfortable with Kubernetes should expect a couple of days to a working install, not a multi-week project.
On CI/CD, it's built to fit rather than replace. Udal is GitOps-native: agents are defined in a readable manifest and promoted through dev, staging and prod from Git, so Argo CD sits very naturally on top and GitLab CI pipelines drive it fine too. You keep your existing pipeline, your existing review and approval gates, and your existing observability. Udal adds the eval and policy gates on the agent side and streams its audit trail into whatever you already run. Hope that answers your question?
How does governance actually work in practice here, like is it policy-as-code or more of a manual review workflow before agents get promoted?
@bayramzndzow4z THis is actually the thing regulated buyers care about most.
Short version: it's policy-as-code at the core, with two deliberate human gates on top, one at promotion and one at runtime for consequential actions. It is not a "manually eyeball every agent before it ships" workflow. Most of the enforcement is automated and fail-closed.
The automated layers:
Every agent is a YAML manifest that declares its tools, permission scopes, budgets, guardrails, default-deny egress and identity. That manifest is machine-validated at author time, in CI, and again by the Kubernetes operator on apply, so there's no "code does whatever it wants" path.
At runtime, the tool-server consults OPA (Rego) before any side-effecting tool call. Grants map your IdP groups and roles to tool scopes, and they're fail-closed, so an empty grant map denies everything until you define it. The important part: scopes are evaluated against the caller's entitlements, not the agent's, so an agent can never exceed the permissions of the person invoking it. It's your policy-as-code, owned by you.
On the way in, CI runs manifest validation, an offline eval gate, OPA policy tests, a digest-pinning check and security scans. Fail any of these and it doesn't promote.
The human gates, kept deliberately narrow:
Promotion is GitOps (Argo ApplicationSet with per-env overlays). Dev and stage auto-promote once the automated gates pass, but prod is a manual approval and sync, with digest-pinned artifacts at each hop. Deploying an agent at all is gated to a deployer role, fail-closed and audited. And for consequential actions like money movement, agents pause at an approval node with enforced separation of duties, so the approver has to be a different identity than the submitter and hold an approver role. Add per-agent pause and suspend plus hard budget stops as kill-switches.
Every one of those decisions, grants, approvals, deploys and pauses, lands in an immutable hash-chained audit log, which is what the compliance-evidence export is built on.
One honest caveat: policy is authored as Rego and promoted through GitOps. There isn't a point-and-click policy-authoring UI yet, the Policy tab is read-only reporting today and that's a tracked increment. So "policy-as-code" is literal here. You review policy the same way you review any code change, through PRs and the promotion gate, which is generally what regulated buyers want anyway (reviewable, versioned, signed) rather than live-editable policy.
So if the real question is "do I have to manually approve every agent," no. The guardrails are automated and fail-closed, and humans are only inserted at two high-leverage points: approving a production promotion, and approving a consequential runtime action.
Sorry, bit of a long winded answer but an important part of the whole application and one of the pain points we are trying to help people with
How does the governance layer actually work day to day, like are approvals enforced automatically through policy checks or is it still a manual review step before agents go to production?
@elmasdfxx Both, but weighted heavily toward automatic. Day to day, governance is enforced through policy checks, not human review. Each agent is a declarative manifest with its permissions, budgets and guardrails validated automatically at author time, in CI and on deploy, and policy is checked again at runtime before any consequential action. It's fail-closed, so nothing runs unless it's explicitly allowed.
The manual step is deliberately narrow. Lower environments promote automatically once the automated gates pass, and a human signs off only at the production boundary and for high-consequence runtime actions like moving money. So it's not a manual review of every agent before it ships. The automation does the enforcing, and people are inserted at just those two high-leverage points, with every decision logged.
How does deployment actually work on day one, do you package it as containers we can drop into our existing k8s cluster or do we need a separate control plane host?
@nisanurahraz Containers into your existing cluster, no separate control plane host. It ships as a Helm chart + Kubernetes Operator: you mirror our signed images into your own registry (cosign-verified, digest-pinned), kubectl apply one CRD, and helm install into a namespace. That deploys the whole control plane (runner, gateway, operator, etc.) as pods; agents themselves are just CRs the operator reconciles. Identity, secrets, models, and observability all bind to what you already run via adapters — IdP, Vault/KMS, your SIEM, Bedrock or self-hosted vLLM. Needs K8s 1.27+, works on EKS/AKS/OpenShift, and there's a signed air-gap bundle for offline installs. If you just want to kick the tires first, the whole stack also runs locally with docker compose up in ~10 minutes.