Four teams. Four ways of building an agent.
And the platform group gets asked to sort it out before it becomes a mess. Mandate one runtime, one cloud and one framework and they’ll find four ways around that too. Whatever you standardisestandardize on this year is a different product next year. What’s standard here is how the work is defined, tested and governed; the runtime, the cloud and the framework stay whatever each team already picked.
promptpacks · one workspace · version and status on every row
Whatever the four teams build, it lands here as one of these.
{
"id": "refund-voice-agent",
"version": "1.4.0",
"requires": {
"providers": [
{ "key": "default", "role": "llm" },
{ "key": "judge", "role": "llm" }
]
},
"tools": {
"lookup_order": { "description": "find the order first" },
"verify_customer": { "description": "before disclosing anything" },
"issue_refund": { "description": "only once verified" }
},
"prompts": {
"refund": {
"tools": ["lookup_order", "verify_customer", "issue_refund"]
}
},
"evals": [
{
"id": "never-promises-early",
"type": "llm_judge",
"trigger": "sample_turns",
"sample_percentage": 10
}
]
}Compiled out of the testing that already passed.
The standard is a file, not a mandate.
Everything that makes an agent that agent, in one versioned thing. Review it the way you review anything else.
requiresasks for a judge model, and your cluster decides which one that istoolsis the whole list it may reach for, and the only oneevalsship inside it, so the checks that proved it keep running after it lands
PromptPack The open spec this file is written to. MIT, twelve accepted RFCs, a schema to validate against. Read the spec → Where you start depends on what you already have.
- 01 you already run agents Leave them where they are. The ones on AgentCore, Vertex or Foundry come up in the console beside anything you deploy later, under the same rules. How much that takes depends on how they were built; none of it is a migration.
- 02 you build the next one Define it as a pack. Deploy it to your cluster, AgentCore, Vertex Agents or Foundry. The guardrails and the tests travel with it.
- 03 you want all of it A rule on every tool call, redaction you can test, ten thousand test runs at once, and rollouts that stop themselves.
Watch one go from a first draft to live traffic.
Five steps, one artefactartifact. What gets tested at the start is what serves traffic at the end.
Describe the job. Your own tooling writes the first draft.
promptarena agent-brief drops the skills and reference a coding agent needs to author one of these properly. After that you describe the job in a couple of sentences, and it comes back with the prompt, the tools it needs mocked out, and the cases that will try to break it.
Every case, on as many workers as it takes.
Evaluations, load tests and data generation, run against a project by a pool of workers you size. Mocked tools keep it cheap enough to sit in CI, and pointing the same run at real providers tells you what finding out cost.
The pack compiles.
Prompts, tools, steps, the models it’s allowed to use and the tests it has to pass: one versioned thing. That’s what gets reviewed and approved.
It shows you what it will create before it creates it.
The same kit that just passed, compiled straight to Kubernetes: one PromptPack and one AgentRuntime. A plan first, so you can read what it intends to do, and deploy apply is the only thing standing between this and serving traffic.
It keeps being tested.
The checks that proved it run inline against the real work, every decision is on the record with the rule that made it, and anything that goes wrong comes back as a case for the next version.
These are real sessions, and the tool in them is PromptArena, which is Apache 2.0. npm i -g @altairalabs/promptarena and run the same commands against something of your own.
Authored in the console
Quick to get a first version standing up and being argued with. Who can do it, and in which workspace, is a role, so it can be two people, or nobody, without changing anything else.
Synced from your repository
Definitions, skills and test projects come from git, an OCI registry or a config map, so a change is a pull request with the reviewers you already require, and the cluster reconciles to what’s merged, not to what someone clicked.
Both produce the same artefactartifact and face the same gate. The console is the quicker way to find the shape of a thing; the repository is where it lives once you know.
Every one of the eighteen custom resources serves v1alpha1. That’s the first
thing a platform team checks, and it’s deliberate: the shape of a
CRD is a contract you have to live with, and we’d rather settle it with the people who
are going to run it than freeze it early and find out we were wrong at v1.
Four products, one lineage.
PromptPack The file that pins down what an agent may do. Open spec, MIT. 
PromptArena Evaluation, regression and adversarial testing. Apache 2.0. 
PromptKit The portable runtime. Text, voice, tools, memory and workflow state in one Go binary. Apache 2.0. 
Omnia Where you build them, run them by the thousand, and see what every one of them did. promptpack → promptarena → promptkit → omnia
It runs air-gapped.
Your cloud, your region, your air-gapped environment. Prompts, traces, tool calls, evaluation data and behaviouralbehavioral evidence never go anywhere, because nothing needs to leave for any of it to work. The deployment is yours.
Free while you build. Free to run. Enterprise features when you need them.
Seven native provider interfaces, three managed platforms, and any OpenAI-compatible endpoint. Embeddings, speech and image generation are roles a pack can require, the same way it requires a judge model.
Which ones an agent is allowed to use is part of its definition, so swapping a model is a change you can review.