Yes. There are several examples of plugin architectures built around the Actor Model, although they differ in how closely they treat plugins as actors.

The most interesting examples for Seed are Erlang/OTP, Akka, and Elixir’s Broadway.

1. Erlang/OTP — The closest architectural match

Erlang/OTP Design Principles⁠

Erlang’s OTP framework provides many of the primitives needed to build an actor-based plugin system.

Each plugin can be implemented as an independent actor or group of actors, with:

Identity: An addressable process.

State: Private state managed by the actor.

Messages: Communication through asynchronous messaging.

Lifecycle: Start, stop, restart, and upgrade.

Supervision: Automatic recovery from failures.

Isolation: A failing actor does not necessarily crash other actors.

For example, a document-processing application might look like:

Application

    │

    └── Plugin Supervisor

          │

          ├── Search Plugin (Actor)

          │     └── Handles document indexing

          │

          ├── Notification Plugin (Actor)

          │     └── Handles document events

          │

          └── AI Plugin (Actor)

                └── Handles agent requests

OTP provides gen_server for implementing stateful actors and supervisors for managing their lifecycle. These are building blocks rather than a complete third-party plugin marketplace.

2. Akka — Actor-based extensions

Akka Extensions⁠

Akka is particularly interesting because it has an explicit extension mechanism.

Extensions can:

Register functionality with an ActorSystem.

Initialize on demand.

Expose services to other components.

Integrate with the actor infrastructure.

However, Akka extensions are not necessarily actors themselves. In fact, Akka recommends actors for managing mutable state.

This distinction is important: an actor-based application does not automatically imply an actor-based plugin system.

3. Broadway — Pluggable actors for processing pipelines

Broadway documentation⁠

Broadway is an Elixir framework for concurrent data processing.

It uses actor-based processes to implement pipelines with interchangeable producers.

For example:

Kafka Producer ──┐

                 │

SQS Producer ────┼──> Processing Actors

                 │          │

RabbitMQ ────────┘          ▼

                      Output / Storage

Broadway supports custom producers, supervision, backpressure, and fault handling.

This is a concrete example of a pluggable architecture built on actors, although its focus is data processing rather than general application extensibility.

4. How I would apply this to Seed

I would explore a model where a plugin is an actor that exposes capabilities through messages.

For example:

Seed Runtime

     │

     ├── Document Actor

     │

     ├── Plugin Registry

     │       │

     │       ├── Search Plugin

     │       ├── Ontology Plugin

     │       └── AI Agent Plugin

     │

     └── Event Router

Each plugin would have a contract:

interface Plugin {

  id: string

  capabilities: string[]

  subscriptions: string[]

  receive(message: Message): Promise<void>

}

A plugin could subscribe to events:

document.published

document.updated

comment.created

And expose capabilities:

search.query

ontology.validate

agent.summarize

Other actors would invoke those capabilities by sending messages, rather than calling plugin functions directly.

An important distinction

I would separate three concepts:

A plugin can be implemented as an actor, but the two concepts are not equivalent.

Also, message passing and event-driven programming are related but different. Actors can receive commands, queries, and events. Not every message is an event.

My recommendation

For Seed, I would study Erlang/OTP’s supervision and lifecycle model first.

The architecture could be especially interesting if plugins were independently managed actors with explicit capabilities and permissions.

One important caveat: actors provide concurrency and fault isolation, but they do not automatically provide security isolation. Third-party plugins would still need sandboxing and capability enforcement.

The architectural question I would investigate is whether a plugin should be a single actor or an entire supervised actor system.

The second option is more powerful: a plugin could create its own actors, manage internal state, and expose only a small set of capabilities to the rest of Seed.