<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Build Log on ./Sam_Stelfox.sh</title><link>https://stelfox.net/projects/hive/logs/</link><description>Recent content in Build Log on ./Sam_Stelfox.sh</description><generator>Hugo</generator><language>en-US</language><copyright>Copyright © 2008, Sam Stelfox, all rights reserved.</copyright><atom:link href="https://stelfox.net/projects/hive/logs/atom.xml" rel="self" type="application/rss+xml"/><item><title>Why Build Another Agent Harness</title><link>https://stelfox.net/projects/hive/logs/why-build-another-agent-harness/</link><pubDate>Sat, 04 Apr 2026 12:00:00 -0400</pubDate><guid>https://stelfox.net/projects/hive/logs/why-build-another-agent-harness/</guid><description>&lt;p&gt;There are a lot of agent harnesses out there. So why build another one?&lt;/p&gt;
&lt;p&gt;I've spent a lot of time in this space. I built several small agent systems in both Rust and Python, tried most of the popular frameworks, ran models from all the major providers and a bunch of open ones, experimented with custom LoRA layers and spec-driven task systems. Every setup taught me something about where things break down and I kept notes along the way.&lt;/p&gt;
&lt;p&gt;What I wanted wasn't exotic. A system that runs on my hardware, manages agents as durable long-lived processes, connects to the communication channels I already use, and enforces real security boundaries between agents and data. Capability-based access control, taint tracking, domain isolation, per-process network filtering. These are all well-understood ideas with decades of prior art. The agent ecosystem just hasn't prioritized them yet because everyone's working on different problems.&lt;/p&gt;</description></item></channel></rss>