How We’re Building a Human-Gated AI Automation Layer for MyZubster LIFE
Today we improved one of the most practical parts of the MyZubster ecosystem: how Zorgax handles recurring operational work without becoming an unrestricted autonomous agent.
The current experiment combines three things:
LIFE registry monitoring, participant automation, and controlled Google Drive visual access synchronization.
The interesting part is not that “AI can automate tasks.”
The interesting part is how to automate them without losing consent, traceability, or human control.
The problem
As MyZubster grows, more work becomes repetitive:
checking GitHub for meaningful project changes;
monitoring participant updates;
keeping LIFE-related evidence separated correctly;
detecting when clarification is needed;
preparing structured pull requests;
synchronizing access to a specific set of visual assets.
These are ideal candidates for automation.
But there is a dangerous shortcut:
give the AI broad permissions and let it do everything.
We are intentionally not doing that.
Instead, we are building narrow operational contracts.
Zorgax works inside explicit scopes
Our automation is structured around the idea that every capability should have a clearly defined boundary.
For example, the current LIFE automation can monitor:
GitHub;
Gmail;
LIFE registries;
participant evidence;
contributor states;
stakeholder states.
But it must keep those categories separate.
A participant is not automatically a contributor.
A contributor is not automatically a LIFE partner.
A public GitHub interaction is not participant consent.
An interested organization is not automatically a formal partner.
This sounds simple, but it matters a lot when AI systems start updating persistent project state.
Participant automation is consent-driven
The participant workflow follows a separate consent model.
The general structure is:
Consent → Authorized Processing → Evidence Check → Proposed Change → Pull Request → Human Review
Zorgax can process only the information that falls inside the participant’s approved scope.
If the information is incomplete or ambiguous, it should not invent the missing pieces.
Instead, the message is classified.
We currently use states such as:
NO_ACTION
Nothing material changed.
NEEDS_CLARIFICATION
The information is incomplete, ambiguous, or unsupported.
UPDATE_PREPARED
There is enough authorized evidence to prepare a focused update.
That small classification layer prevents the agent from treating every new message as an instruction to modify the system.
GitHub is the audit layer
For project changes, we use a workflow like:
ZORGAX → BRANCH → COMMIT → PULL REQUEST → HUMAN REVIEW → MERGE
The agent can prepare the work.
It cannot automatically merge it.
This gives us an auditable trail:
what changed;
why it changed;
what evidence supported it;
which files were affected;
whether the change passed review.
Instead of “the AI changed the project,” we get a traceable software-engineering workflow.
A narrow exception: automatic visual access sync
Today we added a more interesting capability.
We have a Google Drive folder dedicated to shareable MyZubster comic and visual assets:
Visual Fumetto — Condivisibili
The folder contains assets such as:
MyZubster Marketplace comic;
Zorgax visual updates;
Gateway visuals;
bounty visuals;
AI visuals;
roadmap graphics;
cyberpunk system illustrations.
We wanted one approved collaborator to automatically receive access to new visual files added to this folder.
At first glance, this sounds trivial.
Just give the AI access-management permissions.
But that would be too broad.
So we created a narrow automation rule.
The access contract
The automation can inspect only one specific Drive folder.
For files directly inside that folder, it checks whether the approved collaborator already has access.
If a new file appears and access is missing, Zorgax can automatically grant:
reader access only.
The automation is explicitly forbidden from:
granting writer access;
granting ownership;
changing folder-level permissions;
sharing files outside the approved folder;
adding other users;
expanding permissions beyond the predefined collaborator;
modifying the actual file content.
In other words, we treat access management almost like an API capability with a strict allowlist.
Conceptually:
Allowed folder
↓
Detect new file
↓
Check existing permission
↓
Missing reader access?
↓
Grant reader
↓
Log / notify only if change occurred
Nothing else.
Why not just share the whole folder?
Because narrow permissions are easier to reason about.
If the automation shares the entire folder dynamically, a future mistake could expose files that were never intended for the same audience.
By restricting the automation to files directly inside a dedicated “shareable” folder, the folder itself becomes part of the security model.
The human decides which assets belong there.
Zorgax only handles the repetitive permission update.
That separation is important:
Human decides scope.
AI executes the narrow rule.
Condition-based automation
The task runs as a condition watcher.
It does not need to notify us every time it runs.
Instead, it should stay silent unless something meaningful happens.
For the visual sync, that means notifications happen only when:
access was granted to one or more new files;
an access error occurred.
For the LIFE side, notifications are similarly limited to meaningful events such as:
participant consent changes;
relevant participant updates;
contributor evidence changes;
stakeholder state changes;
clarification required;
a new PR prepared for review.
No change means no noise.
This turns Zorgax from a notification generator into a state-change detector.
One automation, multiple bounded responsibilities
We also hit a practical limitation: the account already had the maximum number of active automation tasks.
Instead of creating another independent task, we improved an existing LIFE registry automation and added the visual synchronization as a narrowly defined secondary capability.
This is actually a useful architectural lesson.
More agents and more scheduled jobs are not always better.
Sometimes the better design is:
fewer orchestrators, stricter scopes.
The important part is that responsibilities remain clearly separated inside the task.
For example:
Zorgax LIFE Registry + Visual Sync
├── LIFE registry monitor
│ ├── participant evidence
│ ├── contributor evidence
│ ├── stakeholder states
│ └── GitHub PR preparation
│
└── Visual permission sync
├── one Drive folder
├── one approved collaborator
└── reader permission only
Automatic does not mean unrestricted
This is one of the main principles we are discovering while building Zorgax.
An AI agent can be highly useful without being given unrestricted control.
The real architecture looks closer to:
Knowledge → Reasoning → Policy Check → Authorized Action → Evidence → Human Gate
Different actions have different levels of autonomy.
Low-risk repetitive actions can be automated.
Higher-risk actions remain gated.
For example, Zorgax may automatically synchronize an approved read permission.
But it should not automatically:
publish commercial offers;
change production secrets;
merge sensitive code;
transfer money;
alter ownership;
make legal commitments;
change pricing;
modify production databases destructively.
Capability-based AI agents
We are increasingly thinking about Zorgax in terms of capabilities, rather than generic “agent permissions.”
Instead of saying:
“Zorgax has access to Drive.”
We want to say:
“Zorgax may ensure that one approved user has reader access to files directly contained in this specific folder.”
Those are very different security models.
The second is much easier to audit.
This idea can be applied far beyond Google Drive.
For example:
GitHub capability:
prepare PR, never merge
Email capability:
read participant replies, never send automatically
Payments capability:
prepare payment intent, never execute without approval
Metaverse capability:
prepare identity state, never mutate production identity without authorization
Drive capability:
grant reader access inside one approved folder
The agent becomes a collection of constrained operational capabilities.
Where we are heading
The long-term architecture for MyZubster and Zorgax is moving toward:
Knowledge → Reasoning → Decision → Human Approval → Action → Measurement → Learning
But not every action requires the same approval level.
The challenge is designing the boundary correctly.
For safe repetitive work, the system should operate automatically.
For sensitive or irreversible actions, humans should remain the final authority.
That is what we are testing now.
Not maximum AI autonomy.
Useful, auditable autonomy.
And for us, that distinction is becoming one of the most important parts of building real AI agents.
Top comments (0)