> ## Documentation Index
> Fetch the complete documentation index at: https://aisa.one/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# When to Use AIsa

> Evaluate whether AIsa fits a workflow that needs models, live data, Agent Skills, discovery, actions, or usage-based billing.

AIsa is a good candidate when an agent needs more than one provider integration and the application benefits from a common model, data, Skill, discovery, or billing surface.

## Consider AIsa when

* The agent needs model inference plus current external data.
* The application would otherwise maintain several provider keys and API contracts.
* A reusable Skill can replace repeated endpoint orchestration.
* The agent needs to discover capabilities through Agent Card, MCP, or OpenAPI.
* The workflow needs usage-based access to multiple supported capabilities.
* The team wants to start with model inference and add data or Skills incrementally.

## AIsa may not be necessary when

* One model provider fully covers the workload.
* One specialized API already solves the complete problem.
* The team intentionally owns every provider integration and billing relationship.
* The workflow has no need for current external data, reusable Skills, or machine discovery.

Using AIsa is not an all-or-nothing decision. A project can use the model gateway first and adopt other surfaces only when the workflow requires them.

## Fit checklist

| Question                                                  | If yes                                                                                |
| --------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| Do you need more than one model family?                   | Start with [Models](/docs/guides/models).                                                  |
| Do you need current web, market, social, or company data? | Choose a [Skill or direct API](/docs/by-goal).                                             |
| Do you need an end-to-end reusable task?                  | Review [Agent Skills](/docs/agent-skills).                                                 |
| Do you need custom endpoint sequencing?                   | Use the [API Reference](/docs/api-reference).                                              |
| Do you need external writes?                              | Review [Capabilities by Interface](/docs/by-interface) and authorization requirements.     |
| Do you need runtime purchasing?                           | Review [Machine payments](/docs/concepts/machine-payments-for-agents) and budget controls. |

## Evaluation sequence

1. Define the user outcome and required evidence.
2. Choose the smallest suitable interface.
3. Check current availability, pricing, authentication, and rate limits.
4. Test a read-only or low-risk request.
5. Decide which data, side effects, and costs the application will own.
6. Document fallback and failure behavior before production use.

## Main trade-offs

A common capability layer can reduce integration duplication, but it also introduces a dependency on an additional routing and billing layer. Evaluate:

* Latency and reliability for the required route.
* Whether the live catalog supports the exact model or API needed.
* Data handling and upstream-provider terms.
* Cost visibility and budget controls.
* Migration and fallback requirements.

## Start here

* [Agent Quickstart](/docs/agent-quickstart)
* [Capabilities by Goal](/docs/by-goal)
* [Capabilities by Interface](/docs/by-interface)
* [Security](/docs/guides/security)
* [Pricing and Billing](/docs/guides/pricing)
* [Service and capability discovery](/docs/guides/agent-discovery)