We’re Taking Zorgax From GitHub Into the Real World

Tue, 01 Sep 2026 03:56:18 +0000

We’re Taking Zorgax From GitHub Into the Real World

For months, we have been building MyZubster and Zorgax mostly through code, architecture, tests, automation and open-source experimentation.

Now something more interesting is happening.

The system is starting to interact with real people, real organisations and potential real-world pilot environments.

And that transition is forcing us to rethink what an AI agent should actually be allowed to do.

The core idea behind Zorgax

Zorgax started as an intelligence layer inside the MyZubster ecosystem.

But calling it a chatbot no longer describes what we are trying to build.

The architecture is increasingly based on this loop:

Knowledge
   ↓
Reasoning
   ↓
Decision
   ↓
Human Approval
   ↓
Action
   ↓
Measurement
   ↓
Learning

That Human Approval step is intentional.

As AI systems become connected to GitHub, infrastructure, participants, environmental data and eventually economic systems, unlimited agent permissions become dangerous very quickly.

So instead of building:

AI → everything

we are moving toward:

AI
 ↓
Evidence
 ↓
Recommendation
 ↓
Permission boundary
 ↓
Human approval
 ↓
Action
 ↓
Audit trail

Capability-based automation

One lesson has become particularly important:

an AI agent should receive capabilities, not unlimited authority.

For example, one automation may be allowed to:

read a project registry;
detect changes;
prepare a branch;
create a commit;
open a pull request.

But it may still be forbidden from merging that pull request.

Another workflow may inspect participant information but remain unable to send external communications automatically.

This creates a much more useful distinction:

CAN READ
CAN ANALYSE
CAN PREPARE
CAN PROPOSE

≠

CAN EXECUTE EVERYTHING

It sounds obvious.

In practice, it changes the architecture significantly.

Testing the idea with a real participant

We have also started exploring what this architecture means for a real person.

One participant, Nicola, is using the process to develop a digital-product idea.

Instead of asking the AI:

Give me a business that will make money.

the workflow is closer to:

Idea
 ↓
Validation
 ↓
Evidence
 ↓
Human Choice
 ↓
Blueprint
 ↓
MVP
 ↓
Human Approval
 ↓
Possible Launch
 ↓
Metrics
 ↓
Learning

We deliberately added an evidence gate.

If there are not enough meaningful validation responses, Zorgax should not magically declare the idea validated.

The correct result can simply be:

MORE EVIDENCE REQUIRED

This is important because generative AI is extremely good at producing convincing explanations.

That doesn't mean the explanation is supported by reality.

Then something happened outside the codebase

During a recent real-world discussion involving Nicola and a representative from Maggioli, Nicola described what working through this process had meant to him.

He reported that the experience had strongly affected how he approached his project.

More concretely, he said it motivated him to buy a PC so he could work seriously on the idea and with Zorgax.

That caught my attention.

Not because it proves product-market fit.

It doesn't.

Not because it proves someone will pay for Zorgax.

It doesn't prove that either.

But because the software apparently contributed to a physical-world decision:

AI interaction
     ↓
Idea becomes structured
     ↓
User sees a path forward
     ↓
Motivation increases
     ↓
User invests in working tools

That is a much more interesting signal to me than another chatbot benchmark.

The question becomes:

Can AI increase a person's ability to act?

From one participant to environmental pilots

The same discussion produced another useful direction.

We were encouraged to look for additional pilot cases elsewhere in the European Union.

So we started researching environments where the broader MyZubster architecture could be tested against measurable physical-world evidence.

One particularly interesting area is water.

The architecture fits surprisingly naturally:

Sensors / IoT
      ↓
Environmental evidence
      ↓
Zorgax analysis
      ↓
Recommendation
      ↓
Human decision
      ↓
Intervention
      ↓
MRV
      ↓
Measured result

MRV means Measurement, Reporting and Verification.

That final part matters.

If we say an AI system helped reduce water loss, improve monitoring or optimise some environmental process, there needs to be evidence.

Not:

AI → impressive claim

but:

Baseline
   ↓
Measurement
   ↓
Analysis
   ↓
Human-approved intervention
   ↓
Measurement
   ↓
Comparison

We started European outreach

We have now prepared exploratory pilot concepts around three European environments:

Denmark — Water Valley Denmark

Potential direction: water infrastructure, sensor evidence, digital twins and decision support.

Netherlands — WaterCampus Leeuwarden

Potential direction: circular water / wastewater experimentation using existing demonstration infrastructure.

