FastBundle Classic · Internal Talk

Agentic
Development.

How we code with AI agents.

by Mahdi Hosseinzadeh Bahreini · Backend Developer

What you'll leave with

A mental model

What "agentic" really means.

Four levers

Context · Tools · Skills · Models.

Token literacy

What we pay for. And why.

A checklist

Habits we can use tomorrow.

From autocomplete to agent.

⌨️

Autocomplete

Predicts the next few tokens.
You drive.

💬

Chatbot

Answers your question in text.
You ask.

🤖

Agent

Reads, edits, runs, verifies — in a loop.
You delegate.

Open: Three flavors of AI in our editor. They are not the same thing.

Say: Autocomplete is what we've had for years. Copilot's original gray suggestions. The model predicts what you might type. You're still doing all the work.

A chatbot answers questions. You paste code in, it explains it, gives you a snippet, you paste it back. The model never touches your filesystem.

An agent is different. You give it a goal — "fix the failing auth test" — it reads files, runs the test suite, edits source, runs the suite again, commits if you let it. It uses tools in a loop until the goal is met or it gets stuck.

That's the shift. We've gone from "AI that writes text" to "AI that does work." And the moment something starts doing work on your behalf, all sorts of new questions matter — how does it know what to do, what can it touch, how do we keep it on the rails. That's the whole rest of this talk.

Bridge: Here's that loop, visually.

The agentic loop · gather → act → verify → repeat

Open: This single diagram is worth memorizing. Everything else hangs off it.

Say: Three phases. Gather context — the agent reads your files, your CLAUDE.md, the git state, runs greps, looks at test output. Take action — it edits a file, runs a command, creates a branch. Verify results — it runs your tests, re-reads the diff, takes a screenshot if it's UI work, asks itself "did that work?". Then it loops.

Two things to notice. First — the phases blend. The agent doesn't strictly go 1-2-3-1-2-3; it interleaves. Second, and this matters — you are part of this loop. You can hit Escape anytime, redirect, undo. The agent is autonomous but not unsupervised.

When agents fail, they almost always fail at the verify step — they skipped it. So a huge part of being good at this is giving the agent something to verify against: tests, screenshots, a clear definition of done.

Bridge: Let me show you what's inside the agent.

Anatomy of an agent.

Open: Four parts. Memorize the names — I'll use them all day.

Say: The model is the brain. Doesn't touch your computer. Just produces text and decides which tool to call next.

Tools are the hands. Read file, edit file, run bash, fetch URL. Without tools, the model can only talk. With tools, it can act.

Context is the working memory — everything the model can see this turn. We'll spend a whole section on this because it's the single biggest lever.

And the harness is the glue. Claude Code is a harness. Cursor is a harness. They wrap the same underlying Claude model with different tools, different prompts, different UX. That's why the same model feels totally different in different products.

A practical takeaway: when something behaves badly, ask — "is this the model, or the harness?" Usually it's the harness. Meaning it's something we configured, and therefore something we can fix.

Bridge: Why is this all working now, and not five years ago?

Why now?

2026

Reliable tool use. 200K context. Haiku 4.5 cuts subagent cost 3×.
Prompt caching. Plan mode. Checkpoints.

Opus 4.7 Sonnet 4.6 Haiku 4.5 MCP Skills Subagents

Open: Five things came together.

Say: First, tool use got reliable. Earlier models would call the wrong tool, pass garbage arguments, or just refuse. The 4.x family is reliable. You can chain twenty tool calls and it stays on the rails.

Second, big context windows. 200K tokens is roughly 400-500 pages of code. You can hand it a whole module instead of one file at a time.

Third, cost. Haiku 4.5 came out, and suddenly there's a model that's 90% as good as Sonnet at coding for a third of the price. That changes the economics of running subagents and background tasks. We don't have to choose between "use the expensive one" or "do without" anymore.

Fourth, prompt caching — the one most teams under-use. If your CLAUDE.md and tool definitions stay the same across requests, Anthropic caches that prefix. You pay a fraction. We'll come back to this.

Fifth, the harness matured. Plan mode, checkpoints, subagents — these aren't research papers anymore, they're features.

Bridge: So given all that, what do we as developers actually need to be good at?

The rest of the talk

Four pillars
you control.

Context

What the model sees.

Tools

What the model can do.

Skills

What it knows on demand.

Models

Which brain we hire.

