> ## 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.

# One API for Models, Data, and Agent Tools

> Understand what AIsa unifies across models, live data, Agent Skills, actions, discovery, and billing—and what remains capability-specific.

AIsa gives AI agents a common resource and transaction boundary for supported models, APIs, data services, Agent Skills, and paid capabilities. This reduces the number of separate provider accounts, credentials, discovery formats, and billing relationships an application must manage.

“Unified” does **not** mean every capability uses one identical endpoint, request schema, price unit, or authorization method. It means an agent can begin from one product and account boundary, discover the appropriate surface, and then use the exact contract for that capability.

## What AIsa unifies

For supported capabilities, AIsa can provide a shared starting point for:

* **Product discovery:** identify whether the task needs a model, Skill, direct API, authenticated action, or payment flow.
* **Account access:** use an AIsa account and API credential for documented model and API surfaces.
* **Machine discovery:** inspect the Agent Card, MCP manifest, OpenAPI specification, and llms resources.
* **Usage visibility:** review billable model and API consumption through AIsa usage and billing surfaces.
* **Technical routing:** move from a task goal to the smallest relevant documentation and API contract.

Authenticated actions may also require a provider-specific OAuth connection or delegated credential. Possession of an AIsa API key does not by itself authorize an external write.

## What remains capability-specific

Each resource can still have its own operational contract:

| Concern                      | Why it can differ                                                                             |
| ---------------------------- | --------------------------------------------------------------------------------------------- |
| Endpoint and request schema  | Model inference, search, financial data, and social APIs accept different inputs              |
| Response semantics           | Generated text, source records, market data, and action receipts require different validation |
| Billing unit                 | Usage may be measured by tokens, requests, media outputs, or another documented unit          |
| Availability and rate limits | Capabilities can depend on different upstream providers and quotas                            |
| Additional authorization     | Writes may require OAuth, account connection, or explicit user confirmation                   |
| Retry behavior               | A read can often be retried differently from a write or paid request                          |

Use the [OpenAPI specification](https://aisa.one/openapi.yaml) and exact documentation page as the implementation source of truth.

## Resource types

| Resource                     | Use it when                                                                 | Start with                                                              |
| ---------------------------- | --------------------------------------------------------------------------- | ----------------------------------------------------------------------- |
| AI model inference           | The task is reasoning, generation, coding, vision, or media processing      | [Models](/docs/guides/models)                                                |
| Live data or specialized API | The workflow needs current, structured, provider-backed information         | [API Reference](/docs/api-reference)                                         |
| Agent Skill                  | The outcome is reusable and benefits from an established workflow           | [Agent Skills](/docs/agent-skills)                                           |
| Authenticated action         | The agent must change an external system                                    | [Capabilities by Interface](/docs/by-interface#authenticated-actions)        |
| Machine discovery            | A client must inspect capabilities and contracts programmatically           | [Agent Discovery](/docs/guides/agent-discovery)                              |
| Programmatic payment         | A supported capability must be purchased at runtime under explicit controls | [Machine Payments for AI Agents](/docs/concepts/machine-payments-for-agents) |

## Example: research followed by an approved action

A single task can cross several surfaces without treating them as interchangeable:

1. Use [Capabilities by Goal](/docs/by-goal) to select a research path.
2. Call a search or data API to retrieve current evidence.
3. Use a model to compare and synthesize the evidence.
4. If the result should be published or sent, classify that step as an authenticated write.
5. Verify the connected identity and request confirmation where required.
6. Inspect usage and the external result separately.

The common boundary reduces integration fragmentation. The application still owns task state, evidence requirements, authorization policy, retry logic, and result verification.

## When one interface is useful

Consider this architecture when:

* An agent needs models plus current external data.
* A product would otherwise maintain several provider integrations.
* Multiple agent clients should reuse the same Skills or discovery resources.
* The workflow needs shared usage visibility across different capability types.
* New resources should be added incrementally without redesigning the whole agent.

## When direct integrations may be simpler

A direct provider integration can be the better choice when:

* One stable model or API solves the complete task.
* The team needs a provider-specific feature not exposed through AIsa.
* Existing reliability, compliance, procurement, and billing processes already cover the provider.
* An additional routing or billing dependency is not desirable.

AIsa is not an all-or-nothing architecture. Start with the smallest useful surface and add other resource types only when the workflow needs them.

## Next steps

* [Agent Skills vs. Direct APIs](/docs/concepts/agent-skills-vs-direct-apis)
* [Model Gateway vs. Agent Capability Layer](/docs/concepts/model-gateway-vs-capability-layer)
* [AIsa Architecture and Integration Boundaries](/docs/evaluate/architecture)
* [When to Use AIsa](/docs/evaluate/when-to-use-aisa)
* [Capabilities by Interface](/docs/by-interface)