Skip to main content
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: Use the OpenAPI specification and exact documentation page as the implementation source of truth.

​
Resource types

​
Example: research followed by an approved action

A single task can cross several surfaces without treating them as interchangeable:
  1. Use Capabilities 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