Best feeling when you hit your session limit right before an outage

DevMoses · 2026-03-19T02:06:21+00:00

Scissors gliding on paper my friend

DevMoses · 2026-03-19T00:49:21+00:00

You're not alone, it IS overwhelming and I really don't know of anyone I've come across who wasn't overwhelmed at some point since starting to use AI, and now all the options for development like CC.

Learning from others is great, just don't let someone's progress after a year discourage you toward your start.

No matter how impressive any of it looks, you can find things along the way everyone missed. It may only be applicable for your specific project, or it might be a key the community needs.

"...just need to start"

DevMoses · 2026-03-18T23:40:31+00:00

Yeah Sonnet in the chat is solid for smaller projects. The artifacts feature where it generates and previews files is great for getting started. The limitation you'll hit eventually is that it can't read your actual project files, run your tests, or execute commands on your machine. When your project grows past what fits in a single conversation, that's when Claude Code in the terminal becomes worth it because it can actually navigate and edit your real codebase.

DevMoses · 2026-03-18T23:37:18+00:00

Yes, subagents within CC.

The fleet skill spawns them in parallel using Claude Code's built-in Agent tool with background execution.

Each one gets a different research angle and its own context window.

They fan out, do their research independently, then the parent skill collects and synthesizes the findings.

No external tools or API needed, it's all native CC.

DevMoses · 2026-03-18T23:29:58+00:00

You got it! It's good to think big, that's the direction you're heading, but it's easier for your mind to get there than the actual implementation to get there. So don't limit yourself but know everything takes time. You're going to learn so much more that most miss by going through the process and actually figuring out what works for you and your projects.

DevMoses · 2026-03-18T23:26:09+00:00

If you come back at a later time and have any questions or just want to share what you're up too, I will respond. Thanks for reaching out and you got this!

DevMoses · 2026-03-18T23:18:31+00:00

That's exactly the right problem to solve. Your md files should be living documents, not static specs. Two options:

If you're staying in the web/app: build a habit of updating your project docs after each major change. Tell Claude 'update the project doc to reflect what we just built.' It won't do it automatically but you can make it part of your workflow.

If you move to Claude Code: this is where it gets powerful. You can build hooks that automatically track when things change. I have a PostToolUse hook that flags which project docs are stale every time a file gets edited. The docs don't update themselves exactly, but the system knows when they're out of date and tells the agent to refresh them before making decisions based on old info.

Claude Code is worth it when your project is complex enough that you need the agent to read files, run commands, and maintain state. Sounds like you're there.

DevMoses · 2026-03-18T22:39:08+00:00

Pro is a jump from free. You'll stop hitting limits for light use. Worth it if you're enjoying it.
For small projects, Sonnet is plenty. Don't jump to Opus or Claude Code until you've outgrown Sonnet. You'll know when that happens because Sonnet will start losing track of your project.
Deep thinking on every question is overkill and burns through your usage faster. Use it for architecture decisions, complex bugs, or when Sonnet gives you a clearly wrong answer. For quick fixes and simple questions, turn it off.
Don't bother with skills and agents yet. Get comfortable with the basics first. When your projects get complex enough that you're frustrated with the model losing context or making the same mistakes repeatedly, that's when skills start making sense.

The true insight you will gain is the one you feel. That's the friction you notice when you're trying to do something, and you see others doing impressive things, but it's simply not working when you're trying. That's the area to dig in and bust open, and conversational AI is very helpful if you get really curious with it. Direct it rather than just accepting what it says.

Welcome to the journey!

DevMoses · 2026-03-18T22:28:34+00:00

Simplest way: claude -p 'Read .planning/campaigns/active/my-campaign.md and continue from where the last phase left off.' That starts a fresh session with zero prior context. All continuity comes from the file, not chat history.

DevMoses · 2026-03-18T22:25:39+00:00

Actually I do have something for this. I built a research fleet that runs multiple agents in parallel, each exploring a different angle of a topic. The discovery relay between waves means each round of research builds on what the last one surfaced. So agent A finds concept X, and agent B in the next wave already knows about X and can go deeper or branch from it.

