One Prompt to a Live URL: The Anatomy of an Agent-Shipped Product

For a recent internal demo day, this was the entire specification:

Create me a single page that is something fun related to facts about the
deep sea and make it animated. Use our GPU server to provide some AI
interactive experience. Go to gpu-chat and generate a token from
litellm and set yourself a budget for $20, store it in this repo
https://github.com/ankraio/deep-sea-demo, use ankra cli to add it as an
application, when it's fully built, deploy it to the cluster demo-day,
and provide a url on our demo domain

That is one paragraph, typed the way you would brief a colleague on their way to get coffee. Some time later, deepsea.demo.ankra.cc was live: an animated page called Deep Sea Facts, full of drifting bioluminescent creatures and genuinely fun ocean trivia, with a chat named Sonar in the corner answering questions from a GPU we own. Real TLS, real domain, running on a real Kubernetes cluster.

This post unpacks what that paragraph actually asked for, what the agent did with it, and, honestly, how much of the result was the agent versus how much was the platform underneath it. Because the answer to that second question is the whole story.

Six asks in four sentences

Read the prompt again slowly and count the jobs in it.

Build a fun animated single page: that is a frontend developer. Wire an AI interactive experience to our GPU server: that is an AI engineer who knows the inference stack. Generate yourself an API token with a spending cap: that is credential management, normally a ticket to whoever guards the keys. Store it in this repository: source control. Add it as an application and build it: release engineering. Deploy it to a named cluster and put it on a real subdomain with TLS: platform operations and DNS administration.

Six hats. In most organisations that paragraph is a Jira epic with five assignees and a two week lead time, most of which is waiting: for the API key, for the pipeline, for the DNS record, for the person who knows how the cluster works to come back from lunch.

The agent did not wait for anyone, and that is not because it is smarter than your team. It is because every hat except the first one had already been turned into a platform capability it could call.

What came out the other end

The page itself is charming and completely unremarkable as software, which is exactly the point. Deep Sea Facts animates glowing creatures drifting through the midnight zone and serves up the kind of trivia that makes people smile: pressure at the deepest trench equal to a small car balanced on your thumbnail, anglerfish carrying their own biological lanterns, more of the ocean floor unmapped than the surface of Mars. Exactly the kind of thing a demo day deserves.

The interactive part is Ask Sonar: a chat window where visitors ask anything about the deep and get answers streamed back. Sonar is not calling a public AI provider. It is calling the OpenAI-compatible API of the gpu-chat stack running on our own GPU cluster, the same managed private AI stack we wrote about this week: vLLM on a GPU node in our own cloud account, behind a LiteLLM token broker.

A competent developer builds this page in an afternoon. Everything after the page is where an afternoon usually becomes a sprint. So let us talk about everything after.

The sentence that should scare you

The prompt contains one instruction that ought to raise the hair on a security engineer’s neck: “generate a token from litellm and set yourself a budget for $20.”

An AI agent provisioning its own credentials is, on most infrastructure, a horror story with extra steps. Against a public AI provider it means the agent holds an organisation-level API key with the power to mint more, and its idea of restraint is whatever the prompt implied. The blast radius is your monthly invoice.

On the private stack this sentence is boring, and boring is the achievement. The LiteLLM broker in front of the GPU exposes exactly one lane for this: mint a scoped key with a named alias and a hard budget. The agent called it, got a key that belongs to this demo alone, and wired that key into the deployment. If Sonar gets popular beyond its budget, requests start returning 429 while every other key on the stack carries on. If the demo is ever compromised, we revoke one key and nothing else rotates. Per-key spend shows up on the same Grafana dashboard as everything else, so the demo’s consumption is a line item we can read, not a surprise we reconstruct.

And because the GPU is a flat-rate server we already pay for, the twenty dollars is not even real marginal spend. It is a governance cap: a number that makes the agent’s autonomy finite and legible. That is what letting an agent self-serve credentials should look like: possible, bounded, and recorded.

From a repository to a running deployment

The rest of the prompt is verbs that usually mean YAML: add it as an application, build it, deploy it, give it a URL.

