Where should agent instrumentation end? Devs weigh 3 designs for verifying external state
Sensitive-Parsnip-12 · reddit · 2026-11-15
A Reddit developer poses a practical agent-engineering question: after an agent calls an API to issue refunds, update records, or trigger jobs, a 200/202 response doesn't guarantee the change stuck — it may fail later, roll back, or never happen. How do you record final state and tie it back to the original operation and its retries?
Three candidate architectures are proposed for discussion:
- Give a small SDK a callback that reads the external system after the action and handles recording and linking results
- Keep all verification logic in your own app, with the SDK only logging what was checked, the result, and the owning operation
- Skip the SDK: custom OTel spans/events plus a separate verification worker
Assuming all three produce debuggable evidence and none require sending credentials to third parties, the poster asks which approach belongs in prod — and what would block adoption: latency, security reviews, eventual consistency, or extra dependencies. The underlying question: where should instrumentation end and application logic begin?
More from coding & agent
- Two prompt audits worth running on your Claude Code setup — RLanceMartin · 2026-11-15
- Weekend reads: HF decision models, llama.cpp 1.0, 3D fine-tuning guide and more — kalyan_kpl · 2026-11-15
- Dev ditches Linear for Flywheel, a graph-based tool for mapping SWE decisions — tensorqt · 2026-11-15
- Solo founder claims $6,000 in a week running an internet business with a team of AI agents — CustomerFearless2294 · 2026-11-15
- Gemini CLI docs PR fixes stale Zed flag and wrong ACP expansion in CLI reference — DZH166 · 2026-11-15
- Two AI agent teams given $150 in DoorDash credits compete to decorate booth at Takeoff DC — lfschiavo · 2026-11-15