Meet Zorgax: the Local AI Research Agent Inside MyZubster

MyZubster is growing from a collection of services into a larger open-source ecosystem made of APIs, observations, research data, automation, identity layers, dashboards, and experimental AI components.

One of those components is Zorgax.

Zorgax is not just a chatbot skin attached to an API.

It is a local AI identity designed to operate inside the MyZubster environment, with access to selected internal capabilities such as persistent memory, observations, and a provenance-aware research layer.

The important word here is selected.

Zorgax does not receive unlimited control over the infrastructure, and it does not autonomously crawl the Internet or Tor.

Instead, MyZubster gives it controlled tools and structured context.

---

What is Zorgax?

Zorgax currently runs as the virtual entity:

text
ZORGAX-001
The AI backend can run locally through Ollama.

A current deployment can use:

zorgax:latest

with a Qwen-based local model.

The basic architecture looks like this:

User
  ↓
MyZubster API
  ↓
Zorgax
  ├── Local AI model
  ├── Persistent memory
  ├── Observation registry
  └── Research RAG
        ↓
     MongoDB
        ↓
 provenance-bearing research context

This means that the model does not need to rely only on whatever knowledge was originally embedded in its weights.

MyZubster can provide it with selected contextual information at request time.

What powers does Zorgax have?

“Powers” in this context means capabilities exposed by MyZubster, not unrestricted server privileges.

At the moment, the most interesting capabilities are these.

1. Local AI inference

Zorgax can run through a local Ollama instance.

Example:

Provider: ollama
Model: zorgax:latest

This makes it possible to run the AI layer without sending every conversation to an external hosted LLM provider.

It also makes experimentation with local models much easier.

2. Persistent memory

Zorgax can use a persistent memory layer.

The current MyZubster status API exposes capabilities such as:

{
  "persistent_memory": true,
  "memory_opt_in": true,
  "memory_ttl_days": 90
}

Memory is therefore not simply an unlimited transcript dump.

It is designed as an explicit capability with retention controls.

Applications can also decide whether memory should be used for an individual request.

For example:

{
  "message": "What were we working on?",
  "useMemory": true
}

Or disable it:

{
  "message": "Answer without previous memory.",
  "useMemory": false
}
3. Observation registry

MyZubster also contains an observation layer.

Zorgax can use observations as structured context rather than treating every piece of information as conversational memory.

Conceptually:

real-world observation
        ↓
observation registry
        ↓
selected context
        ↓
Zorgax

This distinction matters.

Memory represents conversational or retained context.

Observations can represent registered facts, measurements, or ecosystem events.

4. Research RAG

This is one of the most important recent additions.

Zorgax can query a MongoDB-backed research index and receive a bounded set of relevant documents.

The flow is:

ResearchDocument index
        ↓
text retrieval
        ↓
top-k sources
        ↓
RAG context
        ↓
Zorgax
        ↓
answer + provenance labels

An API response can include something like:

{
  "research_used": ["R1"],
  "research_provenance": "MongoDB ResearchDocument text index"
}

The source itself can include:

{
  "label": "R1",
  "url": "https://example.com/document",
  "sourceType": "web",
  "crawledAt": "...",
  "contentHash": "..."
}

This is very different from simply asking a model:

“Do you remember something about this topic?”

The response can be tied to an actual indexed source.

Provenance matters

One of the goals of the Zorgax research layer is to make answers easier to inspect.

When research context is used, the system can preserve:

source labels
original URLs
source type
crawl timestamp
content hashes
retrieval provenance

This makes it possible to build AI features that are closer to:

answer
+
where the context came from

instead of only:

answer

For an open-source research ecosystem, that difference is important.

Does Zorgax crawl the Web?

Not autonomously.

This is an intentional boundary.

The current system exposes:

{
  "research_crawl_autonomous": false,
  "research_crawl_requires_admin": true
}

Zorgax can search already indexed research material.

A separate controlled crawler can refresh or add documents when explicitly invoked with the appropriate authorization.

So this:

Zorgax decides to crawl random websites by itself

is not the architecture.

The intended model is closer to:

authorized research ingestion
          ↓
controlled index
          ↓
Zorgax retrieval

The same boundary applies to Tor.

Zorgax is not designed as an autonomous Tor crawler.

How to check whether Zorgax is online

On a MyZubster node, the status endpoint can be queried with:

