The difference is not the number of Plugins
Many systems can add a tool or callback. DSH is different because the Cordis plugin model runs through the whole Harness: core services, providers, policies, UI glue, and the agent loop all follow the same Context, inject, event, and effect lifecycle.
A Plugin is therefore not an optional extension slot. It is the basic unit of application composition, and the same mechanism handles both adding behavior and replacing foundational implementations.
Configuration is executable architecture
cordis.patch.yml describes which rows to mount, which implementations to use, and what configuration each Plugin receives. Stable row ids and layered precedence let a Harness be changed locally without forking the whole application.
The final tree can be dumped, compared, validated, and rebuilt. Authors are tuning an explicit runtime topology, not only editing source files.
Replaceability and reversibility share one ownership model
Service injection separates Consumers from Providers, Context scopes let different Agents receive different implementations, and effect disposers reclaim registrations and resources during a switch or unload.
Together, these mechanisms turn modularity from a source-directory convention into runtime semantics for isolation, replacement, and rollback.
Profiles turn architecture choices into a distributable result
Cordis explains how to compose a runtime safely. Bundles package composition layers. Profiles and the Plugin Hub then make the tuned result transferable to another person.
The real differentiator is not compressing several files. An expert absorbs the complexity of provider selection, Plugin composition, order, configuration, and validation once. Product, operations, research, or customer teams can then use the same versioned Agent Harness without becoming Cordis experts.
Cordis Plugin
-> Bundle patch layer
-> Profile composition
-> versioned Hub Release
-> one-command applicationThe Hub amplifies the ecosystem without copying the Runtime
The Plugin Hub discovers and indexes Bundles, validates manifests, presents compatibility and provenance, generates installation paths, and captures Profiles as verifiable Releases. Local DSH still owns dependency resolution, patch composition, and lifecycle execution.
That boundary matters. The Hub makes distribution more trustworthy and approachable without introducing a second composition model. Authors and recipients still run the same DSH/Cordis system.
The mechanism does not hide trust or environment requirements
Composable does not mean every composition is safe or compatible. A Release should still pin runtime and dependency versions, record provenance and verification evidence, and disclose required local inputs. Secrets, account permissions, and external service state remain in the recipient's environment.
DSH + Cordis does not remove those real constraints. It makes the code, configuration, ownership, and distribution boundaries explicit enough for teams to inspect and manage them.