Pillar 01 — Context · what fills the window

Open: Pillar one. The most important pillar. If you only remember one thing from today, make it this one.

Say: The context window is the model's RAM. Everything the model can see this turn. Every time it takes a step, it re-reads the entire context.

Look at this diagram. Even before you type anything — the model is already carrying the system prompt, your CLAUDE.md at every level up the directory tree, the first 200 lines of auto-memory, the list of available tools, the descriptions of available skills. That's typically 10–20K tokens before you say hi.

Then you start working. Every file Claude reads — stays. Every bash output — stays. Every error message it tried to parse — stays. A single debugging session can burn 50–100K tokens, and the model is still carrying every wrong turn it took.

And here's the line from the docs I want everyone to internalize — performance degrades as the context fills. The model starts forgetting earlier instructions, making more mistakes, going in circles. It's not a hard cutoff at 200K; quality slides well before then.

Context discipline isn't an optimization. It's the difference between a useful agent and a frustrating one.

Bridge: So how do we control what goes in. Start with the file that loads every session.

Pillar 01 — Context · Live demo

Watch the window fill.

CONTEXT WINDOW 0 / 200,000 0%

Click Next event ▶ to start the session.

Open: Now let's actually watch this happen. This is a simulation of a real debugging session — based on the interactive demo on the Claude Code docs.

Say: I'll click "Next event" and we'll see the window fill, step by step. Notice — before we even type anything, the system prompt, CLAUDE.md, memory, tool defs, skill descriptions — that's already 8–10K tokens of overhead. Every session starts with that.

Then I send my first prompt. Then Claude reads the auth file. And the session file. And runs the tests — that's a 12K-token output. Reads more files. Edits. Runs tests again.

Watch the bar. Within a normal debugging session, we're already at 30, 40, 50 percent. And remember the line — performance degrades as the window fills. By the time we cross that red 80% line, the model is forgetting things you told it at the start.

I'll hit /clear and you'll see — instant reset. That's why this command is the highest-impact habit. Once a task is done, you don't carry its weight.

Bridge: So the file that controls how much overhead we start with — that's CLAUDE.md. Let's look at it.

Context grows linearly · every turn keeps the previous ones

Context window grows linearly with each turn

Open: Quick mental model of how this actually works inside the API.

Say: Every turn — every back-and-forth between you and Claude — adds to the window. Previous turns aren't summarized or dropped, they're preserved completely. So the bar I just showed you in the demo isn't a metaphor — that's literally what the API holds in memory.

There's a term Anthropic uses for what happens when this window fills up — context rot. Even before you hit the hard limit, recall degrades. The model starts forgetting things from earlier. Long-context benchmarks like MRCR and GraphWalks measure exactly this — and they show that what's in the context matters more than how big the window technically is.

The practical takeaway — managing what's in context isn't just about staying under a number. It's about keeping signal high. A focused 50K-token conversation will outperform a noisy 180K-token one every time.

Bridge: Now — what about thinking tokens? The newer models do extended reasoning. Where does that fit?

Extended thinking · stripped from the next turn automatically

Extended thinking tokens are stripped from subsequent turns

Open: Extended thinking — when the model reasons internally before answering.

Say: Sonnet 4.5, Opus 4.6, and newer all use extended thinking by default. The model writes out its reasoning in a hidden block, then produces the visible answer. Those thinking tokens can be substantial — tens of thousands of tokens for a hard problem.

Here's the nice part — and this is something a lot of people don't know — the API automatically strips those thinking blocks from the next turn's input. You pay for them once, when they're generated. Subsequent turns don't carry them. So you can have ten turns of deep reasoning without your context window collapsing.

The one gotcha — during a tool use cycle, you must pass the thinking blocks back with the tool result. The model uses cryptographic signatures to verify they're unmodified. If you strip them mid-cycle, the API errors. But after the cycle closes, they drop out automatically.

For us, this is mostly invisible. Claude Code handles it. The point is — extended thinking isn't free, but it's not the runaway cost it might look like.

Bridge: OK back to the practical lever — CLAUDE.md.

Pillar 01 — Context

`CLAUDE.md` — under 200 lines.

Keep

Commands Claude can't guess
How to run a single test
Code-style rules that differ from defaults
Real gotchas (ms vs seconds, etc.)
Branch & PR conventions

Cut

