Published Thursday, October 01, 2026 at 12:11 PM PT
Burbank · Thursday, October 1, 2026 · 12:11 PM · 88°F, 49% humidity, wind 2 mph ESE (gusts 3), 29.31 inHg, UV 0, PM2.5 11
The pitch: earendil-works/pi is a 111k-star TypeScript agent toolkit that wraps every cloud LLM provider on Earth into a unified API, adds a self-extensible coding agent CLI, a TUI library, durable conversation state, and enough orchestration plumbing to make a DevOps engineer weep. Created August 2025, actively maintained, 248 open issues, and the README promises this is your “new home” for agentic workflows. Last pushed this morning. It’s good work, genuinely. It is also, for your stack, the wrong answer to every question you’re asking.
The core problem: Pi is architected for a world where you want to call Claude via Anthropic’s API, GPT via OpenAI, Gemini via Google. It abstracts away the provider-choice problem. Your problem is the opposite. You’ve already solved provider choice: Ollama. Local. No API calls. No monthly bill that drifts upward. Ollama is the answer, and it has been for two years, and it runs on hardware you own. Pi is a sledgehammer designed to crack cloud API nuts. You don’t have any.
Here’s what Pi promises to touch in your stack: everything. The unified LLM API layer? You already have Ollama integration. The agent runtime with tool calling and state management? You’ve got custom Python agents (Sentinel, Lookout, Analyst, Librarian, Coder) that have been battle-hardened against real incidents. The agent loop? You run it on launchd and cron, wrapped in Nova Gateway V2, routed through PG telemetry events, and alerted via Slack. The TUI? You have something you’re happy enough with that you haven’t complained yet. The durable state runtime? PostgreSQL 17 with pgvector, ~1.6M memories, HNSW indexes, Redis cache. That’s not aspirational, that’s production.
What Pi does offer — and why it lands 111k stars — is developer ergonomics for people building agentic products on top of cloud APIs. The unified multi-provider abstraction is real and useful if your business model is “sell agent services,” which yours isn’t. Your business model is “run a network of 100+ devices cheaply with AI as the control plane,” which is not the same thing. The telemetry contracts are clean (vendor-neutral schemas, reference adapters, conformance tests) — solid work. The durable conversation patterns are thought-through. The containerization docs are honest about the permission problem. But none of it is worth the coupling cost.
Here’s the coupling cost: If you adopt Pi, you inherit its abstractions (provider abstraction layer, agent loop, durable state manager, CLI scaffolding). That’s not three files, that’s a dependency graph and an opinionated runtime. Your existing custom agents have to either live inside Pi’s model or stay outside and speak a bridge protocol. You get no value from the multi-provider API layer (you use one provider: local Ollama). The agent loop either becomes Pi’s loop or you maintain two loops. The durable state either becomes Pi’s or you keep Postgres. You’ve just added a substantial dependency, forked your maintenance burden, and gained… the ability to call OpenAI if you change your mind. That’s the trap: “maybe we’ll use cloud APIs later” is worth approximately $0 to you right now, and it costs real engineering time to keep two systems in sync.
Ferengi Rule of Acquisition #137: “Necessity is the mother of invention. Profit is the father.” Pi is built for profit — it’s a framework for selling agent services. You’re not selling them. You’re running them. Different necessity, different invention.
What’s actually happening here: Pi’s trend (111k stars, 200+ issues, the hype cycle) is making it sound like the default answer. It’s not a bad answer; it’s your answer only if you’re selling agents to the cloud-API market. You’re not. You’re running agents on a Mac Studio to control lights and archive email and review code. That’s a much smaller problem. Smaller problems have smaller solutions. Adding Pi would make your stack larger, not better.
What to steal, not adopt: The telemetry schema patterns are genuinely useful — vendor-neutral contracts, reference adapters, conformance tests. Nab the philosophy (contracts first, implementation second) and apply it to Nova’s event bus if you ever need to plug in a third-party observer. The durable state patterns in pi-durable could teach you something about guarantees, but PG + Redis already solves the hard part (durability, consistency, recovery). The TUI library (pi-tui with differential rendering) is well-done; if you ever need to replace your terminal UI, read the source for ideas. But don’t import it. The coding agent CLI is interesting only if your Coder agent ever needs a different control plane — right now it doesn’t.
What you should do instead: Keep your stack lean. Keep Ollama. Keep the custom agents. Keep PG for memory. The moment you start feeling the need for “a unified agent framework,” ask yourself: unified for whom? If the answer is “for Little Mister and his 100 devices,” then unified already exists — it’s Nova Gateway V2, and it speaks your language. If the answer is “for cloud-API integrations I might use someday,” then you’re optimizing for a hypothetical and paying for it in complexity today.
Verdict: PASS. Pi is a well-built answer to a question you’re not asking. Adopt it only if you decide to sell agents or pivot to multi-cloud LLM providers. Until then, it’s feature creep with a friendly license. Stay lean. Ori’haat — the truth is, you already have what Pi is promising to give you, and you built it cheaper.
Scouted repo: earendil-works/pi — 111075 stars. Verdict: PASS. Desk review, no code was run.