# Build an AI application (/docs/get-started/build-ai-application)



This path is for AI engineers, software engineers, and solution teams building an application on BullSequana AI.

## Outcome [#outcome]

You can authenticate to the BSQAI API, make a model request, add the capabilities required by the use case, deploy the application, and retain enough telemetry to operate it.

## 1. Choose the smallest useful application shape [#1-choose-the-smallest-useful-application-shape]

| Need                                       | Start with                                                 |
| ------------------------------------------ | ---------------------------------------------------------- |
| text generation or transformation          | model access through the BSQAI API                         |
| answers grounded in organizational content | model access plus [RAG](/docs/ai/rag)                      |
| extraction or classification from files    | [Docling document conversion](/docs/ai/components/docling) |
| tools and multi-step actions               | model access plus approved agent and tool interfaces       |
| speech input or output                     | model access plus the supported speech path                |

Build one complete request before combining multiple capability areas.

## 2. Establish authentication [#2-establish-authentication]

Use a user token for interactive user-delegated behavior and an approved API key or service identity for application-to-application behavior. Preserve the tenant and team boundary of the caller.

[Use local models via API](/docs/develop/use-local-models-via-api) documents base URLs, credentials, model discovery, the Responses API, and client configuration.

## 3. Discover and call a model [#3-discover-and-call-a-model]

Do not hard-code an internal serving endpoint. Discover the model names exposed through the BSQAI API, select one appropriate for the workload, and implement request timeout and error handling.

Use [Model as a Service](/docs/ai/model-as-a-service) for model lifecycle context and [BSQAI API](/docs/ai/components/bsqai-api) for the product-facing integration boundary.

## 4. Add knowledge, documents, or tools [#4-add-knowledge-documents-or-tools]

For RAG, define source ownership, ingestion, chunking, embedding, retrieval, citations, and permission behavior. For document processing, separate synchronous application requests from long-running processing jobs. For tools, constrain which actions the calling identity can perform and retain an audit trail.

Add only the capability required by the use case; each additional integration expands the security and operational boundary.

## 5. Deploy the application [#5-deploy-the-application]

[Deploy apps on the platform](/docs/develop/deploy-apps-on-the-platform) covers packaging, runtime configuration, identity, network exposure, health checks, and GitOps delivery.

Your deployment definition should include:

* immutable application image and version
* non-secret configuration separated from credentials
* resource requests and limits
* startup, readiness, and liveness behavior
* network and ingress requirements
* telemetry and an owned rollback path

## 6. Operate the result [#6-operate-the-result]

Measure request rate, latency, errors, model behavior, retrieval quality, and downstream dependency failures. Keep application telemetry tenant-aware without recording prompts, retrieved content, or responses unless the approved use case explicitly requires it.

Use [Troubleshooting](/docs/troubleshooting) for common integration failures and [Foundation observability](/docs/foundation/observability-and-audit) for the platform signal path.

## You are done when [#you-are-done-when]

* the application uses the BSQAI API rather than an internal component endpoint
* authentication and tenant boundaries are tested
* one end-to-end user outcome works in the target environment
* failures are visible and actionable
* deployment, rollback, and ownership are documented