Architecture - MESO Docs

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

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.