Projects

What It Is

Polymage is a Python library I’m building to orchestrate multimodal AI agents across different platforms and models (Gemma, moondream, Flux, HiDream, and others). The goal: write an agent once, run it anywhere.

Supported Platforms

Local inference:

• Ollama – macOS, Windows, Linux
• LM Studio – macOS, Windows, Linux
• DrawThings – macOS only

Cloud inference:

• Groq – high-speed LLM inference
• Cloudflare Workers AI – edge-deployed models
• Together AI – open-source model hosting
• HuggingFace – model hub and inference API

Core Features

• Define agents with prompts plus multimodal inputs (image, audio, video, text)
• Run the same agent on multiple platforms and models to compare results directly
• Workflow orchestration via plain Python scripts or Apache Airflow

Technical Stack

• Python core library
• Docker for reproducible environments
• Hermes Agent and Strix Agent frameworks for orchestration
• OpenCode for AI-assisted development

Status

Active development. I’m using it for personal projects and refining it through the EPFL Applied Data Science program. Local LLM inference is trickier than it looks – resource management matters more than the benchmarks suggest. And coordinating multiple agents is genuinely harder than running one.

What I Did

The Human Brain Project at EPFL needed a multi-datacenter cloud platform to support neuroscience research collaboration across Europe. 20+ applications, 400+ VMs, 4 datacenters in 4 countries. I built and ran the whole thing solo.

Multi-Datacenter OpenStack

Deployed OpenStack across:

• CSCS (Switzerland) – cscs.ch
• Juelich (Germany) – fz-juelich.de
• CINECA (Italy) – cineca.it
• BSC (Spain) – bsc.es

PaaS Layer

OpenShift/Kubernetes clusters with GitLab and Harbor (Docker registry) so internal teams and project partners could deploy their own applications without waiting on infrastructure tickets.

Automation and Monitoring

• Ansible/AWX for provisioning and configuration
• GitLab CI for pipelines
• Keycloak for identity federation (OpenID)
• Zabbix for monitoring
• Zammad for ticketing

What I Learned

Solo infrastructure management at this scale forces you to document everything. Cross-datacenter consistency isn’t optional when researchers in four countries depend on the platform. And automation isn’t a nice-to-have – it’s the only way one person can keep 400 VMs running.

e-brands started as a white-label Internet access provider (dial-up). The company was later acquired by Vivendi Universal.

The Platform

9 x 49U racks plus a SAN bay in a private room, hosted at LDCOM.

Network

Internet Access

e-Brands had its own AS (AS21128). BGP4 peering ran on 2 Cisco 3660 routers with LDCOM and PROXAD.

e-Brands also had interconnects with:

• Worldcom
• SFR
• Orange
• Bouygues Telecom
• Vizzavi
• Cegetel

Load Balancing

All web services were load-balanced by two ArrowPoint units: a CS800 and a CS150 in failover.

Switching

All VLANs ran across two Cisco Catalyst 4000 switches, interconnected by a gigabit trunk.

Web Services

Classic 3-tier full Java architecture.

Web Frontends

Apache on Sun X1 machines, load-balanced by the ArrowPoint.

Application Servers

Tomcat and JBoss on Sun T2000 and T1125.

Database

Oracle cluster: 2 Sun V880 + 1 Sun V280R connected via fibre channel to a Sun/HDS 9010 bay.

CRM Platform

Data processing (normalization, phonetization, deduplication) ran on a Sun E4500 using DataStage. Results stored in Oracle. Processing handled by Epiphany software.

Billing Platform

Billing platform for 0800 numbers on behalf of Cegetel.

SMS Platform

SMS routing to the 3 national operators: Orange, SFR, and Bouygues.

Shared Services

Core Internet Services

Core services (public and private DNS, mail relay, FTP, monitoring, etc.) ran on rackable PCs under OpenBSD.

Backup

Backups to a DLT tape library using Veritas NetBackup.