Meridian Line is assembling the deployed system for its port-operations copilot: a retrieval step over the circulars Vector Search index, a summarization step, and a separate charter-desk assistant that has nothing to do with circulars. Should these be deployed behind one shared Model Serving endpoint or separate endpoints, and why?

Deploying genuinely distinct applications — different traffic patterns, independent release/versioning cadences, and different access-control requirements — behind separate Model Serving endpoints is the appropriate architecture, because it isolates blast radius: promoting a new version, hitting a rate limit, or debugging an incident on the charter-desk assistant has no effect on the port-operations copilot's endpoint, and vice versa. Independent endpoints also let each application be scaled, monitored, and governed (Unity Catalog permissions) according to its own needs rather than a shared compromise. Claiming one shared endpoint is 'always cheaper' ignores that cost depends on the actual capacity/traffic profile of each workload — coupling unrelated workloads for a hypothetical cost saving trades away isolation for a benefit that isn't guaranteed and often isn't real once contention and blast-radius incidents are counted. There's no platform limit of one Model Serving endpoint per Unity Catalog catalog — endpoints and catalogs aren't related that way, and this constraint is fabricated. The claim that Vector Search results and a generated summary can't coexist behind one endpoint response is also fabricated — a chain or agent can retrieve and then generate within a single served model's response, which is exactly how RAG applications are typically composed; that's not the actual reason to separate these two, unrelated, applications. Exam framing: architecture-level endpoint separation is part of sequencing a real deployment, distinct from the mechanics of any single endpoint's configuration.