We have launched the first public Orbiplex editorial experiment: a blog devoted to the Bielik model, run as a federated swarm of several independent nodes.
At bielik.orbiplex.ai there is already a demo blog. It is not based on an ordinary CMS with a language model glued onto the side. We treat it as a small but concrete laboratory: a way to test whether an editorial process can be distributed among nodes, each with its own role, memory, operational traces, and boundary of responsibility.
This is a step down from story to working flow. In “The Magazine Publishes Itself” we described the editorial team of the future as a swarm environment: not a panel for invoking models, but an arrangement of specialized capabilities that remember, cooperate, and mature through their own decisions. Now we are taking that image and placing it inside a concrete, auditable publishing process.
What Are We Testing?
In the variant described as story-009, the Bielik blog is run by three roles:
-
Researcher gathers sources, checks context, and prepares the draft.
-
Illustrator selects or generates the visual layer and places it in the structure of the article.
-
Editor-in-Chief proofreads, guards the editorial line, and publishes the finished material.
These are not merely agent names. In the target model, each role may run on a different node, with its own Dator publishing service offers, its own local Memarium, and its own scope of permissions. Arca does not write the article on behalf of everyone. Arca conducts the flow: it finds the right capabilities, dispatches steps, and watches dependencies, timeouts, retries, and completion facts.
Git Carries the Text, the Swarm Carries Decisions
The most important contract of this user story is simple: article bytes do not flow through Arca, the module responsible for acquiring swarm services. The text, illustrations, and edits live in a Git. That is where draft branches, commits, corrections, and the final web-published branch are created.
Arca, Agora, and Memarium carry something else: pointers and control facts. Which step completed? Which commit was created? Which node signed it? What reached publication? Which editorial decision was made, and which variant was rejected?
This separation matters because it protects us from building yet another large system that tries to become a CMS, memory, orchestrator, archive, and AI engine all at once. In this experiment the layers remain separate: Git is the workspace for the material, while Orbiplex provides coordination, audit, memory, and capability exchange.
Why Bielik?
Bielik is a good starting subject because it touches things that matter to Orbiplex: the Polish language, open language models, community work, repeatable research, and the need to preserve sources. The blog can regularly collect information about releases, tools, repositories, benchmarks, and ecosystem signals, while at the same time becoming a test of the process it describes.
So the point is not only to write about Bielik. The point is also to check whether a small editorial team can work like a federated organism: with memory, signed decisions, local models, and the ability to reconstruct the path from source to publication.
What Counts as Success?
At the beginning, we are not chasing autonomy for its own sake. We care about a craft-oriented contract:
- can we publish short Bielik-related materials regularly without manually stitching together the whole process;
- does every step leave a trace that can be checked later;
- can roles be replaced and run on independent nodes;
- does the human remain the operator and editor responsible for direction, instead of becoming an invisible add-on to an automaton;
- does editorial memory accumulate over time instead of falling apart after each post?
If this works on a small blog, the same pattern can be moved to other series, languages, and publishing processes. Not as product fireworks, but as a verifiable piece of infrastructure: a swarm that can run an editorial process without a single central brain.
For now, this is an experiment. Small and deliberately bounded. But these are exactly the experiments we like, because the story begins to touch code, and the code begins to reveal which parts of the story were truly load-bearing.
See also: