Reading the project.
The architectural ideas Beach is built around, stated once and precisely.
Beach in one paragraph.
Beach is an application scaffold whose interior is protocol-agnostic and whose edges are protocol plug-ins. Its central architectural commitment — that the event router and the manifest registry are the only components that see both sides of a call — means inbound and outbound protocols are interchangeable parts. A Beach application speaks whatever protocols its edges are mounted with today, and whatever protocols its edges are mounted with tomorrow, without any change to participants, domain logic, or routing rules.
The guarantee Beach offers its adopters is not compatibility with any particular standard, but durability across all of them.
The interior speaks only in events, manifests, and participants. The edges speak only in protocols.
Nothing in the middle sees protocols; nothing at the edges sees other edges.
That rule, applied consistently, is the whole architecture. Every principle — router-as-boundary, strict respond(), explicit turn states, declarative routing — is a consequence of the invariant rather than a starting premise.
A Beach application is two faces
and an opaque middle.
Inbound
Appears as an MCP server to one caller, an A2A peer to a second, an A2UI producer to a third, a webhook receiver to a fourth, an email correspondent to a fifth. Peers see the open protocols they already speak. Beach is not visible to them.
Outbound
Reaches downstream to MCP servers, A2A peers, REST APIs, GraphQL schemas, gRPC services, SQL databases, filesystems, message queues — through a single plugin contract. Actors and handlers do not know which protocol they are calling.
Middle
The router and the manifest registry. They see events and manifests, not protocols. The middle is opaque in both directions by construction.
Articles and talks.
Pieces by the maintainers on the ideas above, and how they apply in practice.
-
Architectural erosion happens through yes, not no
Architectures do not fail because bad requests are approved. They fail because reasonable ones are, again and again, until the thing that made the architecture valuable is gone. A pattern especially visible in AI-enabled applications right now.
-
Shiny protocols and slick decks: how the wrong AI architecture gets chosen
The two most reliable ways to make a wrong technology decision about AI — engineers chasing the protocol of the month from below, and executives buying a platform pitch from above — are currently happening at the same time, in the same organisations.
-
Ship fast, survive long: why Beach is a maintainable head start
The choice between shipping fast and building something maintainable is a false one — in AI, in particular, the applications that ship fastest often survive shortest. Beach is the scaffold that lets you do both.
-
The asynchronous problem nobody names
Every AI application hits the same wall. A call is made, some of the result arrives quickly from one place, some later from another, and the last part comes back hours from now from a human. Most codebases handle this badly and nobody has a name for the primitive they are missing.
-
The LLM is not the centre of your application
Putting the LLM at the centre of an AI-enabled application seems natural, because that is the shape every framework and tutorial encourages. It is also the reason most of these applications will not survive the next shift in AI approach.
-
Your AI application has the wrong shape
Most AI-enabled applications being built today will need to be rebuilt in eighteen months — not because the code is bad, but because the shape is wrong. Here is the shape that survives.