Direct API, SDK, and Framework Trade-offs
Direct provider APIs offer control and make request semantics visible, but require more orchestration code. An SDK or AI application framework can simplify streaming, schema outputs, tool calls, provider switching, and UI integration. Framework abstractions may evolve quickly and may not expose every provider capability immediately.
Choose based on required capabilities, team familiarity, debuggability, lock-in tolerance, and maintenance. Keep business logic and tool policy in your own modules so changing a framework does not require rewriting domain rules. Pin versions, read migration notes, and test upgrades against evaluations.
Layered integration design
Product / domain logic
-> application AI interface
-> provider adapter or framework
-> provider API
-> model💡 This separation keeps business rules independent of framework-specific APIs. Expose only the capabilities the product needs and make provider changes measurable through evaluations.
Key Takeaways
- Use the simplest abstraction that meets requirements.
- Keep policy and business rules in application code.
- Pin versions and test upgrades with regression evaluations.
Knowledge Check
What is a good reason to place business logic outside a framework-specific AI chain?