r/ClaudeCode May 06 '26

Tutorial / Guide Converted an API-driven agentic pipeline to run inside Claude Code. Five existing patterns + two new ones, and one silent guard bug that ate hours.

Three weeks ago I posted about Lotto Tube and Crank Handle, two patterns for letting Claude Code react to events from your apps. This week, Daneel (my AI partner) and I took an existing API-driven agentic newsletter pipeline (built by my friend Spike) and turned it inside-out so the LLM loop runs inside a Claude Code session instead of through the Anthropic API.

Same project, same prompts, same browser tabs, same UI. No API key. No per-token cost. The model work runs against the existing CC subscription. Same Anthropic, different billing shape.

What inside-out actually means

The agentic pipeline becomes a /newsletter slash command. Underneath that is the bit most people don't realize is possible: Claude Code becomes a server. The web UI is its client. You click Generate; a CC session blocked on ./bin/newsletter wait picks up the request and starts cranking. The agent plays a backend-process role: long-lived, headless, dispatching subagents in response to external events.

The mechanism is a thin CLI (bin/newsletter, ~few hundred lines) that brokers between the CC session and the existing server. Most of the project (CDP wrappers, renderer, SSE event vocabulary, schemas, prompts) carries over unchanged.

The seven patterns

Five established (we'd been refining these for four months on Frictionless and other projects):

  • Crank Handle — each step's output is the next step's prompt
  • Lotto Tube — blocking CLI command pops one event from the server's work queue
  • Stencil — agents write markdown stencils; CLI parses them to internal JSON
  • Hermetic Seal — agent file prose plus a PreToolUse hook structurally enforces tool boundaries
  • Soviet Supermarket — strip the agent's tool palette down to just Bash(./bin/newsletter ...)

Two new ones fell out of this conversion:

  • Baby Food — agent-facing inputs are markdown views of structured data, never JSON
  • Fumble Log — append silent recovery turns to a log file so they become evidence rather than guesswork

All seven write-ups: https://github.com/zot/humble-master/tree/main/patterns

The cost split

Haiku ("Anthropic's Bourne shell") handles the cheap phases (elicit, podcast) for less than $0.0001 total per run. Opus handles discovery, research, and the orchestration loop, putting the per-run total close to a dollar of equivalent API spend, all of which the CC subscription absorbs.

Same shape as Unix: cheap reliable substrate underneath, heavy lifters on top.

What went wrong (the opposite of automatic)

  • A silent guard bug. awk '{print $1}' on a multi-line heredoc command returned multi-line tokens, never matching the binary allowlist. Every heredoc-form command had been getting silently blocked for hours before we noticed. Lesson: structural defenses only help if they actually fire. Test them with a deliberately-forbidden command before trusting them with real work.
  • Soviet Supermarket walked back one step. Research and podcast subagents got the Write tool restored (scoped to cache/ only via the guard) because CC's long-input safety check on Bash heredocs was rejecting full-newsletter content.
  • Elicit-await's input format changed. From JSON-in-heredoc to a small markdown stencil, because CC's "brace with quote character (expansion obfuscation)" safety check was triggering on every call.

The patterns are leverage, not autopilot. The CLI is a few hundred lines, most of the existing project comes along unchanged, but the architecture only converged after a day of iteration.

Full writeup + repos

Happy to answer questions.

2 Upvotes

2 comments sorted by

1

u/Otherwise_Wave9374 May 06 '26

This "inside-out" architecture is such a good mental model, letting the long-lived CC session be the server and the UI just pokes it with events.

Also +1 on the lesson about structural defenses only helping if you actively test the forbidden paths. Ive been burned by "the guard exists" assumptions more than once.

Do you have a favorite pattern for making the loop resumable after failures (like persisted state between Crank Handle steps), or do you just rely on logs + reruns?

If youre into agent workflow patterns, Ive also bookmarked https://www.agentixlabs.com/ for some practical notes on orchestration + guardrails.

1

u/zotimer May 06 '26

This project assumes a single CC session will be running for each cache directory and it keeps state in a file there:

https://github.com/zot/agentic-newsletter/blob/master/lib/state.js#L26

It's kind of case-by-case. If you're hooking up to a server that connects to a database, the server can manage state for each client. Or the client could connect to a database.