I put a runtime supervisor around a real LangGraph agent — it rejected a tool call before execution and the model replanned

I have been building ARK, runtime supervision layer for tool using AI agents. The idea is simple: keep your model, keep your agent framework, keep your tools, put ARK around the runtime. I finally got it working around a real LangGraph agent using a real OpenAI model. For this test I intentionally created a conflict: the user prompt asked for the cheapest flight, while the runtime policy required the rank-2 option. The point was not to prove that rank-2 is “better”; it was to test whether ARK could enforce a runtime constraint without taking control of the agent. The actual sequence was: OpenAI model authors: book_flight(option="A") → ARK checks it → REJECT → A executed = false LangGraph feeds ARK's feedback back to the model OpenAI model authors: book_flight(option="B") → ARK checks again → ALLOW → B executed = true The important part is that ARK did not rewrite A into B itself. The raw model-authored tool calls were: turn 1: book_flight(option="A") turn 2: book_flight(option="B") And the actual side effects were: real bookings: ["B"] A executed: false B executed: true Retry state was maintained by ARK’s Go runtime, while LangGraph continued to own the model, planner, tools, and execution loop. I also tested ARK in observe-only mode around LangGraph: model_call → tool_call → complete where LangGraph reports model/token/tool information and ARK builds the decision trace and derives telemetry around the run. The SDK isn’t public yet(soon today or tomorrow may be), I am still hardening it before release. Live testing already caught a model-pricing resolution bug that our deterministic tests didn’t expose, which I’m fixing before shipping. Question for people running tool-using agents in production: would you want a supervisor like this in the execution path? What would make you trust it or refuse to use it?