Over the last months, we have been building MyZubster as an open ecosystem connecting AI, software, environmental infrastructure, digital identity, payments, robotics, IoT and human decision-making.
Something important is now changing.
The project is beginning to move from architecture and code into real-world interaction.
This is not a claim that everything is finished.
It is not a claim that every organisation we talk to is already a partner.
And it is definitely not a claim that an AI system should autonomously control critical infrastructure.
It is the opposite.
We are trying to build a path from:
software → evidence → people → real-world pilots → measurement → learning.
This post is an update on what we have been building online and what has started happening in the real world.
Zorgax Is Becoming an Operating Layer, Not Just a Chatbot
The central intelligence layer of the ecosystem is Zorgax.
We increasingly describe Zorgax through this loop:
Knowledge
↓
Reasoning
↓
Decision
↓
Human Approval
↓
Action
↓
Measurement
↓
Learning
The important part is the Human Approval step.
Our objective is not to create an AI that receives unlimited permissions and starts making sensitive decisions by itself.
Instead, we are building a human-gated coordination layer.
Zorgax can potentially collect evidence, analyse a situation, structure alternatives and recommend an action.
But when an action has meaningful consequences, a human remains responsible for approving it.
This principle is now influencing multiple parts of MyZubster.
From AI Agents to Capability-Based Automation
One of the architectural lessons we have learned is that giving an AI agent broad access to everything is usually the wrong abstraction.
Instead, automation should have narrow capabilities.
For example:
Read evidence
↓
Detect meaningful change
↓
Prepare an update
↓
Request approval when required
↓
Execute only the authorised capability
We are applying this thinking to participant workflows, project registries, GitHub activity, documentation and controlled operational processes.
The goal is simple:
automate repetitive coordination without removing accountability.
That distinction becomes increasingly important when software begins interacting with people, organisations, money or physical infrastructure.
Building an Economic Layer Around Payment Intents
Another major area of development has been the MyZubster economic architecture.
Instead of treating a wallet address as the core payment primitive, we have been working around the concept of a Payment Intent.
Conceptually:
Economic event
↓
Payment Intent
↓
Unique payment destination
↓
Blockchain transaction
↓
Verification
↓
Idempotency / anti-replay
↓
Application state
For Bitcoin-oriented flows, the architecture is designed around ideas such as:
- per-intent addresses;
- watch-only infrastructure;
- integer satoshi accounting;
- transaction-ID idempotency;
- anti-replay protection;
- shared economic verification APIs.
Real financial execution remains deliberately separated from development and testing.
The broader objective is to eventually allow different MyZubster applications to consume the same economic verification layer rather than each application inventing its own payment logic.
The Metaverse Is Becoming Identity Infrastructure
We are also developing the MyZubster Metaverse beyond the idea of a purely visual virtual world.
A character can represent an account-linked identity.
The direction is:
Account
+
Verified external identity
↓
Metaverse Character
↓
World participation
↓
Activities / projects / contributions
GitHub-linked identities can be connected to characters while guest identities remain separate.
This distinction matters because a visual avatar should never be enough to impersonate an account-linked participant.
We have already been testing this model with characters associated with real ecosystem participants.
Again, identity verification and database changes remain controlled processes rather than autonomous AI actions.
A Real Participant: Nicola
One of the most important developments has not happened inside a repository.
It has happened with a person.
Nicola joined an experimental MyZubster/Zorgax participant workflow.
The objective is to explore whether an AI coordination system can help someone move from an idea toward a structured project while maintaining human agency.
The workflow looks roughly like this:
Idea
↓
Validation
↓
Evidence
↓
Human Choice
↓
Blueprint
↓
MVP
↓
Human Approval
↓
Possible Launch
↓
Metrics
↓
Learning
A critical rule is that Zorgax should not invent market demand.
Positive comments are not automatically purchase intent.
A person saying they would test something for free does not mean they would pay for it.
And a small number of conversations cannot be transformed into a revenue forecast.
We therefore introduced a simple validation scoring framework.
Evidence is evaluated around dimensions such as:
- whether the problem is real;
- urgency;
- weakness of the current solution;
- willingness to test;
- clarity of the desired outcome;
- clarity of the required feature.
If the evidence is insufficient, the correct output is:
MORE EVIDENCE REQUIRED
not a fabricated conclusion.
When Software Produces Motivation in the Physical World
Recently we had a real-world conversation involving Nicola and a representative from Maggioli.
During that discussion, Nicola described his experience using Zorgax to develop his idea.
His feedback was unusually strong.
He explained that the process was having a significant positive impact on how he was approaching his project.
He also reported that the experience motivated him to buy a computer so that he could work more seriously on the idea and with Zorgax.
He additionally expressed that he no longer felt interested in paying for several other AI tools.
We need to interpret this carefully.
It does not prove willingness to pay for Zorgax.
It does not prove product-market fit.
And we should not transform a participant's personal statement into an unsupported marketing claim.
But it is meaningful qualitative evidence.
For us, the interesting sequence is:
Zorgax
↓
Idea exploration
↓
Structure
↓
Validation
↓
Operational accompaniment
↓
Greater digital autonomy
↓
Participant invests in better working tools
That is something worth studying.
The important metric may not initially be "How many tokens did the AI generate?"
It may be:
Did the system help a human become more capable of acting?
An Important Conversation About LIFE 2027
The same discussion also produced useful strategic feedback for our work around the EU LIFE programme.
One recommendation was particularly interesting:
look for additional real pilot cases outside Italy, preferably elsewhere in the European Union.
This changed our immediate next step.
Rather than concentrating only on a single geography, we started looking for environments where MyZubster technologies could eventually be evaluated against real environmental evidence.
Importantly, this conversation should not be interpreted as a formal partnership announcement.
Exploratory discussions, contributors, pilot candidates and formal project partners are different things.
We deliberately keep those statuses separate.
Looking for European Pilot Cases
Following that feedback, we began researching European environments where a small MyZubster pilot could make technical sense.
The strongest initial direction is water.
Why water?
Because it connects several parts of the ecosystem naturally:
Water infrastructure
+
Sensors / IoT
↓
Environmental evidence
↓
Zorgax
↓
Human decision
↓
Operational action
↓
MRV
↓
Measured environmental outcome
MRV here means Measurement, Reporting and Verification.
Instead of saying that a technology produces environmental impact, we want the pilot architecture to define how that impact would actually be measured.
Denmark: Water Valley
One candidate we identified is Water Valley Denmark.
Its water innovation environment is particularly interesting because of the combination of real infrastructure, sensor data, digital technologies and experimentation.
Our proposed direction is not:
"Please become a MyZubster partner."
It is much smaller.
We want to explore whether there is a bounded use case where existing evidence could feed a human-gated Zorgax workflow.
For example:
Sensor evidence
↓
Anomaly detection / analysis
↓
Zorgax recommendation
↓
Operator review
↓
Action
↓
Measured result
The first objective would simply be determining whether such a pilot is technically meaningful.
Netherlands: WaterCampus Leeuwarden
A second candidate is WaterCampus Leeuwarden in the Netherlands.
The attraction here is its ecosystem around practical water technology experimentation and demonstration environments.
A possible MyZubster pilot could focus on circular water or wastewater evidence.
Rather than installing an entirely new infrastructure, our preference would be to begin with existing measurements whenever possible.
That gives us a much cleaner experimental question:
Can a human-gated AI coordination layer extract useful decision support from an existing environmental evidence stream?
If yes, then we measure it.
If no, we document why.
Both results are useful.
Finland: Freshwater Monitoring
The third initial direction is Finland, through the Freshwater Competence Centre ecosystem.
This is particularly interesting from the monitoring side.
A potential architecture could be:
Freshwater observations
↓
Evidence quality checks
↓
Zorgax analysis
↓
Human-reviewed recommendation
↓
Follow-up measurement
Here the AI does not need control of a physical system to provide value.
It can begin as an evidence and decision-support layer.
That significantly lowers the risk of an early pilot.
We Prepared the Pilot Documentation Before Asking for Anything
We wanted these conversations to be more serious than a generic cold email.
So before starting the outreach, we prepared an initial European pilot documentation package.
It includes:
- a MyZubster EU Pilot Brief;
- a Water Valley Denmark pilot concept;
- a WaterCampus Leeuwarden pilot concept;
- a Freshwater Competence Centre pilot concept;
- a pilot protocol template;
- a technical due-diligence checklist.
The protocol forces us to answer questions such as:
Who owns the pilot?
What exactly is the problem?
What is the baseline?
Which data can be used?
What is Zorgax allowed to do?
What is Zorgax explicitly forbidden from doing?
Who approves recommendations?
Which indicators measure success?
Who validates the measurements?
What causes the pilot to stop?
This may look bureaucratic.
It is actually an important engineering tool.
The moment an AI project touches real infrastructure, "let's connect everything and see what happens" stops being an acceptable architecture.
European Outreach Has Started
We have now initiated exploratory outreach toward the first three European candidates:
- Denmark;
- the Netherlands;
- Finland.
The documentation has been prepared and organised so that each organisation receives a general project brief plus a concept tailored to its environment.
The request is deliberately modest:
a short exploratory conversation to identify whether a small, measurable pilot case exists.
There is no assumption that any recipient will accept.
There is no assumption of partnership.
And there is no assumption that the initial technical hypothesis is correct.
The outreach itself is part of the validation process.
Environmental AI Needs Evidence, Not Marketing
This principle is becoming increasingly important inside MyZubster.
Imagine someone says:
"Our AI reduced water consumption by 20%."
That statement means almost nothing unless we know:
- the baseline;
- measurement period;
- measurement instrument;
- external variables;
- intervention;
- comparison method;
- data quality;
- person or organisation validating the result.
So the model we want is closer to:
Baseline
↓
Evidence
↓
Recommendation
↓
Human Approval
↓
Intervention
↓
Measurement
↓
Comparison
↓
Verified conclusion
Sometimes the conclusion may be:
No measurable improvement.
That needs to remain a valid result.
Otherwise we are not doing experimentation.
We are doing marketing.
Open Source Is Still Central
All of this continues to be developed around an open-source philosophy.
GitHub is not simply a place where we dump source code.
It is increasingly becoming part of the project's audit trail.
Changes can be represented through:
Issue
↓
Branch
↓
Commit
↓
Pull Request
↓
Tests / CI
↓
Human Review
↓
Merge
That pattern also fits the broader Zorgax philosophy.
AI can prepare work.
AI can analyse evidence.
AI can suggest changes.
But critical transitions remain explicit and reviewable.
Security Work Is Happening in Parallel
As the ecosystem grows, security work cannot be postponed until the end.
We have been working across several fronts.
One is dependency security in our Tari-related work, where Rust security advisories are being handled carefully rather than forcing incompatible upgrades across a large dependency graph.
Another is network resilience.
We have also tested a high-availability onion gateway architecture.
Conceptually:
Tor Client
↓
Master Onion
↓
OnionBalance
↓
Multiple backend onion nodes
↓
Gateway
We performed failover testing by taking one node offline and confirming that requests continued through the remaining infrastructure.
This is still infrastructure engineering, not magic anonymity.
Operational security depends on much more than simply using Tor.
Payments Also Need Event Infrastructure
Another area now being explored is outbound payment events.
If an ecosystem contains payment confirmation, escrow release or bounty completion, other applications eventually need to react to those events.
That suggests an architecture around signed webhooks:
Payment event
↓
Canonical event payload
↓
Signature
↓
Delivery
↓
Failure handling
↓
Retry
↓
Idempotent consumer
The important requirements are predictable:
- signatures must be verifiable;
- retries must be safe;
- secrets must not leak into logs;
- duplicate events must not produce duplicate economic effects.
This becomes particularly important in an ecosystem where many different applications may consume the same economic layer.
MyZubster Is Becoming a Stack
The project increasingly makes more sense when viewed as layers.
┌──────────────────────────────────────────┐
│ ZORGAX │
│ Intelligence / coordination / knowledge │
├──────────────────────────────────────────┤
│ APPLICATIONS │
│ Marketplace · LIFE · Bounties · Services│
│ Digital Assets · Metaverse │
├──────────────────────────────────────────┤
│ ECONOMIC LAYER │
│ Payment Intents · Verification │
│ Idempotency · Anti-Replay │
├──────────────────────────────────────────┤
│ PAYMENT RAILS │
│ BTC · Monero · Machine Payments │
├──────────────────────────────────────────┤
│ PHYSICAL WORLD │
│ Robots · Sensors · Water · Infrastructure│
│ Environmental Systems │
└──────────────────────────────────────────┘
The interesting part is not any single layer.
It is what happens when they begin interacting.
A sensor can create evidence.
Zorgax can analyse the evidence.
A human can approve a response.
A machine or operator can perform an action.
A payment layer can verify an economic event.
MRV can measure the environmental result.
And the outcome can become new knowledge for the next decision.
The Real Experiment
The question behind MyZubster is becoming clearer.
It is not simply:
Can we build a powerful AI agent?
Large technology companies are already answering that question.
The question we are interested in is different:
Can we build an open ecosystem where AI helps coordinate humans, software, machines, environmental evidence and economic activity without removing human responsibility?
That requires more than an LLM.
It requires:
- identity;
- permissions;
- evidence;
- auditability;
- security;
- payments;
- infrastructure;
- sensors;
- governance;
- human approval;
- measurement.
And eventually it requires something even harder:
real people and real environments willing to test it.
That phase is beginning.
What Happens Next
The next milestones are not about making the architecture diagram larger.
They are about making the evidence stronger.
For the European pilot work, that means finding one small use case where we can define:
Problem
+
Baseline
+
Evidence
+
Human decision
+
Intervention
+
Measurement
=
A result we can actually evaluate
For participant experiments, it means observing whether Zorgax genuinely increases people's ability to structure and execute their ideas.
For the technical ecosystem, it means continuing to make every layer more secure, testable and auditable.
And for MyZubster as a whole, it means continuing the transition from:
an ambitious open-source architecture
to
an evidence-driven ecosystem tested against the real world.
We don't know yet where every experiment will lead.
That is precisely why we are running them.
Build.
Measure.
Learn.
Keep humans in control.
And let the evidence decide what comes next.