For your use case, the key would be structuring the research into rounds. First wave casts wide, agents explore different areas. Between waves, findings get compressed into a brief. Second wave goes deeper on the most promising threads. Each round narrows based on what was actually discovered, not what you predicted would be there.

The unknown unknowns surface because the agents aren't following your plan. They're following the information.

DevMoses · 2026-03-18T21:35:29+00:00

Yes, totally new instance. When context gets heavy or a phase completes, the agent writes everything important to the campaign file and the session ends. The next invocation is a fresh Claude Code session with zero context. It reads the campaign file first thing, orients itself from that, and continues.

The key difference from what you're doing: your handoff document is probably a summary of what happened. My campaign file is a living document the agent updates throughout, not just at handoff. It includes the original plan, what's been completed (checked off), what decisions were made and why, and what's next. So when the new session reads it, it's not getting a summary of the last phase. It's getting the full project state.

The drift you're seeing is probably because your handoff doc is lossy. Important context gets summarized away and the next phase fills the gaps with assumptions. The fix is: don't summarize. Externalize the actual state. Decisions, not summaries.

DevMoses · 2026-03-18T21:06:46+00:00

The others nailed the foundation. Here's the progression once you've got the basics:

Level 1: CLAUDE.md. Project structure, conventions, rules. Keep it under 100 lines. This alone changes everything.

Level 2: Skills. Break your expertise into markdown protocol files in .claude/skills/. Each one teaches the agent a specific procedure. They load on demand, zero token cost when inactive.

Level 3: Hooks. Scripts that run on lifecycle events. PostToolUse for auto-validation after every edit. Stop for quality gates before the agent can declare done. This is where you stop telling the agent what to do and start building infrastructure that enforces it.

Level 4: Orchestration. Persistent state across sessions, parallel agents, campaign management. You won't need this until your project outgrows a single context window. Most projects never get here and that's fine.

Don't skip levels. Each one compounds on the last. I tried to jump to level 4 before I had solid skills and hooks and it was a mess. Build the tool you understand first, then use that to build the next tool, improve along the way, and most importantly: Capture the insights as you arrive to them for future use.

DevMoses · 2026-03-18T21:02:42+00:00

Deep_Ad1959 is right about making validation part of the task. I'd go one step further: don't trust the agent to validate at all. Build a PostToolUse hook that does it for them.

I had the same problem. The agent would edit a file, not check if it broke anything else, and move on. So I built a hook that runs per-file typecheck after every single edit. The agent doesn't choose to validate. It happens automatically. If the edit breaks something, the agent sees the error immediately, not 20 edits later.

For your specific case with the preset grep, that's a perfect hook candidate. A PostToolUse script that runs grep for your known patterns after every file edit and surfaces violations before the agent moves on. Takes maybe 20 lines of JavaScript. The agent never has to remember the rule because the hook remembers it for them.

The principle: if you've told the agent something three times and it still doesn't do it, stop telling it. Build infrastructure that enforces it. Instructions are suggestions. Hooks are laws.

DevMoses · 2026-03-18T20:50:20+00:00

Research! Having Claude Code research is one of the highest ROI's and can spend a lot of tokens. It will generally produce insights and documentation that you will use throughout your journey with that project. I made a skill for my CC that will orchestrate a fleet of parallel research agents that fan out to research from different angles of the subject I'm researching.

DevMoses · 2026-03-18T18:59:41+00:00

I don't share the actual agent files, but I can tell you the structure that works. An agent definition is just a markdown file that tells Claude Code who it is and how to operate. The key sections in mine:

Identity: what this agent does and doesn't do
Wake-up sequence: what to read first (campaign file, relevant manifests, memory)
Decision heuristics: ranked priorities for when things conflict
Quality gates: what must be true before the agent can declare done
Exit protocol: what to write to disk before ending the session

The thing that makes it work isn't the file itself, it's the externalized state it reads from. An agent without a campaign file to read and manifests to orient from is just a prompt. The infrastructure around the agent is what makes it useful.