Finland — Freshwater Competence Centre

Potential direction: freshwater monitoring, environmental observations and sensor evidence.

We have initiated exploratory outreach.

This does not mean these organisations are MyZubster partners.

That distinction matters.

They are potential pilot environments we would like to talk to.

A conversation is not a partnership.

A pilot candidate is not a consortium member.

And an email is definitely not validation.

We prepared the technical documents first

Before contacting them, we prepared a small pilot package.

It includes:

an EU Pilot Brief;
individual pilot concept notes;
a pilot protocol;
a technical due-diligence checklist.

The pilot protocol asks questions like:

What problem are we measuring?

What is the baseline?

Which sensors or datasets exist?

Who owns the data?

What can Zorgax analyse?

What is Zorgax forbidden from doing?

Who approves an intervention?

Which metrics define success?

Who verifies the final result?

When should the experiment stop?

I increasingly believe this kind of document is part of the software architecture.

Once AI leaves the browser and begins interacting with infrastructure, governance becomes an engineering problem.

The same principle applies to payments

We are applying similar thinking to MyZubster's economic layer.

The primitive we are building around is a Payment Intent rather than a shared checkout address.

Conceptually:

Application
    ↓
Payment Intent
    ↓
Unique destination
    ↓
Blockchain transaction
    ↓
Verification
    ↓
Idempotency
    ↓
Application state

For Bitcoin-oriented flows this means thinking carefully about:

per-intent addresses;
watch-only infrastructure;
integer satoshi accounting;
TXID idempotency;
anti-replay protection.

And as payment events become useful to other applications, signed and retry-safe webhook delivery becomes another part of the architecture.

The same rule returns:

economic actions must be harder to execute than recommendations.

Security is becoming part of the product

We've also been working on infrastructure resilience.

One experiment involved a high-availability onion gateway architecture:

Tor client
    ↓
Master Onion
    ↓
OnionBalance
    ↓
node-a
node-b
node-c
    ↓
Gateway

We tested failure of one node while requests continued through the remaining infrastructure.

Meanwhile, dependency security work continues in other parts of the ecosystem, including Rust dependencies.

None of these things are particularly glamorous.

But once you're trying to connect AI to real systems, the boring parts become the important parts.

MyZubster is starting to look like a stack

The architecture currently makes the most sense to me as several layers:

┌──────────────────────────────────┐
│ ZORGAX                           │
│ Intelligence / Coordination      │
├──────────────────────────────────┤
│ APPLICATIONS                     │
│ LIFE / Marketplace / Bounties   │
│ Services / Metaverse / Assets   │
├──────────────────────────────────┤
│ ECONOMIC LAYER                   │
│ Payment Intents / Verification  │
│ Idempotency / Anti-Replay       │
├──────────────────────────────────┤
│ PAYMENT RAILS                    │
│ BTC / Monero / Machine Payments │
├──────────────────────────────────┤
│ PHYSICAL WORLD                   │
│ Sensors / Robots / Water / IoT  │
└──────────────────────────────────┘

The experiment is what happens between those layers.

A sensor produces evidence.

Zorgax analyses it.

A human approves a decision.

An operator or machine performs an action.

The result is measured.

That result becomes new evidence.

And the loop starts again.

What I'm learning from building this

The biggest lesson so far is that building an AI agent is relatively easy.

Building an AI system that knows when not to act is much harder.

The future architecture I'm interested in is therefore not:

AUTONOMOUS AI

but something closer to:

CAPABLE AI
+
LIMITED PERMISSIONS
+
REAL EVIDENCE
+
HUMAN AUTHORITY
+
MEASUREMENT
+
AUDITABILITY

We're still early.

The European organisations we've contacted may say no.

Some experiments may fail.

Some architectural assumptions will probably be wrong.

That's fine.

Because the next phase of MyZubster isn't about making the diagrams more impressive.

It's about putting small pieces of the architecture against reality and asking:

Does this actually work?

And if it doesn't:

What did we learn?

That's where Zorgax is heading next.

From GitHub.

To people.

To sensors.

To infrastructure.

And, hopefully, to measurable evidence.

Building MyZubster / Zorgax in public.

If you're working on human-gated agents, IoT, environmental monitoring, MRV, AI governance or open-source agent infrastructure, I'd be interested in comparing architectures and lessons learned.

Coder Legion - Recent posts tagged realworld

We’re Taking Zorgax From GitHub Into the Real World