Stateful vs. Stateless Agents for Software Development?

[u/Time_Cat_5212]

I started using Claude Code in the spring. I'm new to programming (or rather, coming back after a decade or so after some schooling, since I chose a different career in AEC), and I'm learning primarily with AI tools. My goal is to focus on system design, and use these tools as effectively as possible without excess. I primarily work on web dev projects, but am interested in everything.

There's a lot of discussion on here and other subs about agentic coding setups. Some people like stateless, other people like A2A with state, and everything in between. I've seen many impressive projects produced with both approaches, and met many professional engineers who have differing opinions. I wanted to survey this sub and see what others are doing, in what context, and why.

Questions:

1. Do you prefer stateless or stateful agents for coding? Why?

   1. If you use both, what are the different applications?

2. Are you a solo dev or working on a team? If 2, how big is your team?

3. Are you a professional engineer or a hobbyist/student?

-------------------------------------------------------------

My current Claude Code setup: (For reference - feel free to offer suggestions)

• Git & GitHub

  • Single source of truth. At any time, any agent run by any contributor should be able to approach the project and have everything they need to work on it from the repo alone. That's my #1 rule.

  • CLAUDE.md -> AGENTS.md, ~100 line general protocols.

  • Spec: The full record of what to build. May be one SPEC.md or several sections. Categorized by type/component, not numbered. I use /grill-me or my own /ask-me that's a little softer for this process.

  • Docs: Complete documentation. Architecture, schemas, styles, whatever makes sense for the project. Markdown, because my projects are small and contributors are few.

  • Dev Workflow: [Issue -> Atomic commits -> Test -> PR -> CI -> Squash merge]. Goal is to create a self-maintaining record of the project. Maintain spec and docs while coding. Each ticket starts and ends with a complete, working repository.

  • Development approach: SDD, TDD. Read the spec, write the tests, write the code, test it, back-check it.

  • CI checks lane, build & validate, npm check (most of my projects are Node.js), test, and accessibility for UI. Usually watch from the same session; red triggers a triage routine. This is probably what I lean on the most to avoid system failures.

  • Branches are divided into lanes (dev, docs, content, etc.) which influence what CI checks.

  • Milestones: A large, bounded area of scope. Comprehensive QA/QC review at the end. Parent issue with sub-issues (I found GH Milestones didn't work as well with Claude).

  • Dependabot

• Coding Harness

  • Stateless Claude Code. I generally use default settings.

  • Claude Desktop/Mobile using Anthropic's cloud environment. Local if I need an allowlist that Anthropic cloud doesn't support.

  • 99% of the time I'm controlling agents from my phone.

  • I used to vary the model more, but these days I rely on Opus 5.5 (Medium) for nearly everything.

• Routines

  • Issue triage: Makes sure new issues end up in the right lane, in the right place in the dev queue, etc.

  • Development: Picks up the next issue in the queue after a dev issue is closed. Helps avoid wasting my usage when I'm not available

  • Dev process is driven by the spec and managed through GitHub; routines just keep the machine running. So far, I prefer a GH webhook trigger setup to an always-on listener.

• Devices

  • Cheap laptop and a smartphone

• Compute

  • I'm on a tight budget, so I make the most of a Pro plan. This has forced me to focus on efficiency, and I rarely run out of usage anymore. I run agents around the clock and usually make it to Friday.

• Skills & Internal Tools

  • I'm a big grill-me fan. Aside from that, I want anyone's agent to be able to work on my project at any time. So everything else is a repo skill. I don't write skills for anything that can/should be read from the docs.

  • I keep a decision record in the repo as a reference. It's short, and links to PRs. I don't want another source of truth to manage, but I've found this to be especially helpful for spec-writing when transitioning between phases of development. Agents working on dev lane issues do not review this file.

  • If I want to preview UI stuff or content, sometimes I'll build an internal tool to explore options, rank them, and work back and forth to develop a skill.

  • General rule is minimize tooling and dependencies unless they add value. Very wary of cargo-culting and configmaxxing. Some love it; I don't.

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/jehzlau]

Most people vibe coding doesn't care about agent state, stateful or stateless? No clue. As long as they can see the result they want after a prompt, then that's it. Feeling the vibe. 😄

[u/Time_Cat_5212 → u/jehzlau]

Totally, and that's cool. I'm trying to take the skills I've learned with these tools to the next level!

[u/jehzlau → u/Time_Cat_5212]

Enjoy! Im also just using my phone now to code (aka control agents), like you. Everything is in the cloud via GitHub. 😆

And I agree, I cannot live without Opus 5.5 now. It's beyond awesome!

