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

# Architecture

> How a MESO request travels from client to model and back.

## Request path

```
Client  →  Edge function (thin index.ts)
        →  Shared capability handler
        →  Provider seam
        →  Model backend (Bedrock Flows | OpenAI | Vertex/ADK)
        →  Transformation layer
        →  Structured JSON response
```

Each endpoint file is deliberately tiny — it imports a handler and serves it.
All domain logic lives in a shared capability module, so the same behaviour is
reachable from any endpoint name. Legacy endpoint names remain as aliases.

## The provider seam

Model backends sit behind a provider interface rather than being called directly
from capability code. This is what lets a capability move between backends
without its request or response contract changing.

| Backend | Used for |
| - | - |
| AWS Bedrock Flows | Flow-managed generation, knowledge-base-enhanced planning |
| OpenAI | Chat, helper calls, transcription, hero imagery |
| Google Vertex AI (ADK) | Adapter seam reserved for migration |

> [!NOTE]
>
> Provider choice is a server-side concern. Clients never select a model, and the
> response contract does not change when the backend does.

## Structured output

Capabilities return **structured JSON**, not prose. Where a payload also has a
rendered form, the structured content is authoritative and the renderer is a
consumer of it — never the other way around.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.