AGKit vs Direct provider SDKs
Choose AGKit when you want model capabilities connected to actions inside your app, with routes, profiles, credentials, and spending controls managed in Cloud.
Provider SDKs expose model capabilities, including tool calling. For application tools, your code performs the requested action and returns its result.
 AGKit | Direct provider SDKs | |
|---|---|---|
| Application stack | Swift, Android, React Native, and Web; one Cloud backbone | Provider-supported languages and APIs |
| Application actions | Agent runtime, tool contracts, permission hooks, and cancellation | Tool calls integrated with your application code |
| Configuration | Cloud-managed model tiers, credentials, and agent profiles | Provider-specific API and model configuration |
| Production controls | End-user identity, project/user budgets, and configured attestation | Your backend and provider account controls |
| Application responsibility | Tool implementation, state validation, approvals, and actual undo | Your tool lifecycle, user identity, and client integration |
Choose your platform and access path for SDK availability and setup. Guard and confirmation support depends on the SDK execution path you integrate.
Where a provider SDK fits
One provider meets your needs, or a provider-specific feature is central to your product. Use its SDK and build the surrounding application and operational workflow.
Where AGKit fits
You want the app to request an intent tier while Cloud manages the model binding, agent profile, credentials, and budgets. The runtime connects model-selected tools to your app’s handlers.
What your team implements
Validate tool arguments and current state, request approval where needed, and return the actual result. The application remains responsible for publishing changes and implementing reversible operations.