Writing
The canonical home for our long-form. Most of it runs in series — start at Part 1 and read down. Syndicated to LinkedIn, Medium, and Substack, but published here first.
Read any time
The groundwork the series build on — read these in any order.
The assistant on bleenq.com runs on our own open-source platform: a scoped gateway key, a dedicated public knowledge base, semantic plus graph retrieval, and an outbound-only tunnel so nothing on our network is ever exposed. Here's the architecture, end to end.
Read article →40+ services, one machine, security and observability from day one. Now public — and the launchpad for everything from knowledge-base-powered chatbots to a personal AI voice assistant.
Read article →2-part series · read in order
How we actually build — the operating model behind the software, not just the software.
We build production software with Claude Code by treating the main session as a coordinator, not a coder. It grooms a GitHub Projects board and dispatches an org of ephemeral specialist sub-agents that hold the heavy context, return a result, and evaporate. Here's the operating model, why the orchestrator's context staying lean is the whole point, and how to build your own.
Read article →Our incubator is a program, not a building. Give it a raw SaaS idea and it runs the research a good investor would — market sizing, competitive landscape, unit economics, all adversarially fact-checked — to an honest go/no-go. On a go, it stamps out a new startup already staffed with the full sub-agent org from Article 1. If the org is code, a company is an instance.
Read article →4-part series · read in order
Making AI governance technically enforced, not merely advisory — drawn from the model we run in the open on ai-homelab.
Most AI governance would survive an audit and lose to an attacker, because it lives in a PDF instead of in the infrastructure. This is the model we run instead: Govern, Manage, Enforce — where every policy is bound to a control point that makes it physically true. The gateway won't authenticate an unregistered system. Approval isn't a document; it's the credential. And no security property depends on the model behaving.
Read article →Enforcement starts with an inventory, because you cannot govern a system you don't know exists. This is how we build the AI inventory and the AI bill-of-materials, why the embedding model and the knowledge corpus belong in that bill as attack surface, how T0–T3 risk tiers make control proportional, and the five signals we use to hunt the shadow AI already running inside the walls — plus why the paved road has to be faster than the goat path.
Read article →The dangerous moment is when an AI takes an action. This is the deterministic layer that decides whether it may: the model emits an intent, never an action, and a policy enforcement point validates the schema, binds every parameter to the authenticated session, checks a per-tool authorization matrix, and hands execution to a workflow engine that holds the credentials the agent never sees. Including the prompt-injection test that passes even when the model is fully compromised — because 'the model resisted' is not a pass criterion.
Read article →A governance control you never test is indistinguishable from a control that doesn't work. This closes the series: guardrails as versioned code, an evaluation suite that runs like unit tests and blocks the merge on a regression, the scheduled jobs that check for inventory drift and shadow credentials and fail loudly, and the honest scorecard that marks its own unfinished items instead of claiming completion. Governance as a living system, not a document.
Read article →