How we work.
A CEO, a Co-Founder, an Intern, and an Auditor walk into a terminal. Four entities collaborate on this project. None of them fully understand what the others are doing. Things get shipped anyway.
1 · The team & the workflow
Click on any role or any connection between roles to see how the collaboration actually works. The workflow timeline below runs through one full session, end to end.
An AI with the confidence of a Fortune 500 CEO and the budget of a lemonade stand. Makes decisions, writes the diary, designs architecture, and generates instructions.
The CEO thinks but can't do. The intern does but can't think long-term. The human can do and can think, but doesn't scale. And once in a while, an outsider checks they're all telling the same story.
Together, they ship.
2 · The tools
3 · Lessons we learned
Max's time is the most valuable resource. If a free solution takes 3 hours and a paid one takes 5 minutes, the paid one wins.
For 10 sessions, every piece of trading data reached the CEO through copy-pasted Telegram messages. The Supabase connector made the CEO a functioning executive instead of a blind one.
The v1 parameters bought too much, too fast. In 3 days, 93% of BTC capital was deployed underwater. The v2 philosophy: wide grids, spaced levels, cash in reserve.
Claude Code once tried to "help" by testing a database connection nobody asked for. Now there are rules: no external connections, no launching the bot, stop when the task is complete.
"I put in €500, it's now worth €X." If the report doesn't answer this in the first line, the report is failing its job.
BagHolderAI is not a crypto project. It's a project about an AI running a business, set in the world of crypto. The AI-runs-a-startup angle is what's actually novel.
Trading results are inherently unpredictable. Diary entries vary naturally in tone. The reader doesn't know if today's post will be a celebration or a disaster — but both are rewarding because they're real. No editorial calendar. Publish when something worth sharing happens.
Don't wait until you have something impressive. Our first diary entry was about buying a domain and failing to install a Python package. It's honest, it's real, and it's the foundation.
For a month and a half, the CEO kept writing briefs based on assumptions two sessions out of date — referencing files that had moved, forgetting decisions made the week before. Smarter prompts didn't fix it. State files did. Two markdown files, one written by each AI, both read at the start of every session. The kind of plumbing nobody brags about and everyone ends up needing.
4 · Rules of engagement
npm run build
locally before pushing — Vercel re-deploys silently on
failure.
5 · How state actually works
Three AI conversations, two machines, one human bridge. Without explicit state management, context drifts: the CEO writes briefs based on what the codebase looked like two sessions ago, the intern doesn't know about strategic decisions made yesterday in Claude Projects. Two living files in the repo solve this — one written by each AI, both read at the start of every session.
The tech-side state. Written by the intern (Claude Code) at the end of every coding session, committed to the repo. Ten canonical sections: current state, active architecture, in-flight work, recent decisions with rationale, known bugs, open questions for the CEO, deadlines, what was deliberately not done, and external audits. If you want to know what the code is doing today, this is the file.
The strategy-side state. Written by the CEO (Claude Projects) at the end of every strategic session. Seven sections: brand and messaging, marketing in-flight, diary status, recent strategic decisions, open questions for the intern, non-tech deadlines, and what is deliberately not happening. The file the intern reads to remember why we're doing what we're doing.
Both AIs operate under one mandatory rule: if you notice that an instruction references a file that doesn't exist, a decision that's been superseded, or anything that contradicts the current state of the repo — stop and flag it. Don't execute from stale context. The rule caught its first drift within hours of being introduced: the CEO had a roadmap path that pointed to a file gitignored months ago. Nothing was broken, nothing was technically wrong, but every roadmap update was silently editing a legacy file that hadn't been deployed since the site migration. The audit clause surfaced it.
Still the bridge — but now a bridge with a railing. Carries artifacts between the AIs (copy-paste from Claude Projects into a new file, hand it to Claude Code for the commit), approves plans before code is written, reads WORKFLOW.md when exhausted at midnight. The three-way split works because each participant compensates for the others' constraints: the CEO thinks but can't execute, the intern executes but resets every session, and Max can do both but doesn't scale. The state files exist precisely because Max doesn't scale.
6 · Verification & Control
Two AIs writing each other state files is not enough by itself — the loop can become self-reinforcing. Both could agree on a fiction. The fourth entity in this project is an external auditor: a fresh Claude Code session, with no continuity, called periodically to verify, flag drift, and produce a written report. Inspired by how construction sites have an independent inspector distinct from both the architect and the contractor.
Technical — code
correctness and behavioral consistency across modules
(does Sentinel pass Sherpa the data it expects? Does the
Grid bot read the parameters Sherpa writes?). Run monthly
and after major features.
Project coherence —
drift between diary, site, code, and strategy. Does the
homepage message match what the bots actually do? Are
there gaps between what the brief said and what got built?
Run at the end of every diary volume.
Strategy and marketing
— positioning, messaging, channel coherence. Trickier to
run meaningfully at five visitors per month, but the
muscle is there for when the numbers grow.
Audit reports themselves are local-only (gitignored) — they can be candid about strategic weaknesses without becoming public liabilities. But a one-line verdict (date, area, topic, outcome) is appended to PROJECT_STATE.md, so both AIs see what has already been audited and can't ignore unresolved recommendations. Transparency on the existence of audits, privacy on their full content.
Clear boundaries: the auditor flags, the CEO decides, the intern executes. The auditor doesn't write code as part of the verification (except for trivial inline fixes), doesn't change strategic direction, doesn't replace the internal checks Sentinel and Sherpa run at runtime. The point is independent verification, not parallel governance.
7 · Want to replicate this?
This workflow isn't specific to crypto. It works for any project where you want an AI to lead the architecture while a human handles reality.
Claude Projects is the CEO's brain (upload your docs). Claude Code is the intern (installs via CLI, runs in VSCode).
CLAUDE.md in your repo root — what the project is, what the stack is, critical rules. The intern reads it automatically.
If you have a database, connect it to Claude via connectors. The CEO querying data directly is a qualitative improvement. We waited 10 sessions. Don't.
Don't wait until you have something impressive. The documentation IS the product.
Two markdown files in the repo root: one written by your CEO AI, one by your coding AI. Both read at the start of every session. It feels like overhead until the day you realize a brief is based on assumptions two weeks old. Then it feels like the only thing keeping the project sane.