Daisy' (Anthropic Claude Code engineer) workflow
· back
On <2026-08-23 Sun> I read in stumbled on this post - Anthropic: Please Have Daisy the CC Engineer Do a Video! : r/ClaudeAI.
In this week's newsletter, Anthropic included this:
"My daily driver currently looks like: two lead agents that keep each other accountable and restart the other if either fails. These delegate to tech lead or PM agents for the 8-10 projects I'm running at any one time, and each project has 5-10 IC [individual contributor] agents, generalists or specialists depending on the problem. Across all of these I'm still only doing 30-50 prompts per day, and my IC agents typically work autonomously for 2-3 days. About 60% of my interaction is with the leads, 35% with a project lead, and 5% is when something has gone off the rails. All of these agents communicate directly with the SendMessage tool."
– Daisy, Engineer on Claude Code
Turning it into mindmap:
╭─ keep each other accountable
╭─ two lead agents ┼─ restart the other if either fails
│ ╰─ delegate to ┬─ tech lead ── 8-10 projects...
│ ╰─ PM agents
│ ╭─ . ┬─ generalists
« Daisy workflow » ┼─ 8-10 projects ── per project ── 5-10 IC agents ┤ ╰─ specialists
│ ╰─ work autonomously ── for 2-3 days
│ ╭─ 60% with leads
├─ 30-50 prompts per day ┼─ 35% with project lead
│ ╰─ 5% off rails
╰─ agents communicate ── SendMessage tool
My thoughts:
Why two lead agents? Likely they both run "/loop 30m check projects" with offset, so one is checking status while another is ready for communication. This is where "60% with leads" coming from; sometimes they both are checking, and Daisy goes to project leads directly. Those two leads have permanent session names and never closing.
8-10 projects. I also have about the same number of big topics a week, often carried to other weeks. So this sounds like the right amount of parallelism. Also keeping 8-10 projects on track is within cognitive abilities of an average human.
Beyond the basics with Claude Code
Comments lead to this video:
- YT
- Beyond the basics with Claude Code - YouTube
- author
- Daisy Hollman
- date
- <2026-05-22 Fri>
It breaks down to this mindmap:
╭─ Slack
╭─ where work comes from ┼─ CI/CD ── no point to fix CI/CD manually
│ ├─ Dashboards
│ ╰─ Internal Docs
├─ tip ── try doing ALL work from within CC
│ ╭─ code conventions are not in the model
├─ limits ┼─ fine-tuning doesn't work well ── leads to more hallucinations
│ ╰─ in-context learning ── ICL ── general AI wins over specific AIs
│ ╭─ rigid templates
│ ╭─ compensates lack of intelligence ┼─ guardrails
│ │ ├─ "don't let it touch X"
├─ two kinds of tools ┤ ╰─ gets less useful as model improves
│ │ ╭─ more access
│ ╰─ scales with intelligence ┼─ more control
│ ├─ faster feedback loops
│ ╰─ gets more useful as model improves
│ ╭─ context window stayed at 1M max ── models are way better yoy
│ ├─ can't dump the whole X into context ── X ┬─ wiki
├─ context window is a box ┤ ╰─ codebase
│ ├─ example ── try to run npm on Arduino
│ ╰─ don't pay for what you don't use ── [TK: no slop skills]
│ ╭─ cached tokens are cheap ── new are expensive
│ ├─ not an LRU problem
├─ KV cache ┼─ change in early instructions invalidates the cache ┬─ add new tool
│ │ ╰─ change in CLAUDE.md
│ ╰─ put stable stuff at the front ── volatile at the end ── CC teams tries to solve this problem
├─ Large-scale Software Engineering ── main question ── Does it scale?
│ ╭─ when it's the right tool?
│ ├─ CC has a shell ── Skill+CLI has less overhead
│ │ ╭─ name
│ ╭─ MCP ┼─ tools definitions sit in front ┼─ arguments
│ │ │ ╰─ description
« Agentic flow » ┤ │ │ ╭─ puts just name in the system prompt
│ │ ╰─ tool search ┼─ kind-of lazy-loaded
│ │ ╰─ needs to be very specific ── e.g. slack
│ │ ╭─ in-context
│ │ ├─ one-line description always loaded
│ │ ├─ full SKILL.md and assets loaded on-demand
├─ Plugin primitives ┼─ Skills ┤ ╭─ body is pay-per-use ── good
│ │ ╰─ does it scale? ┼─ reliably loading requires a paragraph in description
│ │ ╰─ not possible to lazy-load sub-skills ┬─ no hierarchy yet
│ │ ╰─ what if 100k skills?
│ ├─ Hooks ┬─ runs code on events ── shell scripts
│ │ ╰─ zero-overhead abstraction
│ │ ╭─ out-of-context ── fundamental difference to a skill
│ │ │ ╭─ named role
│ │ ├─ more Claudes ┼─ own system prompt
│ ╰─ Agents ┤ ╰─ own tool set
│ ├─ spawned with a task ┬─ returns result
│ │ ╰─ its transcript doesn't come back
│ ╰─ description still in-context ── what if 100k agents?
│ ╭─ loads fully unconditionally ┬─ doesn't scale
│ ╭─ CLAUDE.md ┤ ╰─ every plugin adds it
├─ Doesn't scale ┤ ╰─ better inject via SessionStart hook
│ │ ╭─ low-quality ── low-cost ── useful, different contract
│ ╰─ Memory ┼─ model-curated, not human-curated
│ ╰─ plugins are human-authored, human-reviewed
│ ╭─ worktrees ┬─ one repo ── N claudes each owns its branch
│ │ ╰─ better make it long-lived ── less overhead ── [TK: try kunchenguid/treehouse?]
├─ Multi-clauding ┼─ asynchrony ┬─ walk away, let it do the work
│ │ ╰─ /loop 10m
│ ├─ parallelism ── multiple of asynchrony
│ ╰─ lot's of context switching
╰─ Agent-teams ┬─ teammates ── long-lived ── unlike agents
╰─ SendMessage tool ── Claude's talking to each other
Follow-up questions:
- Do I need claude-mem?