The 3 questions, ask these no matter what

1

Token economics and model routing

You run a vision model on roughly 5-second screenshots plus Claude agents. You have mentioned Claude Code Max plans, so I am curious how you split work across models: for your own dev and internal agents versus customer-facing traffic, what runs on a small or cheap model versus Sonnet or Opus? And how do you route, statically by task type, or do you try the cheap model and escalate on failure? I am burning Opus tokens on work a Haiku or a local model should handle. Do you use anything outside Anthropic for the cheap tier, local models or open weights?

Follow-ups
  • Do you hit Max plan usage caps running continuously? How do you stay under them?
  • Prompt caching: given a rolling stream of novel screenshots, where do your cache hits actually come from, the stable prefix like the system prompt and wiki context? How much does it save in production?
  • Is there a volume where pay-per-token API beats the Max plans for you?
2

The unattended agent that takes real actions

Highest value

I want an agent taking real actions unattended overnight. In my case that means sending outreach to real prospects, so the actions are irreversible. Your product acts autonomously on Claude around the clock, though your actions are mostly reversible writes like wiki updates and Extension answers, and mine are irreversible sends. Given that asymmetry, what would you add on top of your guardrail stack? Specifically: what are your kill-switches and circuit-breakers, how do you checkpoint for resume so a crash does not lose work, and do you use idempotency keys on the send so a replay never double-fires? And how do you stop it burning the whole token budget in a loop?

Follow-ups (ask the compute-location one first)
  • Where should this actually run? My main dev machine is a single Windows box that is already memory-constrained, but I own a Hetzner CX23 and use Cloudflare Workers. Should the loop live on infra I already own instead of my desktop, and how do you split what runs on-device versus in the cloud?
  • When it runs unattended, how do you get enough observability to trust the output without reading all of it? What does your monitoring and alerting look like for autonomous runs?
  • Where is your line between an agent that acts on its own versus one that drafts and queues for human approval?
  • What orchestrates the loop, a cron job, a queue, a durable workflow, or Claude Code itself?
3

Data layer: state and retrieval

Two data problems. First, state. For an autonomous pipeline I need real state: a dedup and suppression lookup so I never contact the same entity twice, idempotency keys on the send operation so a retried run never double-sends, and a per-lead status. My lead data is split across Notion and scattered JSON today. What is the minimum real datastore you would stand up for that, and do you keep structured state separate from prose knowledge? Second, retrieval. You auto-build a hyperlinked wiki your teammates query. What is underneath it, a graph database, a vector store, files plus embeddings, or a hybrid, and why? My knowledge base is a few hundred flat Obsidian markdown files that Claude greps, with roughly 3,000 leads in the CRM. At what scale does grep-over-files stop working?

Follow-ups
  • Contacts and CRM: I keep lead and client data in Notion plus markdown. Would you put structured contact data in a real database and keep the prose in files, or unify it?
  • How do you keep an auto-generated wiki from rotting over time, dedup and contradiction detection?

Build versus buy

Build versus buy

You have built a system that auto-maintains a wiki, watches work, and dispatches agents. Honest read: where does knowledgework.ai fit for a two-person agency that already lives in Obsidian and Claude Code? Would it replace my vault, feed it, or sit alongside it? What would you not use it for?

Concrete fit probe: do you integrate with Notion today? My CRM lives in Notion, so does knowledgework feed it, replace it, or leave it alone?

He may pitch here. That is fine, you may want the product. Just do not let the pitch eat the three spine questions.

Lead with genuine curiosity. The relationship is the prize, not any single favor. In priority order:

  1. Would he be open to a periodic architecture check-in, an informal advisor relationship? Highest value.
  2. Feedback on your specific setup if you send a one-page diagram after the call.
  3. Tools and stack he would recommend for your scale.
  4. Intros to others solving similar problems, through the Alignable connection.

Do not stack all four on a first call. Ask number 1, offer to send the diagram, let the rest come naturally.

  • Do not ask what you can Google. He is senior. Ask only what he uniquely knows, his production decisions and war stories.
  • Do not ask him to design your whole architecture live. Ask for the decision plus the reasoning, then you build it.
  • Let him talk. Your job is sharp questions plus good follow-ups, not to show what you know.
  • If he goes deep on one thing, follow it. Do not rush back to the list.
  • Watch the clock. Spine questions in by the halfway mark.
  • Ask to record or take notes, with his permission.