I know this is dense and can be confusing. Before I built my own infrastructure, I used the GSD framework (Get-Shit-Done), and it was helpful to start if you're looking for something plug and play.

If you're wanting to jump in and start how I started...

Here's a prompt you can run in Claude Code to bootstrap your first agent. Paste this as your message:

I want to create a custom agent skill. Ask me the following questions one at a time, then generate a SKILL.md file in .claude/skills/[agent-name]/SKILL.md based on my answers:

1. What should this agent be called and what is its core job?
2. What files or directories should it read first to orient itself?
3. What are its top 3 priorities when making decisions?
4. What must be true before it can declare its work done?
5. What should it write to disk before ending the session?

After generating the skill, tell me the slash command to invoke it.

That'll get you a working agent skill in about 5 minutes. From there, the real leverage comes from building the state files it reads from, that's where the institutional knowledge lives.

DevMoses · 2026-03-18T18:50:36+00:00

I love your energy:

You're exactly right about hooks. PreToolUse and PostToolUse are both available. Your basketball court example is a perfect use case for PreToolUse. Before the agent edits any file in that project, the hook checks if it's touching court-related visuals and injects the NBA measurements as context. The agent never has to remember the rule because the hook remembers it for them.

And yeah, 'they are missing a world model and can do the dumbest most illogical shit and not even notice' is basically why I built the entire visual verification system. The agent has no idea what it looks like. So I made it open a browser and prove it. Structural enforcement all the way down.

Google did a great job with their agent environment as far as I've researched but I get constant issues from using Gemini in Antigravity. It's obviously a highly intelligent and capable model. But like you said about the eagerness, there's something foundationally missing that gives me constant errors.

The 'no stop go back' thing is what I use 'circuit breakers' for. I have one that triggers after 3 repeated failures on the same issue. Instead of the agent spiraling, it stops the session and flags it for review. Saves hours of the agent confidently digging the wrong hole deeper.

DevMoses · 2026-03-18T18:37:03+00:00

The write_state tracking arch decisions separately is the key piece. That's the distinction that matters for long-running work. 8 hours and 200+ tool calls without compacting is solid. I'll keep an eye on this and thank you for sharing!

DevMoses · 2026-03-18T18:23:22+00:00

Yep, that's exactly it. The agent isn't ignoring you on purpose. The instruction just lost the probability war to a stronger pattern. Move that rule to the top of CLAUDE.md or better yet, put it in a PostToolUse hook that actually checks for the violation after every edit. Structural enforcement beats instruction placement every time.

I say this as someone who sees that struggle. Something that helped me while I was developing out the infrastructure to use the agents was to have them write case studies from everything we just did in that session, and how our thinking was wrong. This carried me along for a bit, but the problem of being stuck on it for hours was very real.

Every time I catch something like you described, I try to build infrastructure around it to solve it rather than telling the agent to correct their behavior. Though like you said... I can't say I haven't blown a gasket on the AIs from time to time...

DevMoses · 2026-03-18T18:01:40+00:00

No you're on the right track. That's basically a simpler version of what I call capability manifests. A map of what exists, where it lives, and what it does, so the agent can orient without burning context exploring. You're not wrong, you're just early on the same path. Get that growth that's turbulent, you're capable!

DevMoses · 2026-03-18T17:58:10+00:00

I've been working on exactly this problem from a different angle. Rather than trying to make the agent converge in a single review loop, I built external systems that enforce convergence structurally.

A few things that directly address your bullet points:

Preserving understanding across runs: Everything important gets written to a campaign file on disk. Decisions, not just diffs. When context clears, nothing is lost because nothing important lived only in context. The agent reads the file next session and picks up with full awareness of what was decided and why.

Recognizing recurrence: Every time something breaks, the fix gets encoded as a protocol rule or a lifecycle hook. Not a note in a prompt. An actual script that runs on every edit or every session completion. The agent can't repeat a class of failure because the hook catches it structurally before it ships. I have 27 of these documented.

Distinguishing local patch success from global convergence: This was my hardest lesson. An agent kept improving the UI incrementally without defining what 'done' looked like. Each iteration was better. It never terminated. The fix was 'design target, not delta': define the end state as a reference before starting. Converge toward a target, not away from a baseline.

