Where the loop lives

A key design decision: does your orchestrator drive the loop, or does the provider's SDK? There are two common arrangements:

• You own the loop explicitly: your code does the repeat and decides when to stop. Maximum control and visibility; you can inject logic between turns.
• The provider SDK owns the loop and calls back to you for tool execution: you supply a "run these tools" function and the SDK iterates internally.

A clean hybrid (and a good default) is to own a thin loop that delegates tool execution through a callback, so your orchestrator stays declarative while the provider-specific iteration is encapsulated. Either way, the control (the cap, the termination logic, the event recording) should be yours, not buried in a library.