Every platform team runs part of its stack out of a drawer: a deploy script with a wiki page that says run it twice, a forked dashboard nobody dares upgrade, an internal admin that only works on one person's laptop. Each one solved a real problem the day it was written — and each one is one more thing to keep alive. The usual way out is a Retool-class builder — which swaps the drawer for a box: components that bend only so far, full power only against its own database, role management on a vendor's server, and per-seat pricing.
Vantage UI is the third option. Point an AI agent at your systems and it authors the console for you — declarative YAML plus Rhai for the logic — over a local MCP server, verifying its own work as it goes. Nothing is watered down on the way: Postgres with every subquery you'd write by hand, Salesforce, your internal APIs, AWS, any CLI your team already trusts. Months of internal-tool development become days.
And unlike Datadog, nothing gets ingested anywhere. Your data stays where it lives; Vantage reads it there, live. Nothing to ship out, no second copy to keep in sync — and the drawer finally closes.
The drawer, before. Every item has an owner, a runbook and a failure mode. Vantage retires them into entries in one console's sidebar.
One console, unlimited uses🔗
A Vantage console is not a dashboard product with a fixed shape — it's whatever your backends can answer. Three jobs from real teams:
- Monitor multi-cluster infrastructure in real time — without opening Datadog.
- Aggregate temperature-sensor data from the devices on your floor.
- Show your delivery vehicles on a live map — and reassign a route from the same screen.
Those aren't three products. They're three groups in one sidebar:
Wildly different jobs, adjacent menu entries. If it holds data or takes a command, it can sit in this sidebar.
It stays fast at any size — a smart local cache keeps big grids instant and refreshes them in the background, so the screen never keeps anyone waiting.
The agent writes it, then checks its own work🔗
You describe the screen. The agent writes the config — and proves it works before you look up:
youOne screen: deployments stuck across all three clusters, with a restart button per pod.
agentWrote pages/stuck-deployments.yaml — one grid, all three clusters.
agentWrote actions/restart-pod.rhai — wired to a button on each row.
agent✓ Opened the page over MCP: 3 stuck deployments listed, restart action in place.
That verification loop is why the result holds up. The agent isn't handing you code to go try — it runs the console on your machine, reads its own pages back over MCP, and fixes what it got wrong before reporting done. Ask for the next button and it appears: exactly the controls your team needs. And because the console speaks to your real backends, there is no capability ceiling to hit — if your database or API can answer it, the agent can put it on a screen.
Build once, share with the whole team🔗
One person builds the tool; the whole team opens a link. A Vantage app is only config — YAML and Rhai in a folder — so sharing it is sharing a git repo, or a zip if that's easier. The console travels. The data never does.
You build it
Your agent wires up the pages, tables and actions over the local MCP server — against dev credentials.
You publish it
Push the folder to your corporate git, or hand over a zip. It's just code — no data, no credentials inside.
The team opens it
One vantage:// link installs the app and pulls it from git. Each person signs into the data themselves.
The DBeaver test🔗
If a database client on a cleared laptop passes your security review, Vantage has the same model: a desktop app on your machine, speaking directly to your backends with credentials you hold. Your existing development practice applies unchanged:
- Dev credentials while building. You and your agent work against the dev environment; production credentials exist only where the finished app runs.
- The agent reads; it doesn't write. The agent's MCP access to a running console is read-only — page structure, debug queries, logs. Writes happen in the app, by whoever drives it, under their own credentials.
- The PII-cleared team gets the prod build. Ship the finished app to the cleared team; they connect it with production access. Developers — and their agents — never see it.
- Telemetry, stated plainly. The free version carries crash analytics — and an enterprise build can turn it off or route it to your own account.
See it in action🔗
Periscope shows this shape for Kubernetes — a full control room written entirely in YAML, drilling from namespaces to workloads to pods. The AWS control console example wraps the aws CLI to surface exactly the resources you operate, nothing more — it lands in the examples repo soon.
arrow_forwardNext rung: your console is already live — open screens update by themselves. Here's what that means →