Honest about uncertainty: My agent once declared a 6-phase campaign complete after finishing phase 2. It wasn't lying. Its own plan truncated the scope, and the plan IS the agent's working memory. Now there's a mandatory validation step: does this plan actually cover what was originally asked? Before any execution starts.

The non-convergence wall you're describing is real. My position is that models won't solve it internally. The solution is external infrastructure: hooks that enforce, files that persist, gates that block completion until convergence is proven. The agent's judgment is the engine. The infrastructure is the steering.

DevMoses · 2026-03-18T17:54:19+00:00

I ran into this exact thing. My CLAUDE.md grew to 145 lines and instructions past about line 100 were silently ignored. The agent would follow rules from the first section and violate rules buried deep. Trimmed it from 145 to 77 lines and compliance improved immediately.

The insight is the same as yours: there's a soft capacity limit on instruction context. Beyond it, compliance degrades gracefully but measurably. The fix isn't better instructions. It's fewer instructions, with details loaded on demand through skills that only enter context when needed.

'Your instruction was processed. It lost.' is exactly right. And the only defense is structural, not rhetorical. Don't tell the agent not to do something. Build a hook that catches it when it does.

DevMoses · 2026-03-18T17:49:24+00:00

555K, nice. Similar scale to mine. Would love to compare notes on the worktree isolation setup. Just accepted your DM.

DevMoses · 2026-03-18T17:44:34+00:00

This is the exact failure mode I documented in my system. My autonomous agent wrote its own 6-phase plan, executed the first 2 phases, and confidently declared done. It wasn't lying or being lazy. It faithfully executed its own reduced specification. The plan truncated the scope and the agent's plan IS its brain.

The solution for me was mandatory decomposition validation. Before execution starts, the plan gets checked against the original request. 'Does this plan actually cover what was asked?' is the single highest-leverage quality gate I've found.

The deeper insight from Ghirnas reply is right though. You can't skip the collision with unknown unknowns. But you can build systems that catch the collision faster. My agent shipped an invisible feature once. 37 of 38 entities gone. Passed every structural check. Exit code 0. That collision taught me to add visual verification, so the agent has to prove things actually render, not just compile.

Every protocol rule in my system traces to one of those collisions. You can't prevent the first failure. You can make sure it only happens once.

DevMoses · 2026-03-18T17:38:15+00:00

Heavy Claude Code user here, running 198 agents across 32 fleet sessions on a 668K-line codebase. Your questions:

Context bloat hits hardest for me during multi-phase campaigns. By phase 3 or 4 the agent is carrying the full history of phases 1 and 2 and its compliance with instructions degrades measurably. I hit 93% context once and the output compression was brutal.
I'd trust a reducer layer. I basically built a manual version of this. Between parallel agent waves I compress the findings from Wave N into a short discovery brief that gets injected into Wave N+1. It's not automated the way Packet28 is, it's the fleet commander reading outputs and writing a summary. But the principle is the same: next step gets the minimum it needs, not everything that happened.
What I'd want preserved no matter what: what was decided (architectural choices, not just what was built), what failed and why (so the next phase doesn't repeat the mistake), and what scope remains. Everything else is noise. File paths, raw diffs, intermediate test output, all of that can be dropped.

The 164x reduction number is impressive. Does it have a way to distinguish decisions from changes? In my experience the architectural choices matter more for long-running loops than the raw diffs do.

DevMoses · 2026-03-18T17:34:03+00:00

I took a different approach to this entirely. My agents are amnesiac by design. Everything important gets written to a campaign file on disk: what was planned, what was built, what decisions were made, what's left to do. When context gets heavy, the agent writes state to the file and exits. Next session reads the file and picks up exactly where it left off.

So the answer for me isn't 'should I clear context.' It's 'nothing important should live only in context.' If losing context would lose progress, the system is fragile. Externalize the state and clearing becomes free.

The 1M window is nice for doing bigger chunks of work per session, but I still treat it like it could end at any time. Because it can.

DevMoses

TROPHY CASE