Nobody owns the prompt store, and that is the actual LLMOps problem

A post on dev.to makes the case that LLMOps should be folded into an existing platform rather than handed its own org, quoting CNCF's Daniel Bryant: "LLMOps doesn't need its own kingdom. It needs a well-run platform willing to let it in." ^[3] The reason that matters is not the recommendation but the premise behind it: according to the same piece, LLM operations are currently landing on top of existing DevOps and MLOps workflows without a clear owner. ^[2]

The source is direct about why this is not MLOps with a new sticker. Large language models cost substantially more to fine-tune and serve than classical models. ^[4] Evaluation is fuzzier, because accuracy scores do not capture safety, tone or trustworthiness. ^[5] The operational load is continuous rather than episodic: models drift, prompts stop working, integrations need constant tending. ^[6] And the primitives are new ones - prompt versioning, vector stores, RAG pipelines, inference endpoints. ^[7] What is being operated is a system that chains prompts and queries vector databases, judged on tone and safety rather than accuracy alone, which is why the old train-test-ship shape no longer fits. ^[1]

The precedent is close at hand. MLOps teams already built a parallel stack - MLflow, Kubeflow, Weights & Biases - precisely because DevOps tooling never anticipated data versioning or drift monitoring. ^[8] The source's warning is that without intervention LLMOps becomes a third parallel stack, invisible to whoever governs the rest. ^[9] The failure mode it names is not a hallucinating chatbot but a team standing up its own RAG pipeline against an unreviewed vector store, outside any platform governance. ^[10] That is the same pattern as the DevOps-versus-platform split: a capability gets built outside the platform because the platform was not ready, and it never gets folded back in. ^[11]

The proposed fix is unglamorous and therefore plausible. Bryant's framing, via the CNCF Platforms Whitepaper, treats fine-tuning jobs, vector databases, prompt registries and inference endpoints as just another platform capability, owing the same API, versioning and ownership as anything else. ^[12] The post argues the tooling already exists in the CNCF ecosystem: Backstage at the product layer, Crossplane at the infrastructure layer, Kratix, KubeVela or KusionStack in the middle, exposing LLM pipelines through the same self-service interface as everything else. ^[13] The operational advice follows from that: build the governed self-service path for inference endpoints, prompt deployments and fine-tuning jobs before teams build their own ^[14], and enforce cost limits, data residency and model access controls at request time rather than discovering them on the cloud bill. ^[15]

Note what the article does not resolve. It addresses platform engineers, MLOps and AI teams, and platform leadership in turn, and assigns none of them the accountability. ^[19] For leadership its own reformulation is that the question is not who owns the pipeline but who owns which layer, and whether anyone is coordinating across them. ^[17] Meanwhile the audit trail obligation is already live, with regulators wanting to know what changed and who approved it. ^[16]

What to watch: the CNCF TAG App Delivery Platforms Working Group, which the post says is actively working on this. ^[18] Worth knowing that the post itself was drafted with an AI tool, KewBot, and edited and approved by a human named Drew. ^[20]