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 →5-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 →We wanted to know whether anyone uses the chatbot on this site, what they ask, and whether it's being abused — without storing a single visitor's IP address. Here's the design: a salted hash that counts a returning visitor but can't identify one, a second hash that catches an attacker probing several of our sites without ever linking ordinary readers across them, and an abuse trail that never holds a raw address.
Read article →5-part series · read in order
In consumer finance, the difference between an AI quality issue and a federal violation is which sentence the model got wrong. This opens a new series on governance where the regulator reads your architecture: the consumer-lending regulatory stack translated into engineering requirements, why a nonbank lender answers to forty-four states plus the CFPB, and how the enforcement layer you already built becomes the compliance evidence you were about to write by hand.
Read article →Every governance architecture eventually faces the same four design-review questions: where enforcement lives, what validation may cost in latency, what happens when the guardrail itself goes down, and whether an LLM is allowed to judge an LLM. Part 2 of Governance in Regulated Rooms works through each trade-off — and argues that the last call, fail-closed versus fail-open, is a business decision that engineering should refuse to make alone.
Read article →Fair-lending law requires that a denied applicant be told the specific, accurate reasons for the denial — and the regulator has said in writing that complex models get no exemption. Part 3 of Governance in Regulated Rooms argues this quietly forbids an entire class of architectures: a generative model in the decision path cannot produce a legally valid reason, because a sampled explanation is a plausible narrative, not a cause. The compliant shape: code decides and explains; the model is allowed to translate.
Read article →The evaluation infrastructure nobody audits is full of customer data: golden datasets built from real conversations, trace stores, labeling queues, red-team corpora. Part 4 of Governance in Regulated Rooms makes the case that under GLBA's Safeguards Rule and FCRA, the test tooling sits inside the regulated boundary — and shows the pattern that makes compliance mechanical: a data manifest the build refuses to violate, retention clocks with dead-man checks, and eval assets carried in the same inventory as the systems they test.
Read article →Two customers ask your AI the same question and one legal answer is a violation for the other, because they live in different states. The closing part of Governance in Regulated Rooms: why jurisdiction is a runtime parameter, why stuffing state rules into the prompt is the anti-pattern, and the compliant shape — policy as data: versioned per-jurisdiction rule tables the enforcement layer consults, an eval matrix that crosses scenario with state, and a dead-man-checked job that screams when the table goes stale against the statute.
Read article →