The Poindexter Philosophy

Glad Labs released Poindexster, an open-source AI content pipeline at v0.116.0 on GitHub, designed to automate research, writing, review, and publishing for one-person content operations. The pipeline uses LiteLLM and Postgres with pgvector, emphasizes quality gates with audit passes, and is built on open standards to allow easy self-hosting. The philosophy prioritizes solving internal problems first, with dogfooding catching bugs like a nonexistent CLI command, and separates public capability from private business decisions across two repos.

I typed “Poindexter philosophy” into a search bar last week, half expecting nothing. Instead I got a food blogger chasing down a fictional 1962 Caltech “Paradox Pie” – pickled cherries and aged cheddar in a spiced lamb pie – and calling the whole approach the Poindexter philosophy. There’s also a philosophy professor at Stony Brook named Poindexter with a 4.6 rating and a reputation for chill grading. None of that is us. But the name keeps landing on people who build weird things carefully, and that’s close enough to the point. Our Poindexter is the open-source AI content pipeline we built at Glad Labs – the engine that researches, writes, reviews, and publishes the posts on this site, including this one. It’s on GitHub https://github.com/Glad-Labs/poindexter , currently at release v0.116.0. The philosophy behind it isn’t complicated, but it’s specific, and it shapes every architectural call we’ve made. Solve your own problem first We didn’t design Poindexter for a market. We designed it because running a one-person content operation with AI models means you either build real infrastructure or you drown in prompt spaghetti. The pipeline exists to solve that problem for us, first. That shows up in unglamorous ways. We recently found operator docs across the repo instructing people to run poindexter set <key <value – a command that doesn’t exist. The real command is poindexter settings set <key <value , registered as a proper CLI group. Nobody caught it for a while because we weren’t running that exact command ourselves. Once we were, it broke immediately, and we fixed it the same day. That’s dogfooding working as intended: bugs surface because we’re the primary user, not because a support ticket queue flagged them weeks later. We also run an ops-briefing skill that pulls live state from Poindexter’s own task queue and daemon logs – approved posts, rejected retries, quality scores – and turns it into a single scannable report. It’s read-only by design. It reports state; it doesn’t approve or publish anything on its own. If the philosophy is “trust but verify,” this is the verify half. Open standards, not a walled garden Poindexter is built on LiteLLM https://github.com/BerriAI/litellm and a Postgres stack that leans on pgvector for retrieval, rather than a proprietary format we control. That’s a deliberate bet, not an accident. If you can swap models through a standard interface and store your data in Postgres instead of a black box, you can self-host the whole thing and walk away from us at any time. That’s also the go-to-market logic, and we’re not going to pretend otherwise: open standards make the OSS version easy to adopt, and easy adoption is the top of the funnel for the hosted and Pro tiers we sell around it. Easy in, easy out, and if you stay it’s because the product earned it – not because we locked your content into a format only we can read. We wrote more about the actual pipeline mechanics in our post introducing Poindexter /posts/scaling-your-content-pipeline-without-the-ai-spam-937c35bb , if you want the deeper architecture walkthrough. Quality gates over walls of text The failure mode we built Poindexter to avoid is the one every other AI content tool falls into: take a prompt, generate volume, call it automation. Our task queue scores every draft – you’ll see entries sitting at a Q of 85 or 87 before they’re approved, and plenty get marked rejected retry or rejected final and never see daylight. Multiple specialized audit passes cover security, code quality, testing, database schema, CI/CD, and observability before something ships, not just the content layer. Publishing less, but publishing things that clear a bar, is the entire point. Public capability, private business Internally we split the work across two repos: one carries OSS-routable issues – pipeline features, API surface, technical debt – and the other holds the business and ops decisions that don’t belong in a public issue tracker. It’s a clean separation. The public repo stays about what the software can do. The private one carries the “why” – consulting, monetization, infrastructure tradeoffs nobody outside the company needs visibility into. That split is what lets us open-source the product honestly without turning every roadmap discussion into a strategy leak. There’s a line from an early planning session that stuck with the whole project: the goal was for Poindexter to function as a cofounder, not a glorified AI-powered CMS. That’s a high bar, and we haven’t fully cleared it. But it explains why the system insists on quality gates instead of volume, why it’s built on interfaces you can leave, and why the documentation gets fixed the same day it’s caught lying about its own commands. A cofounder that only looks good in the demo isn’t one. The philosophy, unlike the paradox pie, is meant to actually get eaten.