A demo answers one question
A demo asks, “Can this do something useful?” Production asks harder questions: who owns it, what data may it handle, when is it available, how quickly can it recover, how do users get help and how do we know it is behaving badly?
An agentic feature has the same obligations as any other service. The model does not make it exempt from normal engineering.
Name the service promise
Define a service boundary first. For example: “The incident assistant creates a cited summary for an on-call engineer.” It is not “AI helps with operations.” Then state what a successful request looks like, who may use it, its important dependencies and what happens when the model or a tool is unavailable.
An SLO is a measurable service promise over time. An error budget is the room allowed for missing that promise. They turn “reliable enough” into a conversation an engineering team can have.
user need → service boundary → measurable objective → alert and response
Quality deserves an honest boundary
Availability and latency do not prove that an answer is useful. Define a separate quality evaluation for the task, such as citation completeness or reviewer acceptance. Do not blend it into an uptime number just because it is hard to measure.
Try it
Run workbench production in the cloned Workbench. It produces a trace carrier and metrics from a real local process—not a production claim. Then write one sentence that names your own agentic service, user and artifact. Add two promises: one operational promise, such as successful requests within a time target; and one quality guardrail, such as every operational recommendation having cited evidence. Notice that both need owners.
Keep this with you
Production begins when somebody must rely on the system on a bad day.