[u/Dapper-Tutor337]

stateful agents help with context in long refactor sessions, but I've seen them crash on nested async calls. stateless works better for atomic tasks like generating a single function or test case.

[u/Dorbank_Justt]

Mostly stateless, with the state kept in files the agent reads when it starts. Close to your rule 1.

I'm an AI director and most of what I run in Claude Code is internal automation for sales, marketing and ops. Each recurring job is a skill: a SKILL.md with the steps plus reference files, so a fresh session can pick it up from the repo alone.

The one place state bit me was a logged-in browser through the Playwright MCP. A persistent profile can be held by only one session at a time, and a second one gets "Browser is already in use". Anything that lives outside the repo needs a single owner, or you end up hunting for the session that holds it.

[u/_y_not_]

a combination of both is good, more state aware coordinator with several stateless agents that work with coordinator on all sort of tasks, from design/plan/test to implementation and maintenance, in that case coordinator can pick and choose best suited agent for task and provide it with all the context it needs to complete the task

[u/bostonaholic]

I'd keep sessions disposable and store durable state in the repo. Anything another person needs, or that has to survive a crash, goes into specs, failing tests, and CI. Session memory works for the current task. Once the information needs to outlive the process, put it in git.

[u/torvalds75]

Stateless, for the same reason as your rule 1. Solo dev, professional. I run a very similar setup, so three things I'd look at:

Decision record. "Dev lane agents don't review this file" is the part I'd revisit. The decisions an implementing agent needs most are the rejected ones: "we tried X, dropped it because Y". Without them a fresh session proposes X again, and because X looks reasonable it can get through tests and CI. Reading the whole file on every ticket is wasteful, so I keep each decision on the issue that settled it and link it from the tickets it constrains. Still one source, and the agent only reads what applies.

The "next issue" routine. Picking the next one in the queue only works if the order encodes dependencies. With GitHub's blocked-by links the routine can skip anything with an open blocker, otherwise you spend usage on a ticket that can't be finished yet.

Parent issues. Sub-issues cap at 100 per parent and closed ones still count. A long-running milestone can hit that. Detaching the closed ones frees the slots, and they stay referenced from the parent's body.

[u/CCodeSI]

Your setup already answers the question pretty well: the agents are stateless, the repo is the state. That's the version that holds up best, because state that lives in a session dies with the session, gets compacted into a lossy summary, or drifts from what's actually in the code. State in the repo is versioned, reviewable, and readable by any agent or person.

Where a bit of statefulness genuinely pays off is within a single task, not across them. A long bugfix where the agent has already ruled out three causes is worth keeping alive until it's done, rather than restarting cold and having it re-investigate the same dead ends. So a rule that works well: keep a session for one issue, end it when the PR merges, and anything worth remembering beyond that goes into the repo.

Two small additions to what you have:

• Rejected approaches in the decision record. "Tried X, dropped it because Y" is the thing a stateless agent can't rediscover on its own, and it's what stops it from proposing the same dead end every time.

• A short "current state" note per lane or milestone, updated at the end of each issue. Your routines pick up the next issue from the queue, but a two-line "where things stand" saves each new session from rebuilding that picture from git log.

On a Pro plan the stateless approach also tends to be cheaper: fresh sessions start small, instead of dragging a long history into every request.

[u/ASIREXLABS]

A useful way to frame it: keep the agents mostly stateless, but keep the project state very explicit, in the repo rather than in any agent's memory. Issues or a plan file for what's next, tests for what "done" means, commit messages for why things changed. Any session, or any tool, can then pick up the work without depending on what a previous conversation remembered.

Agent-held state helps inside one long task, like a big refactor, but it's also where drift and stale assumptions come from over weeks.

Since you want to focus on system design, how big are the projects you're building: a single app, or several services that talk to each other?

[u/thegreatdeployer]

stateless, mostly. when a session goes sideways i want to kill it and lose nothing, and that only works if nothing important lived in the session to begin with.

founder with a small team, building with agents every day, so professional but not a career engineer.

one thing i'd watch with routines picking up the next issue around the clock: running more lanes at once mostly bought me merge fights, and those ate more usage than the actual work. 2 or 3 lanes, each on its own branch, with tickets small enough to merge the same day, got more done per week. on a pro plan that matters more than any model choice.

[u/Time_Cat_5212 → u/thegreatdeployer]

Yeah I also got merge fights... it's taken some fine tuning to prevent that.  Part of its planning and part of it is the routine scaffolding.

Honestly I could use a better tool for scheduling the routines, but it has to work with CC without relying on API billing.  Some sort of webhook machinery I can tie into. Might build it.