Ask Jeff: an internal assistant that answers in my voice when I'm not around
An internal-only assistant that answers the team's how-do-I and how-do-I-fix-this questions about the Humbear Platform, Meta ads, and our processes — in my voice, and only from what I've actually documented. Early build, internal use only.
## the problem
I am a bottleneck. The same how-do-I-do-this and how-do-I-fix-this questions come to me over and over — a Humbear Platform workflow, a Meta campaign setup, an audience build, an internal process — and when I am heads-down or out, the team waits on me for answers I have already given a dozen times.
Generic AI is the wrong fix for this. The team does not need a chatbot's best guess at how to run our systems; they need the way we actually do it, which lives in my head and in the SOPs and notes I have written. An assistant that confidently invents a procedure is worse than no assistant, because someone will follow it.
## what I built
Ask Jeff, an internal chatbot for the team. It is scoped tightly on purpose: internal only, never client-facing, never patient-facing. Its job is to answer how-do-I and how-do-I-fix-X questions about the tools and processes we run — Humbear Platform workflows, Meta campaign setup, audience creation, and our internal procedures — in my voice, so it reads like asking me.
The load-bearing rule is what it will not do: it answers only what I have already figured out and documented. It is meant to draw on the SOPs, process docs, and commentary I have written down, not to improvise. If the answer is not something I have established, it should say so rather than guess.
This is an early build — a starter kit at this stage, not a finished product — which is exactly why it is filed here as an internal tool rather than a shipped one. It is documented for the same reason everything else on this site is: the honest state of a thing is more useful than a launch announcement.
## how Claude was actually used
- 01
Scaffolded with Claude Code
The starter kit was built with Claude Code, which is also the point of documenting it: it is another internal system stood up with the same setup the rest of this site describes.
- 02
The guardrail is the design
The whole build is organized around one constraint — answer only from what has already been documented, in my voice — rather than around model cleverness. Getting that boundary right matters more than any feature, because an internal answer that sounds right but is made up is the failure mode that would kill trust in the tool.
## stack
## results (the verifiable kind)
- ✓Scoped and shipped as internal-only: not client-facing and not patient-facing by design.
- ✓Constrained to answer only from documented, established knowledge, so it does not invent procedures the team might follow.
- ✓Documented here honestly as an early-stage internal build rather than presented as finished.
## what I learned
- →For an internal how-to assistant, the constraint matters more than the capability. The rule that it only answers what is already documented is what makes it safe to trust — a confident wrong answer about how to run a real system is the outcome worth engineering against.
- →Not everything I build is a launch. This one earns its place on the site by being an accurate account of an in-progress internal tool, not by pretending to be more than it is.
$ follow --the-build
Watch it happen, don't take my word for it
Every build on this site gets documented as it happens — the prompts, the dead ends, the results. No course at the end of this funnel. There is no funnel.
follow on x →