Who on-calls an AI? This is the unresolved crisis of agent ownership

The New Stack’s point is blunt: the hard part of AI agents isn’t the model choice, it’s ownership. A system can be chatting away, retrying failures, burning more tokens, and still be nobody’s clear problem until an incident lands in the middle of the night.

That’s why the article keeps pushing past prompts and retrieval into the unglamorous stuff: named ownership, escalation paths, limits, logs, and a sharp line between advice and action. An agent that can read telemetry is one thing. An agent that can restart services or deploy code without a human gate is another, and the second one needs real controls, not optimism.

The suggested pattern is practical rather than dreamy. Treat the agent like a production service with ownership metadata, put it behind an explicit allowlist, enforce budgets for steps and tool calls, and wrap model calls so they can be traced back with request IDs, latency, and failure states. If the agent fails, the system should escalate cleanly instead of improvising its own drama.

The article is especially firm on high-risk actions. Recommendations can come from the agent; production changes should not. It also argues for separate liveness and readiness checks, so orchestration can tell the difference between a process that is alive and a service that can actually do its job.

The ending is the right one: every team needs a 2 a.m. runbook, and the question that matters most is what happens if the agent is disabled. If the answer is panic, then the agent was never really a service. It was a liability with better branding.