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.

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

One of our first challenges involved networking.

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.

HTTP: 200 Models: - nomic-embed-text:latest - zorgax:latest - qwen2.5:3b CONNECTION: OK Enter fullscreen mode Exit fullscreen mode We also introduced a systemd socket proxy to make Ollama accessible through the VPS loopback interface:

This preserved the existing Ollama listener used by Docker.

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

RESPONSE: OLLAMA OK DONE: True Enter fullscreen mode Exit fullscreen mode The Open WebUI container subsequently passed its healthcheck:

running / healthy HTTP 200 Enter fullscreen mode Exit fullscreen mode 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.

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

{ "automations": [], "total": 0 } Enter fullscreen mode Exit fullscreen mode 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.

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:

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.

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

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

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

Analyze bounded logs, identify anomalies and suggest possible explanations.

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

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.

Building an AI assistant is relatively straightforward.

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

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

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.

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.