Anything Claude can read in the code
Standard language conventions
File-by-file descriptions
Long API docs (link, don't paste)
"Write clean code"

The test: "if I delete this line, would Claude make a mistake?" If no — delete it.

Open: CLAUDE.md. The one file in every session whether you want it or not.

Say: Because it's loaded every time, every line you put in here pays rent forever. So we have to be ruthless about what goes in.

On the left — things to keep. Stuff the model genuinely cannot figure out. Our custom build commands. How to run a single test. Our branch naming. Real gotchas like "this service uses millisecond timestamps, the rest use seconds."

On the right — things to cut. If Claude can figure it out by reading the code, don't paste it. Don't tell Claude "we use TypeScript" — it can see the .ts files. Don't paste the GraphQL schema — Claude can read schema.graphql. Don't say "write clean code" — that's noise.

The test in the middle is from the docs. For each line, ask — "if I delete this, would Claude make a mistake?" If the answer is no, delete it.

Here's the counter-intuitive part — if your CLAUDE.md gets too long, Claude starts ignoring it. Important rules get lost in noise. A long CLAUDE.md isn't safer — it's worse. Target under 200 lines. Treat it like code. Review it. Prune it.

Bridge: Even with a perfect CLAUDE.md, sessions get long. Here's how to keep it clean.

Sessions are reversible · resume vs fork

Open: Six commands. Memorize these.

Say: /clear is the workhorse. Every time you switch tasks — finished a bug, moving to a feature — clear. Don't carry irrelevant history. This single habit has the biggest impact on quality.

/compact tells Claude to summarize the conversation and continue. Useful when you're deep in a task and don't want to start over but the context is heavy. Pass a focus argument — "focus on the API changes I made" — so the right things survive.

/rewind and double-Escape. Claude snapshots files before every edit. If you went down a bad path, you can rewind to a checkpoint. This is huge — it means you can let Claude try risky things, because undo is one keystroke away.

Plan mode — Shift-Tab. Claude can only read, not write. Use it to explore before you commit to an approach. Slower but prevents you from burning tokens implementing the wrong thing.

Subagents — we'll come back to these. They're the secret weapon for context management because their reads don't pollute your main window.

And /context shows you what's eating your window right now. If you've never run it, try it after this talk. You'll be surprised.

Rule of thumb — if you've corrected Claude twice on the same thing, the context is polluted with failed attempts. Stop fixing in flight. /clear and start fresh with a better prompt.

Bridge: That's pillar one. Pillar two — tools.

Pillar 02 — Tools

The model's hands.

📁

FILE OPS

🔍

⚡

EXECUTION

🌐

WEB

🧠

CODE INTEL

Every tool call returns a result. The result becomes context. The context informs the next tool call.
That's the loop.

Open: Pillar two. Tools. The thing that turns a chatbot into an agent.

Say: Five categories of built-in tools. File ops to read and write files. Search to find things — glob, grep. Execution to actually run code — bash, run your tests, hit your endpoints. Web to look stuff up. And code intelligence — that one requires a plugin, but it's worth it for typed languages: instead of grepping for a function, Claude can do real go-to-definition.

Plus a few orchestration tools — spawning subagents, asking you a question, scheduling itself to wake up later.

Key intuition — every tool call produces a result, and that result goes back into the context. Which the next tool call reads. Which produces a new result. That's the loop. Tools are how the loop touches the real world.

Practical advice — when you ask Claude to do something, think about which tools it'll have to use to verify success. If the answer is "none, it'll just claim it's done" — that's where you're going to get burned. Give it tests, give it a script, give it something to actually run.

Bridge: Built-in tools are great. But your work also lives in Jira, Linear, Sentry, Figma. That's where MCP comes in.

Pillar 02 — Tools · MCP

Reach into the world.

MCP = open protocol. But: CLI beats MCP when both exist (gh, sentry-cli, aws).

Open: MCP. Where the agent reaches out into your actual stack.

Say: MCP is an open protocol Anthropic launched a year or so ago. The idea is simple — instead of every AI tool writing its own Jira integration, its own Figma integration, we standardize how integrations talk to the model. Now Claude Code, Cursor, and others share connectors.

Where MCP shines — Linear or Jira so the agent reads ticket details directly. Figma so it can pull a design. Sentry so it can read the actual stack trace. Your database for read-only investigation. Shopify Admin if we want it to inspect store data during dev.

But — and this is the part most teams miss — for anything that has a good CLI, the CLI is better than MCP. The gh command beats a GitHub MCP server. sentry-cli beats a Sentry MCP server. Why — because MCP tools have schemas that cost context. CLIs don't; they're just shell commands, and Claude already knows how to read --help.

Anthropic made tool schemas deferred. By default only tool names load. The full schema loads when Claude actually calls the tool. Even so, every MCP server pays some context tax. Run /mcp occasionally and turn off the ones you're not using.

Bridge: Pillar three. The piece most teams haven't discovered yet.

Pillar 03 — Skills

Knowledge
on demand.

Pay context only for skills you actually use. Progressive disclosure.

Open: Skills. The newest of the four pillars, and the one I think will change how we work the most.

Say: A skill is a folder with a SKILL.md in it. You put it under .claude/skills in your repo, or ~/.claude/skills for personal ones. The SKILL.md has YAML frontmatter — name, description — and then markdown content telling Claude how to do something.

Here's the key idea — progressive disclosure. The description always loads, so Claude knows the skill exists and roughly what it's for. But the actual body of the skill only loads when the skill is invoked. So you can have a hundred skills installed and pay almost no context cost for the ones you're not using right now.

Two ways to invoke. Manual — you type slash and the skill name. Or automatic — Claude reads the description and decides "this looks right, let me load it." You control which mode by setting disable-model-invocation in the frontmatter.

The headline win — CLAUDE.md content costs context every session forever. Skill content costs context only when actually used. So when you find a section of CLAUDE.md that's only relevant sometimes — migrations, deployments, a specific framework — move it to a skill.

Bridge: Let me make this concrete with what skills could look like for our team.

Pillar 03 — Skills · Examples

Skills we could ship.

/bundle-conventions

Discounts & bundles

Functions patterns, our wrappers, cart-transform gotchas.

/review-shopify-pr

PR checklist

GraphQL deprecations, webhook idempotency, GDPR, billing.

/deploy-staging

Side-effect workflow

disable-model-invocation — manual only.

/repro-issue

From ticket to failing test

Pulls ClickUp + Sentry, scaffolds repro, writes the test first.

Commit to .claude/skills/ — whole team picks them up.

Open: Let me ground this in actual things we could build, today.

Say: First — bundle-conventions. Anyone who's worked on the discounts side knows there are subtle traps: when to use cart-transform vs the discount API, our internal helpers that wrap Shopify Functions, gotchas around merchant-defined input. Encoding all that into a skill means the next person who touches that code — or Claude doing the touching — doesn't have to rediscover it.

Second — review-shopify-pr. A slash command that runs through the things we always check: deprecated GraphQL fields, webhook idempotency, do we have the right GDPR webhooks wired, billing edge cases. Outputs a comment we can paste into the PR.

Third — deploy-staging. This one I'd put disable-model-invocation true, so Claude never deploys staging on its own. Manual only. But when I want it, /deploy-staging knows our exact steps.

Fourth — repro-issue. Pull ticket details from ClickUp, fetch the matching Sentry issue, scaffold a local environment, and — most importantly — write a failing test that reproduces the bug before we touch anything.

Team multiplier — these go in .claude/skills in our repo, we commit them, and they ship with the codebase. Whoever clones, whoever rotates onto the team, immediately has them. They compound the way internal docs never quite do.

Bridge: Pillar four. Models — and the money conversation.

Pillar 04 — Models

Three brains. Pick one.

Opus 4.7

Most capable

Architecture
Long-horizon refactors
When Sonnet is stuck

Sonnet 4.6

The workhorse

Default for coding
80% of our work
Strong + reasonable

Haiku 4.5

~⅓ cost · 2× speed

Subagents
Batch jobs
Verbose, simple work

Default Sonnet. Escalate Opus. Delegate Haiku.

Open: Three models. Not interchangeable.

Say: Opus 4.7 is the smartest. Use it for architecture decisions, complex refactors, things where the model needs to hold a lot of state and reason carefully. Most expensive, and slow. Don't use it for everyday work.

Sonnet 4.6 is the workhorse. What /model defaults to. Where 80% of our work should happen. Good at coding — really good — and the price is reasonable.

Haiku 4.5 is the one that changed the game. About 90% as good as Sonnet at coding, costs roughly a third, twice as fast. For anything high-volume or relatively simple — bulk file edits, running a subagent to do research, batch processing — Haiku is your friend.

The rule — default to Sonnet. Escalate to Opus only when Sonnet is genuinely stuck. Delegate to Haiku for anything verbose or repetitive — especially subagents.

Switch with /model mid-session. Set per-subagent in the subagent's YAML. So your main loop on Sonnet, your subagents on Haiku — huge cost saving when a subagent is reading lots of files.

Bridge: Speaking of cost — let's open the bill.

SWE-bench Verified · coding benchmark, real repos

Model benchmark comparison: Opus, Sonnet, Haiku

The money

We pay for tokens.

$13per developer
per active day

$150–250per developer / month
Anthropic enterprise avg

Context is re-read every turn. 100K context × 20 turns = 2M input tokens.
Context discipline = cost discipline.

Open: Let's open the bill. What are we paying for?

Say: Tokens. Three flavors. Input tokens are everything the model reads — system prompt, CLAUDE.md, the whole conversation, every file read. Output tokens are what the model writes back. Thinking tokens — extended reasoning the newer models do internally before answering — billed as output.

Here's the part that took me a while to internalize — the entire context window gets re-read on every turn. So if you have 100K tokens of context and you do 20 turns of conversation, you've paid for 2 million input tokens, even though the actual conversation was much shorter. This is why context discipline is the same thing as cost discipline. Trimming your CLAUDE.md isn't just a quality move — it's a budget move.

Anthropic's published average across enterprise deployments — about $13 per developer per active day. $150 to $250 per developer per month. 90% of users stay under $30 an active day. That's where we should be.

And there's a free win — prompt caching. Stable prefixes like your system prompt, CLAUDE.md, tool definitions — Anthropic caches them. You pay full price on the first request, a fraction on subsequent ones within a 5-minute window. Already on by default. We're already getting it. But it explains why /clearing and restarting too often can actually be more expensive than continuing — the cache invalidates.

Bridge: The question everyone's waiting for. How do we cut this?

The money · Real prices

Per million tokens.

Model	Input	Output	Cache read
Opus 4.7	$5.00	$25.00	$0.50
Sonnet 4.6	$3.00	$15.00	$0.30
Haiku 4.5	$1.00	$5.00	$0.10

Output costs 5× input. Cache reads cost 10% of input.
A subagent on Haiku is ~25× cheaper than the same work on Opus.

platform.claude.com/docs/en/about-claude/pricing

Open: Real prices, today. These are public.

Say: Three things to notice in this table. First — output costs five times input across the board. So if you can get the same task done with less back-and-forth from the model, that's where the savings are.

Second — the cache-read column. Ten percent of input price. That's the prompt-caching discount I keep mentioning. Cached tokens are nearly free.

Third — look at the spread between rows. Haiku input is one dollar per million tokens. Opus output is twenty-five. That's a 25× difference. If you put your subagents on Haiku and your main loop on Sonnet, you're not just saving a little — you're operating in a different cost regime entirely.

Practical rule — every time you spawn a subagent or batch job, ask "could this be Haiku?" Almost always, yes.

Bridge: Now the free win I keep teasing — prompt caching.

Prompt caching · stable prefix = 90% cheaper

Prompt caching with mixed 5-minute and 1-hour TTLs

1.25×

5-MIN CACHE WRITE

2×

1-HOUR CACHE WRITE

0.1×

CACHE READ — 90% OFF

Open: Prompt caching. The single feature that probably saves us the most money — and we don't have to do anything to get it.

Say: Here's the mechanism. When you send a request, Anthropic looks at the front of your prompt — the stable prefix, things like your system prompt, CLAUDE.md, tool definitions. If they've seen this exact prefix recently, they read it from cache instead of reprocessing.

The numbers — writing to cache costs about 1.25× normal price for a 5-minute TTL, or 2× for a 1-hour TTL. Reading from cache costs 0.1× — ten percent of input. So even one cache hit pays back the write premium. Two hits and you're already saving real money.

In Claude Code, this is already on. Every conversation in a session benefits. But — and this is the thing — every time you /clear and immediately restart, you invalidate the cache. So /clear is great for quality, but back-to-back /clears within a few minutes is more expensive than continuing. Use /clear when switching tasks, not as a nervous tic.

For the Agent SDK or the API directly — if you're building anything custom — turning on prompt caching with stable system prompts is the single highest-leverage optimization.

Bridge: OK. Now let's talk about the habits we control.

Cut the bill — Discipline

Free wins.
No setup.

/clear between unrelated tasks
Specific prompts, not vague ones
Plan mode for non-trivial work

Course-correct early (Esc)
Prune CLAUDE.md
Lower thinking budget for simple tasks

Open: Two halves. First — discipline. Things any of us can do right now without setup.

Say: /clear between tasks. I'll keep repeating this because it's the highest-impact habit. Finish something — clear. Don't bring the auth bug's context into the new feature work.

Write specific prompts. "Improve the auth module" causes Claude to read fifteen files looking for things to improve. "Add input validation to the login function in auth.ts" reads one. Same model, same agent — one is ten times more expensive.

Plan mode for anything non-trivial. Read-only exploration. You review the plan, then execute. Prevents the worst failure mode — implementing the wrong thing and rewinding through it.

Course-correct early. The moment you see Claude going the wrong direction, Escape. Don't let it grind through ten more tool calls. Every tool call result adds to context. Stop early, stop the bleeding.

Prune CLAUDE.md. We covered this. Treat it like code.

Lower thinking budget for simple stuff. /effort low or set MAX_THINKING_TOKENS smaller when you don't need deep reasoning. Extended thinking is brilliant for hard problems, overkill for "rename this variable."

Bridge: That's the discipline half. The architectural half is bigger leverage.

Cut the bill — Architecture

Setup once.
Pay back forever.

Move CLAUDE.md content → skills
Subagents for verbose research
CLI over MCP when both exist

Code-intelligence plugins
Hooks to preprocess data
Haiku for subagents

Do expensive work where the result doesn't have to live forever.

Open: Architectural half. Take some setup, but pay back across every session forever.

Say: Move CLAUDE.md content into skills. Highest-leverage change we can make as a team. If a workflow is only relevant sometimes, it doesn't belong in CLAUDE.md. Make it a skill.

Subagents for verbose work. When Claude needs to read a hundred files to understand the auth system, that's a hundred files in your main context. Or — you say "use a subagent to investigate the auth system" — the subagent reads them in its own fresh context and returns a one-paragraph summary. Same investigation, fraction of the context cost. Single biggest architectural lever.

CLI over MCP — covered. Make it a default choice when you have the option.

Code intelligence plugins. For TypeScript, Python, Go — install them. One go-to-definition replaces a grep plus reading five candidate files.

Hooks. Power-user territory but worth knowing. Claude Code lets you run a shell command before or after any tool call. Classic example — before Claude reads test output, pipe it through grep to keep only the failures. Ten thousand lines becomes fifty.

And — model selection. Subagents on Haiku, main loop on Sonnet, Opus only when stuck. Covered.

The pattern that ties all of these — do the expensive work somewhere the result doesn't have to live in main context forever.

Bridge: Let's land this with a checklist we can actually adopt.

The takeaway

Habits.

Per task

Be specific
Plan mode if scope unclear
Give it something to verify
Course-correct early
/clear when switching

Per project

Lean CLAUDE.md (<200 lines)
Skills for repeated workflows
Hooks for guarantees
Right model for the job
Audit MCP with /mcp

"Pay attention to what works.
When Claude produces great output, notice what you did.
When Claude struggles, ask why."

— CLAUDE CODE BEST PRACTICES

Questions?

Mahdi · Backend · FastBundle Classic

📖 code.claude.com/docs/en/best-practices
🔁 code.claude.com/docs/en/how-claude-code-works
🪟 code.claude.com/docs/en/context-window (interactive!)
🧠 code.claude.com/docs/en/skills
🔌 code.claude.com/docs/en/mcp
👥 code.claude.com/docs/en/sub-agents
💸 code.claude.com/docs/en/costs

Open: All the source material for this talk is on the official docs.

Say: If you want to go deeper on any one pillar, here are the exact pages. The context-window page is interactive — it simulates a session filling up and you can scrub through it. Highly recommend doing that once to build intuition for what's eating your tokens.

That's everything. I'd love to hear what you're running into. What's working, what's not, what we should standardize on as a team.

Thank you.

Q&A prompts if the room is quiet:

What are people actually putting in their CLAUDE.md today?
Anyone using subagents already? What for?
Should we ship a starter skills folder in our main repos?
What MCP servers do we want connected?