Reserve questions, only if time
  • Vision model: why build a bespoke long-context vision model instead of OCR plus text? What did OCR get wrong that justified building your own? (His home turf, a good rapport question.)
  • Security: your app sees everything on screen, including secrets and credentials. How do you handle sensitive data in the capture pipeline? (Directly relevant to your own credential-hygiene rules.)
  • Highest leverage: if you were advising a two-person technical agency running everything on Claude Code, what are the two or three highest-leverage engineering investments to make first?
  • Starting over: what would you build differently if you started the whole system today?
  • Two-person team: I run this with my partner Chase, and a lot of our friction is one of us re-answering something the other already figured out. At what team size does the Extension model start paying off, and what have two-person teams actually told you about it? Skip this if the build-versus-buy discussion already covered it.
  • Autonomous reply-handling: as outbound scales, replies scale. Where do you draw the line between an agent that answers a prospect on its own and one that drafts for my approval? How did you decide what your Extension answers autonomously?
Who he is + 60-second context

Griffin Bishop. Founder of knowledgework.ai. MS in Computer Vision, ex-Amazon (Software Development Engineer at Amazon Robotics, roughly 2020 to 2022), then engineering roles at a few startups before founding this. Reported co-founders: Neil Vachharajani and Pete Schlampp, both senior operators, which is a strong signal on the team's depth.

Calibration, so you pitch your questions at the right level: the "lead developer at Amazon, one of the best in the country" framing came to you secondhand and runs warmer than the public record. His Amazon stint was about 1.5 years as an SDE, not a lead or principal role. What is solid and verifiable: he is a genuine computer-vision specialist (his MS is in exactly the thing his product runs on, a bespoke vision model), he has shipped a hard production system on Claude, and his co-founders bring real scale experience. Treat him as a very strong applied-ML and systems engineer. Aim your questions at vision, agent-systems, and token economics where he is deepest. Do not over-index on the Amazon title.

What he built, and why it matters to you

  • A Mac app that screenshots your screen roughly every 5 seconds and runs a bespoke long-context vision model over it, like an intern shadowing you.
  • Auto-builds a hyperlinked wiki plus a searchable timeline of how you spent your time.
  • Creates an "Extension," an AI clone of you that teammates can query about your work.
  • Runs on Claude. He has referenced Claude Code Max plans, though a commercial multi-user product may also run on the pay-per-token API, which is worth clarifying on the call.

Warm opener if you want one: his edge is computer vision, and the vision model is the coolest part of his product. Asking how he built it is both genuine and flattering. He posts on X. Confirm his current handle before referencing it directly.

60-second context, say this up front

I run a two-person AI agency. Our entire brain is an Obsidian markdown vault that Claude Code reads, writes, and cross-links: wiki pages, SOPs, client records, a CRM. I run multi-agent Claude Code, Opus on the main thread for judgment, Sonnet and Haiku sub-agents for execution, all on Max plans. Three things I want to fix: cut token spend with smarter model routing, run autonomous agent loops overnight, and figure out whether flat markdown is the right data layer or I need a real database plus retrieval. You have clearly solved versions of all three.

Six-month bottleneck audit

The current-state audit is one thing. This is the forward look: what breaks when you 10x volume and take the human out of the loop. The through-line: in six months the bottleneck is not finding leads, it is running a trustworthy autonomous acquisition loop off your desktop without burning domains or budget. Confidence: "stable" is a structural fact, "mem" is from memory and worth a quick sanity check.

Bottleneck Why it breaks at scale Conf Verdict
Unattended action safety An agent that sends to real prospects overnight can fire a bad batch at 2am with no human to catch it. Irreversible. stable Ask Griffin (spine Q2, highest)
Compute location for a 24/7 engine A single Windows box under memory pressure cannot run continuous scrape, enrich, send, and reply loops. stable Ask Griffin (spine Q2)
Data layer for autonomous state Flat markdown plus Notion plus scattered JSON cannot hold dedup, idempotency, suppression, and reply state. At volume it double-sends. stable Ask Griffin (spine Q3)
Token cost of enrichment at volume Per-lead enrichment and personalization at 10x is a linear token blowup without enforced caps and cheap-model routing. mem Ask Griffin (spine Q1)
Observability and kill-switches An unattended loop that fails silently at night spams prospects and burns domains before morning. mem Ask Griffin (Q2 follow-up)
Per-lead research and retrieval Personalization needs per-entity research, and grep over markdown does not scale to autonomous retrieval. stable Ask Griffin (spine Q3)
Autonomous reply-handling trust As sends scale, replies scale, and where to draw the human-in-the-loop line is a judgment call. mem Ask Griffin (reserve)
Send and deliverability mechanics Domain reputation, sending caps, inbox warmup. Real and rising, but this is outbound-ops, not his domain. mem Fix yourself
Reply capacity and staffing Raw volume of replies to handle is an ops and staffing problem, not architecture. mem Fix yourself
Compliance at scale CAN-SPAM, CASL, and TCPA exposure grows with volume. stable Fix yourself
Concurrent-session state races and deploy discipline More autonomous processes worsen git-index races and clobbers. mem Fix yourself

The reframe: the single most valuable thing Griffin can hand you is the reference architecture for an autonomous, unattended, real-world-action loop, because his product is one. The action-safety, state, and observability bottlenecks fuse into spine question 2.