Building ZORGAX: From a Local AI Model to a Server Operations Agent for MyZubster

Connecting Ollama, Docker, Open WebUI and a custom AI assistant — and learning why reliable tool calling matters.

We're working on a new capability inside the MyZubster ecosystem: ZORGAX, an AI assistant intended to help observe, diagnose and eventually manage technical infrastructure.

Our goal isn't simply to create another chatbot.

We want an AI agent that can understand what's happening across our servers, services and software projects — while operating under explicit permissions and human oversight.

Here's what we've built and tested so far.

1. Our current infrastructure

The pilot environment includes:

• Ubuntu 24.04 LTS running on our VPS
• Docker and Docker Compose for isolated services
• Ollama for local LLM inference
• Qwen 2.5 3B as the foundation model
• ZORGAX, our custom Ollama model
• Open WebUI as the conversational interface
• N4K48, our independent AI integration pilot
• Qdrant for vector infrastructure

The architecture allows our AI services to communicate internally without exposing the Ollama API directly to the public internet.

2. Connecting Docker applications to Ollama

One of our first challenges involved networking.

Ollama was available at:

http://172.22.0.1:11434

But Open WebUI was configured to use:

http://host.docker.internal:11434

Inside the container, that hostname resolved to 172.17.0.1, where requests timed out.

We corrected the Open WebUI connection to the reachable Ollama endpoint and verified it with an API request.

The result:

HTTP: 200

Models:
- nomic-embed-text:latest
- zorgax:latest
- qwen2.5:3b

CONNECTION: OK

We also introduced a systemd socket proxy to make Ollama accessible through the VPS loopback interface:

127.0.0.1:11434

This preserved the existing Ollama listener used by Docker.

3. Testing actual model inference

Connectivity alone isn't enough.

We tested text generation directly from the Open WebUI container using Ollama's /api/generate endpoint.

The result:

RESPONSE: OLLAMA OK
DONE: True

The Open WebUI container subsequently passed its healthcheck:

running / healthy
HTTP 200

We then connected through an SSH tunnel and successfully interacted with ZORGAX in the browser.

At this stage, we had working infrastructure and a functioning conversational AI.

But the next challenge was more interesting.

4. The tool-calling loop problem

We asked ZORGAX to identify which tools it could actually use.

It invoked a function called:

list_automations

The tool returned:

{
  "automations": [],
  "total": 0
}

Instead of terminating the process and reporting that no active automations were found, ZORGAX repeatedly called the same function.

We observed one sequence reaching 28 calls and another reaching 16 calls.

This exposed an important engineering problem.

An AI agent must not confuse the ability to call a tool with the ability to manage a workflow reliably.

Repeated tool calls are inefficient. More importantly, they could become dangerous if the tools eventually acquire permissions to modify real infrastructure.

5. Isolating the issue

We tested ZORGAX directly through Ollama, without Open WebUI.

First, we confirmed that it could answer normally without tools.

Then we simulated a complete tool interaction:

1. The user asked how many active automations existed.
2. ZORGAX requested list_automations.
3. The test supplied an empty result.
4. ZORGAX responded that no active automations were available.

There was no repeated tool call in that controlled test.

This suggests that the problem requires further investigation into the Open WebUI tool execution path, model configuration and calling behavior.

It does not yet establish a single root cause.

6. What comes next: ZORGAX as a server operations agent

Our next objective is to move beyond conversation and build a carefully controlled operational assistant.

The first planned capability is:

myzubster_server_status

This will be a read-only tool for collecting selected infrastructure health information.

The long-term roadmap includes:

Phase 1 — Observation

Read-only server metrics, Docker container health, systemd service status and selected application healthchecks.

Phase 2 — Diagnosis

Analyze bounded logs, identify anomalies and suggest possible explanations.

Phase 3 — Project intelligence

Review repository status, test results and project diagnostics without automatically merging or deploying changes.

Phase 4 — Authorized operations

Execute predefined maintenance actions only with explicit approval, restricted permissions and audit logging.

We are intentionally not giving the AI unrestricted root access or direct control over the Docker socket.

7. The main lesson

Building an AI assistant is relatively straightforward.

Building an AI agent that can interact reliably with real systems is a different engineering challenge.

The important questions become:

• Can it distinguish facts from assumptions?
• Can it interpret tool results correctly?
• Can it avoid duplicate or unnecessary operations?
• Can it stop when an operation is complete?
• Can it operate with least-privilege permissions?
• Can every consequential action be audited?

For MyZubster, these are not optional details. They are foundational requirements.

Conclusion

ZORGAX is now functioning as a conversational assistant through Ollama and Open WebUI.

We have validated container connectivity, model inference and a controlled example of tool calling.

The next stage is improving tool execution reliability and introducing a read-only infrastructure monitoring interface.

Our direction is clear:

From a local AI model to a permission-controlled infrastructure assistant — one verified capability at a time.

This is an ongoing development experiment, not a production-ready autonomous system.

More engineering notes will follow as we test each component.

---

Built as part of the MyZubster ecosystem and the N4K48 independent AI integration pilot.