One space can hold applications that are provided by many different servers and services

The mount resource will specify the server which is hosting it.

Pros:

Flexible

Easily supports the existing agent server architecture

Cons:

Complicated

Unclear how to handle local app servers

The space specifies the host. All applications run on that host

The mount resource specifies what app should run on the host

To use the apps, communicate with the space server as defined by the siteURL

This has addressing benefits. For example if you have a tool at my-app/action , then you can directly hit that action at the logical URL.

Pros:

Intuitive, simple to understand

Cons:

Can't scale well, if all apps are proxied through the same host

Difficult to adopt because agent server is already decoupled

Unclear how to handle local app servers

The space server remains in charge. API endpoint on mysite.com/:apps allows you to query the apps on the space. If there are different servers, the endpoint will specify.

By default, use Option 2 approach. The app will run on the site server by default.

Remove the space-level configuration for agent servers, as this should not be needed once we have proper mounting.

An app mount (or agent mount) may optionally specify a server, otherwise the space's server will be used.

Pros:

Simple by default, flexible and scalable as needed

Easy adoption path

Cons:

Unclear how to handle local app servers

In any case, we should remove the agent server field(s) from the space configuration