Less Registration, Better Boundaries: Discovery and Model Security
The final integration work for v1.7.1 removes two kinds of accidental complexity: manually listing assemblies that are already referenced, and making in-process runtime services behave like remote administrative clients.
Reference the Project, Discover the Agent
AddFabrCoreServer and AddFabrCoreServices now start from the application assembly and walk referenced FabrCore dependencies. Agents, plugins, tools, and provider registrations in normal project or package references are available without repeating their assemblies in startup code.
AdditionalAssemblies still exists for the case its name actually describes: runtime-loaded code outside the dependency graph. The resolved RegistryAssemblies collection is then the exact scope used for registration and registry construction, so discovery does not differ depending on which subsystem asks.
Runtime Resolution Stays In Process
An agent choosing its configured model should not call its own Host over HTTP. In v1.7.1 the in-process model resolver reads directly from the active model-configuration store. That avoids loopback networking, duplicated authentication plumbing, and startup races when the Host is not yet listening.
The direct path still uses the same active configuration that administrators manage. The difference is trust location: server code already inside the process uses the service; callers across a network cross an authenticated API boundary.
Administration Is Explicitly Protected
Remote model-configuration routes are protected by the FabrCoreAdmin policy. An authorized SDK client supplies FabrCore:AdminAuthentication:ApiKey; ordinary user and agent traffic does not receive that credential.
This is especially important now that model configuration carries reasoning effort, context windows, compaction thresholds, and run-safety budgets. Changing a model can change cost and operational behavior across many agents. It belongs behind an administrative boundary and in an audit trail.
Most applications can simplify startup to builder.AddFabrCoreServer(). Keep explicit dynamic assemblies only where the runtime truly cannot see a compile-time reference.