Choosing Capabilities Under Real Constraints
OpenMontage's provider problem is not “Which vendor is best?” It is “Which capability is available, suitable for this promise, affordable under this plan, and safe to change if the first choice fails?” This chapter explains how the live registry, scored selectors, budget lifecycle, and composition runtimes turn that question into an explicit decision. The result is not a universal ranking. It is a defensible choice for a particular brief and machine.
That distinction matters because a repository can list a provider without making it usable. A service may require a missing credential. A local model may need hardware the user does not have. A renderer may be installed but express the wrong visual grammar. A preferred provider may be available but a poor fit for motion, reference conditioning, language, or cost. OpenMontage's architecture is strongest when it treats these as different facts rather than collapsing them into a single “supported” label.
A live provider menu is different from a static list
A static list answers what the project has integrated. The live registry answers what the current run can use. OpenMontage's registry discovers concrete tool classes, reads their contracts, checks dependencies, and groups the results by capability and provider. Its preflight menu can report configured versus total providers, available runtimes, missing dependencies, and setup instructions. That is more useful than a README table because availability is a property of the machine and environment at this moment.
The difference becomes clear with a simple case. A brief may call for narration, images, and a final render. The repository may contain several narration providers, multiple image paths, and both Remotion and HyperFrames. But if the current machine has only local composition and an offline voice installed, the honest plan is not “all providers are available.” It is a local path with specific quality, latency, and setup characteristics. The registry exposes that envelope before the agent makes a creative promise.
The menu also separates capability from provider. A request for text-to-speech is a capability; a particular cloud voice or local engine is one implementation. A request for video generation is different from a request for video composition. A selector can route among tools inside one capability family, but it should not pretend that an image generator is an acceptable substitute for a motion-required video operation.
That distinction is useful even when the numbers look healthy. “Five of eight image providers configured” says something about breadth, but it does not say that any of those five can preserve a product reference, support the desired aspect ratio, or fit the approved budget. Conversely, one configured local tool may be enough for a narrow brief. The menu is a starting point for reasoning about the task, not a score of the user's setup.
Selectors provide the decision layer above the registry. They discover providers at runtime rather than maintaining a fixed order. The selected tool returns the chosen provider, a reason or score, alternatives considered, and the fallback tools that apply to the input. This makes the result explainable: the agent can tell the user not only what it selected, but what other available paths were considered.
An explicit user preference still matters. The video selector can honor a preferred provider when its score is sufficiently close to the leading candidate. But the preference is not an unconditional command to ignore the task.