We Built Zorgax as a Hybrid AI Layer for MyZubster — Here’s How It Works
Over the last development cycle, we turned Zorgax into a real AI layer inside MyZubster.
The goal was not to add “another chatbot”.
We wanted Zorgax to become a product copilot capable of:
deciding which AI provider should handle a request,
using OpenAI only when it makes sense,
falling back to a local/general AI route,
controlling cloud AI costs,
showing which model actually answered,
distinguishing live product features from pilots and proposals,
and keeping persistent actions behind explicit user confirmation.
The result is now running in production.
A hybrid AI architecture
The current flow is simple in concept:
User
↓
MyZubster /zorgax
↓
POST /api/zorgax/assistant/chat
↓
Access / research policy
↓
Task classification
↓
AI Router
├── OpenAI
│ └── complex / research tasks
│
└── Ollama / general AI gateway
└── standard tasks + fallback
↓
Zorgax system persona
↓
Grounded response
↓
UI + routing metadata
The important part is that we do not hide the routing decision.
A response can include:
{
"ai_provider": "openai",
"ai_model": "gpt-5.6-sol",
"ai_fallback_reason": null
}
and the UI shows:
AI: OpenAI · gpt-5.6-sol
If OpenAI cannot be used:
AI: Ollama · qwen2.5:3b · fallback: openai_error
That gives us transparency for both users and developers.
Not every prompt should use the expensive model
One of the first design decisions was to avoid sending every request to a cloud model.
A basic message like:
Ciao Zorgax
does not need the same infrastructure as:
Analyze this LIFE research workflow, evaluate KPI/MRV evidence,
compare deployment behavior, and explain the GitHub implementation.
So Zorgax classifies requests into broad tiers.
Signals such as:
GitHub
Vercel
deployment
debugging
code
research
LIFE
KPI
MRV
automation
can contribute to the request being classified as complex.
Research mode or very long prompts can also move a request into that tier.
The simplified logic is:
const tier =
useResearch ||
complexSignalCount >= 2 ||
text.length >= 2500
? "complex"
: "standard";
Complex requests can use OpenAI.
Standard requests can remain on the more lightweight route.
OpenAI as a runtime capability
During testing we found an interesting production bug.
The OpenAI API key was already present in Vercel, but Zorgax was still responding through the fallback model.
The runtime logs showed:
aiProvider: ollama
aiModel: qwen2.5:3b
aiFallbackReason: astra_disabled
That made the problem immediately clear: the integration existed, but the runtime gate was still disabling it.
We fixed the routing so that the OpenAI path becomes available when the server has a configured OPENAI_API_KEY.
There is still a dedicated emergency kill switch:
ZORGAX_ASTRA_KILL_SWITCH=true
so remote inference can be disabled deliberately without removing credentials.
The status API now exposes safe observability data:
{
"ai": {
"openai_configured": true,
"astra_enabled": true,
"astra_kill_switch": false,
"astra_model": "gpt-5.6-sol"
}
}
No API key is exposed.
Cost control is part of routing
We did not want “use the stronger model” to mean “ignore cost”.
Zorgax keeps an application-side monthly OpenAI budget.
Before a request is sent remotely, the system checks current usage and reserves an estimated amount.
The flow is roughly:
classify request
↓
check monthly spend
↓
estimate worst-case request cost
↓
reserve budget
↓
call OpenAI
↓
record real token usage
↓
settle reservation
If the budget cannot be reserved, Zorgax falls back instead of failing the conversation.
That makes cost control part of the architecture rather than an afterthought.
The OpenAI path
The server calls the OpenAI Responses API.
The key never reaches the browser.
Conceptually:
const response = await fetch(
"https://api.openai.com/v1/responses",
{
method: "POST",
headers: {
Authorization: `Bearer ${process.env.OPENAI_API_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
model,
input,
max_output_tokens: 4096
})
}
);
After the response returns, token usage is recorded.
If OpenAI fails, the reserved budget is released and Zorgax switches to the fallback route.
That means a remote AI failure does not necessarily make Zorgax unavailable.
The harder problem: product truth
The most important lesson was not about model selection.
It was about grounding.
Once Zorgax became capable of producing richer answers, it also became capable of confidently describing features that would make sense but were not necessarily implemented.
For a platform like MyZubster, that is dangerous.
The ecosystem contains:
live product features,
MVP components,
active pilots,
experimental concepts,
roadmap items.
Those cannot be treated as the same thing.
We therefore introduced explicit capability states:
LIVE / IMPLEMENTED
PILOT / EXPERIMENTAL
PROPOSED / PLANNED
UNKNOWN / UNVERIFIED
Zorgax is instructed not to silently promote one state into another.
For example, it must not invent:
Seller → advanced shipping dashboard
or:
LIFE Pilot → GPS environmental incident reporting
or:
Seller → virtual Metaverse showroom
unless the current product evidence actually supports those claims.
If something is hypothetical, Zorgax should say it is hypothetical.
Product-first answers
Another improvement was changing how Zorgax introduces MyZubster.
An AI assistant can easily over-explain architecture.
A newcomer asks:
What is MyZubster?
and gets blockchain terminology, repository details, validation states, evidence theory, and technical architecture.
Interesting for developers.
Bad for onboarding.
Our new system prompt uses a PRODUCT FIRST rule.
The assistant should first explain what the user can do:
Marketplace
Seller
Community
Metaverse
LIFE Pilot
GitHub
Zorgax
Only then should it go deeper into implementation details.
And when a user has a concrete goal, Zorgax should become a step-by-step copilot rather than a directory.
The preferred interaction becomes:
current step
↓
expected result
↓
next step
instead of dumping an entire workflow at once.
Web research as a separate evidence layer
Zorgax can also perform research through external providers.
The current architecture contains adapters for sources such as:
Brave Search
Tavily
Wikipedia
depending on which services are configured.
Results are normalized into a common structure:
{
"label": "W1",
"provider": "wikipedia",
"title": "...",
"url": "...",
"snippet": "..."
}
That information can be added to the AI context and displayed separately in the interface.
An important rule is that retrieved web content is treated as evidence, not as trusted instructions.
This matters for any assistant that performs web research because external pages can be wrong, outdated, or malicious.
AI is not allowed to silently write data
We also separated conversational reasoning from persistent actions.
If a user asks Zorgax to store data, Zorgax first creates a preview.
It then generates a digest and a confirmation token:
CONFERMA ab12cd34
Only after explicit confirmation can the authenticated write endpoint persist the record.
The flow is:
ANSWER
↓
UNDERSTAND
↓
COLLECT MISSING DATA
↓
VALIDATE
↓
CONFIRM
↓
SUBMIT
This is an architectural pattern we want to keep expanding.
The AI can prepare an action.
The application still controls authorization and persistence.
We also had to fix the chat itself
A good backend does not help much if the UI is uncomfortable.
The original Zorgax conversation area was too small.
Long replies also caused the chat to scroll to the bottom of the answer.
So the user would receive a long response and immediately have to scroll upward to find where it started.
We changed the layout so the conversation is the main area of the page.
We also changed the scrolling logic so a new assistant response moves to the top of that response, not the bottom.
Conceptually:
function scrollMessageToTop(element) {
const delta =
element.getBoundingClientRect().top -
messages.getBoundingClientRect().top;
messages.scrollTo({
top: messages.scrollTop + delta - 12,
behavior: "smooth"
});
}
And when focus returns to the input:
input.focus({ preventScroll: true });
This prevents browser focus behavior from undoing the intended scroll position.
Small detail.
Huge usability improvement for long AI answers.
Observability made the debugging possible
The runtime now logs routing metadata for successful Zorgax requests.
A simplified example:
event: zorgax_message_sent
plan: pro
webResearch: true
sourceCount: 0
aiProvider: openai
aiModel: gpt-5.6-sol
aiFallbackReason: null
That was how we discovered that our first production test was still using Ollama.
Without observability, the answer looked fine.
With observability, we knew the exact provider, model, fallback reason, and deployment involved.
That changed the debugging process from:
"I think OpenAI is running"
to:
"this exact production request used this exact route"
The production model today
The architecture now behaves approximately like this:
STANDARD REQUEST
↓
general/local AI route
COMPLEX / RESEARCH REQUEST
↓
OpenAI
↓
budget reservation
↓
usage tracking
↓
response
↓
fallback if required
The application also exposes enough metadata to verify the decision.
The latest production runtime reports:
OpenAI configured: yes
Astra/OpenAI route enabled: yes
kill switch: off
model: gpt-5.6-sol
The main lesson
The AI API call was the easy part.
The real system is:
AI model
- router
- grounding
- budget control
- fallbacks
- authorization
- observability
- UX
A stronger model does not automatically produce a more reliable product.
In some ways, the opposite is true.
The more convincing the model becomes, the more important it is for the application to define:
what exists
what is experimental
what is verified
what the AI is allowed to do
what actually happened
That is the direction we are taking with Zorgax.
Not AI controlling the entire product.
AI reasoning inside a product whose state, evidence, permissions, and execution rules remain explicit.
What comes next
Zorgax is now becoming the conversational layer that can connect more parts of MyZubster.
The next areas include deeper integration with:
Marketplace
Seller workflows
profiles
research workflows
LIFE pilots
GitHub contributions
community interactions
The goal is to keep improving intelligence without losing transparency.
That balance is becoming one of the core architectural principles of MyZubster.
We did not come to conquer. We came to build together.
Per CoderLegion userei come titolo:
How We Built Zorgax: A Hybrid AI Layer with OpenAI, Ollama, Grounding and Runtime Routing