The agent pushed the code to the repository and ran the Ankra CLI to register it as an application. Ankra analysed the repository, built the container image, and pushed it to the Harbor registry the platform provides for the organisation. Nobody stood up a registry for this demo and nobody handed the agent a docker login: every Ankra organisation gets its own Harbor out of the box, the build lane pushes with credentials the platform holds, and the cluster pulls with scoped credentials of its own. Deploying to demo-day is one more instruction: the deployment engine rolled the application out to that cluster in dependency order, and the platform’s DNS and certificate lane put the demo hostname in front of it, on our domain, with a valid certificate, automatically.

Here is the list of things the agent never touched: a kubeconfig, a kubectl context, a cloud console, a registry login, an ingress manifest, a certificate request, a DNS control panel. It never held a credential that could reach any of those surfaces directly. Every imperative in the prompt resolved to a typed platform capability with its own permissions and its own audit line, which is the only reason handing the whole paragraph to an autonomous agent was a reasonable thing to do.

The honest accounting

So how much of this was Ankra? Being straight about it: the agent contributed the code and the glue decisions, and they were good ones. The animation, the facts, the little personality in Sonar’s tone, the choice of how to stream responses: that is genuine work, done well, by the model.

Every other sentence of the prompt was the agent riding rails that already existed. The GPU endpoint exists because a stack profile deployed thirty-odd resources in the right order weeks ago. The self-serve budgeted token exists because the broker is part of that stack. The repository-to-image-to-rollout path exists because the application registry and deployment engine are the product, and the image has somewhere trustworthy to live because a Harbor registry comes with the organisation. The URL exists because DNS and TLS are a lane, not a ticket.

Agents do not remove platform engineering. They concentrate it. Someone builds the rails once, properly, with permissions and budgets and audit lines, and from then on a paragraph of intent can ride them end to end. Skip the rails and the same paragraph is a week of a senior engineer’s time, or worse, an agent improvising with credentials it should never have held.

Sub-agents with day jobs: the board

There is a part of this story that does not show up on the demo page at all, and it is the part that matters most for anyone thinking about agents in production.

While the main agent built and shipped, the work that touched the Ankra platform itself ran through the Ankra AI board. The board is where agent work becomes accountable: tasks land as tickets, a dispatcher assigns them to sub-agents, and each sub-agent operates under its own identity with its own scoped permissions rather than borrowing some human’s god-mode session.

For this demo we used that to put auditors alongside the builder. Board sub-agents picked up the review lanes: check the deployment’s manifests against policy, verify the minted key really carries the budget and scope the prompt claimed, sweep the repository for anything that looks like a leaked secret, confirm the TLS and DNS state on the new hostname. The builder builds, the auditors audit, and neither needs the other’s permissions to do it.

Anything risky stops at an approval gate. A gated action shows up in the inbox as a card with the full context and the sensitive parameters masked, and a human decides. Every action any agent takes, approved or autonomous, lands in the audit trail and the change ledger, so a security review afterwards is reading a record, not reconstructing one from shell history. And if anything ever feels wrong, there are two brakes: pause autonomy at the policy level, or stop every agent cold with one switch.

That is the security model that makes the one-paragraph prompt responsible rather than reckless: not trust in the model, but identity, scope, budgets, gates, and a ledger. Autonomy scales exactly as far as accountability does.

Party trick, or preview

It is tempting to file this under demo day fun, and it was fun. But look at the steps once more: build, integrate AI privately, provision a bounded credential, register, build, deploy, expose. That is not a demo script. That is what your team does all day, minus the ocean trivia.

Every rail in this story is the product, not a prop: the private AI stack is a profile you can deploy on your own GPU in about thirty five minutes, the application and deployment lanes are the core platform, and the AI board ships with it. The prompt is the easy part. Bring the paragraph; the rails are ready.

The demo’s code is public at github.com/ankraio/deep-sea-demo, together with the CI gauntlet it ships through: linters, tests, gitleaks, Semgrep against the OWASP Top Ten, Trivy and Grype scans, an SBOM, CodeQL, and an OWASP ZAP baseline against the running container. One prompt in, but linted, tested, scanned, and inventoried on the way out.

Get started: Create a free account on Ankra and provision your first cluster inside the free 30 vCPU allowance.

Join our community: Slack

Follow us on: LinkedIn | GitHub

Contact us: [email protected]