1.13 The architecture of participation

Book 2 · The Delegation ContractChapter 1 · section 13 of 14

A pattern runs through every tool in this chapter, and it deserves a name. Tim O’Reilly named it in 2004 writing about open source: the architecture of participation, meaning a system designed so that anyone can extend it without asking permission.61 He returned to the idea in 2026, arguing that the same pattern that let Apache beat Netscape and Microsoft is reappearing in AI. The parallel is not exact and it is close enough to take seriously. Closed labs are building excellent integrated appliances, and in tightly integrated services there is a real tendency for each new version to move more of the system’s behavior out of an editable layer and into the weights, where nobody outside the lab can see it or change it — which makes the model easier to rent and harder to treat as a swappable component.62

The open-source ecosystem has answered with the older pattern, the one that worked before: a small kernel with standard interfaces. Nous Research, behind Hermes Agent, is representative rather than unique here, because Nous builds both open-weight models and open-source agent infrastructure. The Hermes model lineage — fine-tunes aimed at steerability and tool-use reliability, running from Hermes 3 in 2024 through Hermes 4 in August 2025 to Hermes 4.3, a 36B model trained entirely on a decentralized network — demonstrates that open-weight models can compete for agentic workloads even when they are not topping every closed-lab leaderboard,63 and the Hermes Agent runtime discussed earlier is MIT-licensed and runs locally. What matters is that the model and the harness are separable. The model-agnostic harnesses make that literal: Goose, Pi, OpenHands, and Hermes Agent each run models from many providers, so replacing the inference engine is an adapter or configuration change plus revalidation, rather than a complete platform replacement. That separability is what O’Reilly means by participation — replacing a component without asking a vendor’s permission — and the Linux Foundation’s Agentic AI Foundation putting MCP, Goose, and AGENTS.md under a neutral roof is the same bet made at the protocol layer.

None of which is a romantic argument that open always wins the demo, because closed labs frequently ship more polish on day one. Drew Breunig, whom O’Reilly cites, calls the trade-off “trading diversity for reliability”: defaults good enough for a lazy prompt, and a tendency toward what might be called distribution convergence — participants using a common substrate producing increasingly interoperable outputs: the same fonts, card layouts, frameworks, and answers everywhere. For an orchestrator building something specific, that convergence is a problem rather than a feature, and open-weight models exist partly to give you another dial to turn. Breunig’s own move toward models like GLM and Kimi inside a custom harness — not only to save money, but because they take direction differently — is ordinary orchestrator reasoning.

A disclosure is in order here. This book surveys both proprietary and open-weight models, and as an author I will admit that I use the proprietary frontier models in my daily work. But I believe open-weight models are where the sustainable future of orchestration lives, because they are what make an orchestrated system portable and fully customizable, and this book is going to give them more attention than a strictly even-handed survey would. If you notice that weighting as you read, that is not an accident, and I would rather state it than leave you to infer it.

An orchestrator is responsible for the system: what it does, what it can reach, what evidence it produces, and who can stop it. Meeting that responsibility is easier when components can be inspected, modified, and replaced. A stack built entirely from closed components — closed model, closed harness, closed tools, closed memory — can still be genuinely useful; it is simply harder to audit end to end and harder to route around when a vendor changes the terms. An open system is not automatically safer. What it gives you is more places to intervene when something goes wrong, and more control over whether you can still govern the system five years from now.


  1. Tim O’Reilly, “The Architecture of Participation,” O’Reilly Media, 2004, https://www.oreilly.com/pub/a/tim/articles/architecture_of_participation.html; revisited in Tim O’Reilly, “Why Open Source Matters for AI,” O’Reilly Radar, August 2026, https://www.oreilly.com/radar/why-open-source-matters-for-ai/ (verified August 29, 2026).↩︎

  2. Drew Breunig, quoted in Tim O’Reilly, “Why Open Source Matters for AI,” O’Reilly Radar, August 2026, https://www.oreilly.com/radar/why-open-source-matters-for-ai/ — the “trading diversity for reliability” framing, and his move toward models like GLM and Kimi inside a custom harness for malleability. The “distribution convergence” phrasing in the text is this book’s, not a quoted term.↩︎

  3. Nous Research, https://nousresearch.com/ and https://nousresearch.com/releases. Open-weight models (Hermes lineage: Hermes 3, August 2024; Hermes 4, August 2025; Hermes 4.3, December 2025, trained on the Psyche decentralized network) and open-source agent infrastructure (Hermes Agent, MIT, February 2026). The organization’s own releases page lists continuous model publications from 2023 onward.↩︎