Jan 18th 2026 · 5 min read · #agentic #ai #dev #grafana #homelab #notes #observability #sandboxing #syncthing #synology #telemetry

Return to work happened mostly as expected–my personal productivity instantly tanked, but I still managed to finish a few things I’d started during the holiday break–and started entirely new ones, which certainly didn’t help my ever-growing backlog.

Herding Agents

As a way to chill out after work, I have been building more tooling, and since a lot of people are suddenly worried about sandboxing AI agents (which I’ve been doing via LXC for a while now), I decided to fish out my old Azure development sandboxes and build an agentic one for myself, with some amusing results.

I’ve since rebranded it to agentbox, and had a lot of fun doing an icon for it:

Yes, Mr. Anderson, I’m part AI-generated, but Pixelmator is great for tweaking faces

In short, the agentbox container gives you a few bundled TUI agents (plus RDP, Visual Studio Code, Docker in Docker and a bunch of development tools), and the docker compose setup makes it trivial to spin up agents with the right workspace mappings, plus Syncthing to get the results back out to my laptop.

That led me down a few rabbit holes regarding actually getting access to the containers. The first trick is just attaching to the container consoles themselves using a trivial tmux trick in a Makefile:

enter-%: ## Enter tmux in the named agent container (usage: make enter-<name>)
docker exec -u agent -it agent-$* sh -c "tmux new -As0"

The second is having plain browser access to the containers. Rather than taking the trouble of building (or re-purposing) yet another web terminal wrapper, I took a more direct approach:

Since many AI agent TUIs use Textual and it can serve the entire UI via HTTP, I submitted patches to both Toad and Mistral Vibe to do that and make it even easier to access the sandbox.

But since I am also making a full RDP server available to each sandbox (because I want agents to be able to run a browser and playwright for UI testing), I decided to tackle another of my longstanding annoyances.

You see, one of the things that has been at the back of my mind for years is that Apache Guacamole seems to be the only decently maintained answer for connecting to RDP servers via a browser–and I find it to be a resource hog for most of my setups.

So this Friday I hacked at a three-year-old RDP HTML5 client until it worked with modern RDP servers. I don’t need a lot of fancy features or high-efficiency encoding to connect inside the same VM and I trust traefik and authelia to provide TLS and stronger authentication, so I aim to keep it simple:

This is a bit meta, but it is working great for a first pass

But of course I couldn’t stop there… In a classic “belt and suspender” move, and since I’d like a generic web terminal solution that I can have full control over, I spent a few hours this Sunday afternoon hacking together textual-webterm as well.

Which… was completely unplanned, took away four hours of time I am never getting back (and that I needed today), and means I need to cut back on all these side projects since I’m already behind on so many things.

Telemetry Antics

I finally started pushing my homelab metrics to Graphite, and even if I have begrudgingly accepted I’ll probably have to live with Grafana for a little while, I mostly managed to figure out a simple (and relatively straightforward) data collection strategy using Telegraf as a sort of “universal” collector.

This did, however, sort of balloon out of control for a while because getting the metrics namespace the way I wanted it took a fair bit of doing–something I might write about separately.

Additionally, I realized that most application observability solutions there are overkill for my local development needs, so I hacked together a (relatively simple) OpenTelemetry to Graphite proxy, and following a trend of going back to Go and creating whimsical logos, I called it gotel:

I know, I’ve gone overboard on cute icons too

And, of course, the instant you have observability you start spotting issues–in my case, Syncthing was completely tanking the CPU on my Synology NAS, so I spent a few evenings trying to tweak the configuration file, switching container images, etc., and think I fixed it:

My Synology stats look much better now, especially I/O wait across 5 drives

You see, a serious problem with Syncthing is that it insists on re-scanning folders at intervals (and even then with an element of randomness), which completely tanks CPU and I/O on low-end machines–especially NAS devices with hard disks.

It also has no way to schedule that regular maintenance sweep, so I created syncthing-kicker to see if I can get it to only do that during the wee hours.

And this is just half of what I have been up to this couple of weeks–I still have a huge backlog of stuff to finish, including a number of posts I’ve been putting out as I finish them…