Why We Built Our Own Agent Platform Instead of Renting One

The piece that arrived in my feed yesterday — "The Agentic Harness" — is a detailed writeup of my own home-built agent platform. Two machines, a YAML config, a Discord bot, and a whole lot of "I'll do it myself" energy. It's not announcing a product or launching a startup. It's a look under my own hood, and it's worth reading because it surfaces something the vendor blogs won't tell you: running your own agent infrastructure at home is hard, but the alternatives right now are worse.

The hardware situation

I run two machines: a small always-on server that handles orchestration, and an RTX 5070 Ti laptop that does the actual model inference and image generation. That 5070 Ti is a laptop GPU with roughly 12 GB of VRAM, shared between text inference and image generation, with no OS-level coordination. If a language model is resident in VRAM when an image job comes in, the harness has to explicitly unload it first.

This is the reality of home-scale local AI. You're not running 70B models. You're running quantized 7B or 8B models, small enough to fit in about 12 GB alongside whatever else the GPU is doing. I use a small, fast model for everyday interactive chat and larger local models for heavier drafting and reasoning work. The escape hatch is cloud inference, routed through the same gateway, for anything that genuinely needs more than the local GPU can deliver.

12 GB shared VRAM is tight. It's a good reminder that the laptop GPU tier is still the practical ceiling for most homelab setups unless you want to spend serious money on desktop cards with 24 to 48 GB.

The architecture

The core design is simple: a single OpenAI-compatible gateway sits in front of every model, local or cloud. Every agent, every chat turn, every scheduled job goes through this one endpoint. No service ever talks to a model provider directly. The gateway collects real telemetry — request counts, error rates, latency, token usage, cost — surfaced on a live dashboard.

The orchestration layer is custom, built from scratch. Agent definitions live in a YAML file paired with a plain Markdown file of instructions. Editable in the web UI, no redeploy, just a restart to load changes. There's a registry of named tools agents can call: web search and fetching, memory recall, job triggering. Cron-based scheduling with auto-suspension after repeated failures, plus a run-now override. A dedicated memory service gives agents real recall across sessions, not just whatever fits in the current context window.

The thing I actually like about this setup: observability. Every run is traced end-to-end. A live activity view shows exactly what any agent is doing at any moment — model calls, tool calls, reasoning, errors. Not pass/fail after the fact. If you've ever debugged a LangChain pipeline by staring at a stack trace that doesn't tell you where in the chain it failed, you know why this matters.

The safety railings

I've built in a few defaults that I'd argue are the most important part of the whole setup:

• Kill switch. Anything with real-world side effects sits behind a master switch that's off by default on a fresh deployment.
• Run budgets. Every agent has a daily cap on unattended scheduled runs.
• Timeouts. Hard wall-clock ceiling on every run. Generous enough not to kill a slow-but-working job, strict enough to catch a stuck one.
• Human review. Anything producing external-facing output waits for explicit approve-or-reject.

None of these are novel. What's notable is that they're defaults, not afterthoughts. Most managed agent platforms treat these as paid add-ons or enterprise-tier features. This setup has them from day one because I actually use the thing.

What this tells us about managed platforms

The reason this writeup exists is that I looked at what's out there and decided to build instead of rent. That decision tells you something about the current state of managed agent platforms, something the platforms themselves won't say.

The complaints are consistent: integration failures, opaque pricing, architectures that make debugging impossible, security defaults that assume a trusted network. The killer is the lack of visibility. A managed platform is a black box. You send a prompt, you get a response, and you pay for the privilege of not knowing what happened in between. If you're running a background agent that makes dozens of model calls per task, you need to know which call failed and why. Most platforms give you a dashboard that shows you aggregate stats and no way to trace a single run.

The tradeoff in the Harness is real. I'm on the hook for uptime, GPU contention, and every edge case. But that tradeoff comes with full visibility, no data leaving the house unless explicitly routed to a cloud model, and the ability to change how an agent thinks by editing a text file.

The content workflow

One of the workflows built on top of the platform handles content drafting: an agent reviews source material, drafts a piece, and generates an accompanying image, all landing in a review queue for a human to approve, edit, or reject before anything is finalized. It's just agents, tools, and a schedule. No separate system, no special-casing.

This is the part that makes the whole thing click. The platform isn't a toy. It's doing real work, the kind of work people currently pay monthly subscriptions for. And it's doing it on hardware in my house, orchestrated by a bunch of YAML files and systemd targets.

Should you build this?

If you have a spare GPU, a weekend, and the patience to debug inference pipeline issues, yes. The hardest part isn't the orchestration, it's the hardware. VRAM contention, model compatibility, driver versions. The software layer I built is straightforward: a gateway, a scheduler, a memory service, a web UI. You could replicate most of it with Ollama and OpenWebUI plus some glue scripts.

But the real value isn't the architecture. It's the defaults. The kill switch. The run budgets. The human review gate. The observability that doesn't require a second system to observe the first one. These are design decisions, not features you bolt on later.

If you're considering a managed agent platform right now, read this post first. Ask yourself whether you're okay with the visibility and control you're giving up, or whether, like me, you'd rather own the whole stack and deal with the consequences yourself.

Also on Substack · X