When a lab ships a frontier model, the interesting part is rarely the leaderboard. It is the wrapper: monitors on tool use, evals that can block a response, and a deployment path that assumes the model will try things you did not type.
Most product agents I see in the wild do not have that wrapper. They have a system prompt, a tool list, and a CloudWatch log of the last fifty traces. That was survivable when the agent summarized tickets. It is less survivable when the agent can open a browser, call an internal API, or write to production.
What "monitoring" has to mean
Logging the prompt is not monitoring. You need a layer that can answer:
- Which tools ran, with which arguments, on whose authority?
- Did the trace violate a policy before the side effect landed?
- Can a human replay the decision without re-running the model?
If you cannot block a tool call, you do not have an agent platform. You have a chatbot with credentials.
A shape that holds up
- Tool allowlists per environment, not one god-mode MCP bag.
- Idempotency and dry-run on anything that mutates money, access, or customer data.
- Offline evals on a frozen fixture set before you promote a prompt or a model.
- Human-owned kill switches. A feature flag beats a Slack apology.
I will use models that write code and draft designs. I will not let an unobserved loop hold production keys.
Takeaways
- Treat tool calls as production RPCs.
- Put policy in front of the side effect, not in a retrospective doc.
- If the lab needed a monitor to ship the model, your product needs one to ship the agent.