curl http://127.0.0.1:5111/api/zorgax/status

A healthy response can look like:

{
  "ok": true,
  "entity": "ZORGAX-001",
  "provider": "ollama",
  "model": "zorgax:latest",
  "model_loaded": true,
  "virtual_identity": true,
  "persistent_memory": true,
  "observation_registry": true,
  "research_rag": true
}

The research index can be checked with:

curl http://127.0.0.1:5111/api/research/status

Example:

{
  "success": true,
  "total": 1,
  "byType": {
    "web": 1
  }
}
Talking directly to Zorgax

A simple API request can look like this:

curl -X POST http://127.0.0.1:5111/api/zorgax/chat \
  -H 'Content-Type: application/json' \
  --data '{
    "message": "Hello Zorgax",
    "useMemory": false,
    "useObservations": false,
    "useResearch": false
  }'

A research-enabled request can instead use:

curl -X POST http://127.0.0.1:5111/api/zorgax/chat \
  -H 'Content-Type: application/json' \
  --data '{
    "message": "Explain the MyZubster research RAG architecture",
    "useMemory": false,
    "useObservations": false,
    "useResearch": true,
    "researchScope": "all",
    "researchLimit": 3
  }'

Now Zorgax can answer using retrieved research context.

Direct research retrieval

The research layer can also be queried independently from the chat generation step.

For example:

curl \
"http://127.0.0.1:5111/api/zorgax/research?q=provenance%20research%20RAG"

A response may return:

{
  "ok": true,
  "query": "provenance research RAG",
  "count": 1,
  "provenance": "MongoDB ResearchDocument text index",
  "sources": [
    {
      "label": "R1",
      "sourceType": "web"
    }
  ]
}

This separation is useful because retrieval can be tested independently from generation.

Why MyZubster needs an AI entity instead of only an LLM endpoint

An LLM API normally looks like:

prompt → model → answer

Zorgax is moving toward:

identity
+
model
+
memory
+
observations
+
research
+
provenance
+
MyZubster services

That creates a much more interesting building block.

For example, Zorgax could eventually help interpret:

environmental observations
project documentation
ecosystem status
research datasets
technical documentation
operational events
contributor knowledge
MyZubster entity relationships

while still preserving clear boundaries between what the AI knows, what it retrieved, and what the infrastructure allows it to do.

What Zorgax cannot do

This part is equally important.

Zorgax is not:

root access disguised as an AI agent
an unrestricted autonomous crawler
an autonomous Tor crawler
an automatic authority for factual truth
an automatic scientific validator
a replacement for authorization controls
a system allowed to execute arbitrary infrastructure actions simply because the model requested them

Capabilities must be exposed deliberately by MyZubster.

This is the principle:

AI proposes or interprets.
Infrastructure defines authority.
Local-first AI

One of the most interesting characteristics of Zorgax is that it can run on local infrastructure.

In the current deployment, Ollama exposes the model on:

127.0.0.1:11434

while the Zorgax-enabled MyZubster gateway can run on:

127.0.0.1:5111

This architecture lets MyZubster experiment with AI while keeping the model itself behind the local network boundary.

Where this can go next

The current implementation is already enough to demonstrate:

local model
+
persistent context
+
research retrieval
+
source provenance

The next interesting layer is controlled tool use.

Instead of giving an AI unrestricted capabilities, MyZubster can expose individual operations through explicit tools.

For example:

Zorgax
  ↓
tool request
  ↓
policy / authorization
  ↓
MyZubster service
  ↓
result
  ↓
Zorgax

That is much more interesting than simply creating a chatbot with a cyberpunk avatar.

The goal is an AI entity that understands the ecosystem while remaining constrained by it.

The larger idea

Zorgax represents an experiment around a simple question:

What happens when an open-source ecosystem gives a local AI identity structured memory, observations, research, and provenance — but keeps authority outside the model?

MyZubster is exploring that architecture one capability at a time.

Not autonomous everything.

Not invisible magic.

Just explicit tools, inspectable context, local models, and progressively stronger integration.

And that is exactly what makes Zorgax interesting.

Project

MyZubster Ecosystem
GitHub: https://github.com/MyZubster-Ecosystem

Zorgax entity:

ZORGAX-001

Current focus:

Local AI
Research RAG
Persistent Memory
Observation Registry
Provenance
Controlled Tooling

More experiments coming soon.