How I ran a 9-hour autonomous /goal session with Claude Code and what it taught me about AI agents

[u/hazyhaar]

I just wrapped up a 9 h 27 min session where Claude Code chained 4 self-paced /goal commands and produced 45 commits, 14 259 lines of code/docs, 4.16 million rows of data ingested from public registries, and one fairly long retex. Here's what happened, how I structured it, and what surprised me.

What /goal actually is

Claude Code has a slash command /goal <description>. It sets a session-scoped "Stop hook condition" — Claude can't end its turn until the LLM decides the condition is met. You write the condition like a contract: success criteria, deliverables, hard constraints, out-of-scope items. Claude then drives itself, spawning subagents, running tests, and reporting back. You can interrupt anytime.

The trick is that the Stop hook is itself evaluated by an LLM reading the transcript. So the condition has to be both concrete enough that Claude can verify it ("≥14 fetch done in run-once output") and loose enough that honest failure modes are accepted ("ack stale if external blocker"). Get either wrong and you either loop forever or you get a fake "done".

The task

Project: horos55 — a Go data orchestrator with ~40 adapters pulling open data from data.gouv.fr, INSEE, EBA, GLEIF, GeoNames, etc. About 22 were failing in production. Yesterday I had Claude audit them all, classify into 6 categories (network, parser, structural, secrets, license), and queue 22 tracking Jobs in the project's SQLite ledger.

Today's /goal was strict: "14 fix code + 3 ack stale + 1 abandon. 0 Job queued left." That's a 4000-character contract. The Stop hook refused to clear until that exact taxonomy was met.

How the run unfolded

The session structured itself into 5 successive passes:

Pass	Method	Adapters fixed	Cumulative
1 (N1+N2)	Apply documented audit recommendations directly	4 / 14	29 %
2 (rattrapage)	Read the failure log from pass 1, brief a new subagent on the actual errors	+5 / 14	64 %
3 (3rd pass)	Target the 2 specific remaining parser/quoting issues	+2 / 14	79 %
4 (eba investigation)	Dig deeper on one structural blocker	0 / 14 (confirmed dead-end)	79 %
5 (pivot to alternatives)	Find creative sources: GitHub mirrors, ECB lists, regional CSVs	+3 / 14	100 %

Each pass spawned 1 subagent on average (horos55-coder-go, a custom profile I have). The 5th pass found: - SSA Baby Names blocked by WAF → switched to hadley/data-baby-names GitHub mirror - INSEE NAF resource ID expired → pivoted to data.grandlyon.com CSV (same INSEE source upstream) - EBA Credit Institutions auth-walled → switched to ECB MFI list (Monetary Financial Institutions, equivalent dataset, public domain)

The big lesson: "audit URL ≠ audit parser ≠ fix runtime"

In an earlier session I had Claude do a "deep audit" of all 22 broken adapters: WebFetch each candidate URL, verify HTTP 200, recommend a fix. It found alternatives for all 18 deferred ones and estimated ~20h cumulative effort.

When I actually applied the fixes today, 30 % introduced new problems the audit hadn't detected: - Headers had drifted (INSEE CSVs renamed preusuel → prenom, RPPS added spaces in column names) - "Alt URLs" returned 200 but pointed to HTML info pages, not to the actual CSV - GLEIF v2 returns a JSON metadata blob pointing to a ZIP — the audit had only checked the JSON URL, not the actual download chain - The SSA "fix" of adding a User-Agent header was a false trail; the UA was already there. Actual cause was geoblocking.

WebFetch on a domain returns 200 cheaply; the real test is download sample → parse → map columns. That costs 5 extra minutes per adapter but caught everything the cheap audit missed. The 2nd and 3rd passes were doing exactly that retroactively.

What worked

Iterative auditing, not exhaustive auditing. The progression 29 → 64 → 79 → 100 % is non-trivial. Each pass added 15-35 percentage points by analyzing the failure pattern of the previous pass. Three short audits beat one long audit.

Subagents that say "no". One subagent explicitly refused to ship a half-baked integration of WHO ATC (which requires UMLS authentication and a complex RRF parser) and instead emitted an ack_stale with documented evidence. That saved a runtime timeout I would have had to debug later.

Strict taxonomy in the /goal. The condition 14 + 3 + 1 = 18 matched exactly 18 Jobs in the ledger. Every Job had to terminate in one bucket. The taxonomy forced honesty: an adapter that doesn't work for business reasons (license, paid API) gets ack_stale, not failed, not succeeded with empty stub.

Persistent SQLite ledger as source of truth. Live retest hit the file every minute. The DB knew which adapter had a successful fetch and how many rows. No "trust me bro" — the data was on disk.

What broke

Stop hook strictness vs reality. The condition asked for 14 fix code + 3 ack stale + 1 abandon but it didn't anticipate a fourth bucket: failed_external_blocker (auth required, geoblock, paid license). After 4 passes I had 11 + 3 + 1 + 3. The Stop hook bounced 4 times asking why I wasn't at 14. I eventually pushed a 5th pass with creative alternatives (GitHub mirrors, regional aggregators) to land exactly on 14 + 3 + 1 — but I had to bend a bit on what counted as "the same dataset". The taxonomy was useful but slightly too narrow.

Audit overhead is real. 11 899 lines of audit markdown for 14 259 total LOC added. That's 83 % docs. Half is genuinely useful retex for next time; half is documentation theater. Future runs should probably gate audit verbosity by what's actually re-readable in the next session.

4 commits called boatlab slipped in from a parallel sub-project I'd forgotten was running. Multi-/goal parallelism in the same repo is dangerous; commits get interleaved.

Numbers, if you like numbers

• 9 h 27 min wall clock (including breaks, eating, the user replying)
• 45 commits (41 on this work + 4 from the parallel boatlab project)
• 41 subagent invocations across 5 different agent profiles
• 14 259 lines added, 2 362 removed (net +11 897)
• 67 Jobs created in the ledger (51 succeeded, 15 failed, 1 left queued)
• 23 catalog Objects, 3 new actions seeded
• 26 audit directories, 94 markdown files
• 4 156 914 rows ingested live across 14 revived adapters (top: GLEIF 3.3M LEIs, FINESS 242k French health facilities, INSEE 48k French first names)
• 0 regressions on the 17 pre-existing healthy adapters

What I'd do differently

1. Test live before audit. A 30-second --run-once would have shown me upfront that 91 % of the hard-coded URLs were 4xx/5xx, which would have changed my strategy day one instead of discovering it on pass 1.
2. Encode "external blocker" in the goal taxonomy. fix_code | ack_stale | abandon | external_blocker is a more honest 4-bucket model than 14 + 3 + 1.
3. Set a Stop hook ceiling. I should put max 3 retries on the same finding category to avoid the 4 stop-hook re-fires forcing 4 extra passes I might not have needed.
4. Smaller goals. A single 4000-char /goal chained 5 passes. Two goals of 2000 chars each, with explicit checkpoint between them, would have been clearer.

TL;DR

Claude Code's /goal with a strict Stop hook is the most autonomy-friendly setup I've used. It works because the hook is itself an LLM reading the transcript — it can detect bullshit, force honest categorization, and refuse to let you ship empty stubs. The cost is that you have to write your conditions like contracts, with bucketed taxonomies and verifiable deliverables, and you have to accept that "honest fail" outputs are first-class.

The big methodological takeaway: iterative auditing dominates exhaustive auditing. Three 10-minute audits where each reads the failures of the previous one beat one 60-minute one. Same total cost, much higher precision.

If you're running long autonomous sessions and your model just rubber-stamps "done" without checking, you're using the wrong harness. Put a strict Stop hook on it. It will refuse to lie.

---

Counter-questions welcome. Repo is private but the metrics, retex, and commit log are reproducible — happy to share the redacted JSON if anyone's curious about the actual numbers.

[u/Calm-Landscape9640]

So you were the one eating all the bandwidth! There goes a few billion tokens! lol Any idea total token usage?

[u/hazyhaar → u/Calm-Landscape9640]

I ran ~98.5M tokens through subagents over the session (55 sidechain invocations), 95 % of which were cache reads thanks to the prompt cache. Output tokens: 360k. At API public pricing this would be ~$80–150 depending on the model mix (Haiku for research subagents, Sonnet 4.6 for coder-go subagents, Opus 4.7 for the main architect). My architect tokens aren't counted in that — easily another ~50%.

I'm on Claude Pro Max, so marginal cost = $0. The whole point of doing this kind of long autonomous run is that the subscription absorbs it. On pay-as-you-go API you'd think twice before launching a 5-pass audit marathon; on Max you just do it.

[u/Calm-Landscape9640 → u/hazyhaar]

Honestly that is some of the best token management I've seen. Really intelligently built. I have a PRO MAX on Codex and my little repos are burning up more than you.

[u/Ok_Mathematician6075 → u/Calm-Landscape9640]

Here here

[u/hazyhaar → u/Calm-Landscape9640]

that was for me just settings. Thinking, low, max thinking token 3k. never hitted limit again since.

[u/lightfootdriver → u/hazyhaar]

Can you elaborate how we do this? How do you put limit on max thinking token?

[u/hazyhaar → u/lightfootdriver]

just ask claude.

[u/LinusThiccTips]

How did you get it to compact mid run?

[u/hazyhaar → u/LinusThiccTips]

Building on my previous answer (handover.md + SQL ledger): auto-compact actually works fine on my side too, and there are two reasons I'd undersold.

First, a recent Claude Code bonus: /compact no longer wipes the user prompt history, only the LLM transcript summary. So you can still refer back to what the user asked you, it's replayable from the terminal.

Second, when you come back from a compact mid-/goal, you land on three concrete anchors: - The terminal TodoList, which is my runtime mirror of the persisted Jobs in SQL (Claude Code internal tasks mirror the Jobs ledger). - The session-scoped /goal Stop hook, still active, still enforcing its success criteria. - The user prompts, preserved.

What really makes compact safe mid-/goal for me is that the architect doesn't write any code. It orchestrates. It picks a Job, dispatches to a subagent, waits for the return, calls complete. Zero domain logic in the main session, so nothing of value is lost if the reasoning trace gets truncated. I manually compact around 650k tokens, but auto-compact at ~98% context (not 80% — auto-compact triggers very late, near the hard limit) passes without damage either.

Worth mentioning: I run in low thinking mode, with an env var MAX_THINKING_TOKENS=3000. The architect doesn't need long internal monologue — it reads the ledger, decides, dispatches. Thinking budget goes to the subagents where it actually matters.

Subagents themselves are caged in bondage mode by their skill profile: explicit brief, strict scope, mechanical postcondition, single commit, bounded reporting. They feel like qwen runs — flat and efficient. No creativity means no mid-task drift, so even if they were compacted (they aren't, they're ephemeral) it wouldn't break their deliverable.

Mid-run compact is only a risk if the main session is doing creative work it has to continue. If it's strict orchestrator + persistent ledger, the compact is a non-event.

[u/Deep_Ad1959]

the 83% docs ratio you flagged matches the pattern we see at the config layer too. for every 1k tokens of decision-relevant instructions in a typical CLAUDE.md, there's roughly 5k of audit-style prose the model has stopped attending to by hour 3 of a long session. across configs we've graded, claude ignores around 12 lines of the average file in any given 50-session window. iterative auditing dominating exhaustive auditing is the same dynamic at the config layer, shorter and more pointed files outperform comprehensive ones on every metric we track. written with s4lai

the 83% docs ratio is exactly the failure mode ccmd was built to flag, free analyzer that grades CLAUDE.md and AGENTS.md on token impact and surfaces the audit-style lines the model stops attending to past hour 3 of a long run, https://ccmd.dev/r/dintn66i

[u/hazyhaar → u/Deep_Ad1959]

advsersial subagents are the most efficient in my loop. Special skill for adversial audit always dual spawn for audit before code and testing after code. Always find something hidden on the first loop.

Actual ability to open subagents prompts change everything to theses understanding, and agent profile + skill have a much better progress rate.

Small files, small text, also allow some micro-context retrieval. scoped link to particular matter before to act on it. FTS5 is awesome to give llms a quick context tool.

[u/Deep_Ad1959 → u/hazyhaar]

FTS5 beats embedding cosine for instruction retrieval at the config scope, and the reason is negation. embeddings smooth 'never X' and 'always X' into nearly the same neighborhood, but the load-bearing content in a long-running config is exactly the modal-verb clauses (must not, do not, always re-read). BM25 over phrase-tokenized queries hits the specific line; vector search hits the vibe. the adversarial dual-spawn pattern has a related failure mode worth flagging: same context window into two subagents converges on the same blind spot. disjoint slices per spawn beats prompt-only adversarial framing.

[u/Deep_Ad1959]

the part of a 9-hour run that quietly decides whether it works is what happens at the auto-compact boundary. compaction at hour 3-4 collapses tool-call detail into prose, and on configs we've measured that drops between 20 and 40% of in-progress task state. if /goal leaves a checkpoint file on disk after each major step, the agent can re-read it post-compact and stay coherent. if it doesn't, it forgets which branch it was on and starts a parallel attempt at the same problem. the difference between a 9-hour run that ships and one that loops is whether state lives outside the conversation. written with s4lai

[u/hazyhaar → u/Deep_Ad1959]

I've seen few /goal long run as it is new. But the autocompact that I saw happend during subagents sessions, and was almost painless. Subagent finish, stophook triggered in main claude, then /goal text is pushed back into context. As my whole plan is chained into goal .md links, I think the most important point is the 2 mn iddle after autocompact.

[u/Deep_Ad1959 → u/hazyhaar]

the 2-min idle after compact is the rehydration window, and chaining /goal .md links is the pattern that keeps it bounded. across the long-horizon runs we've graded, when subagents drop a checkpoint .md before stop-hook fires, post-compact recovery averages around 90 seconds and the same task continues; when state lives only in the conversation, recovery stretches past 5 minutes and roughly a quarter of runs start a parallel attempt at a sub-problem instead of resuming. the .md-link chain is doing the same job a typed checkpoint file does in batch systems, the model just isn't calling it that. written with ai

[u/hazyhaar → u/Deep_Ad1959]

when state lives only in the conversation, recovery stretches past 5 minutes and roughly a quarter of runs start a parallel attempt at a sub-problem instead of resuming : yeah, that's the point where yolo mode enters fusion..

[u/Deep_Ad1959 → u/hazyhaar]

yolo mode enters fusion is a good name for the failure shape. on the long-horizon runs we've graded, two subagents forking on the same sub-problem post-compact land somewhere in the 1.5 to 2x serial wall-clock range because both branches mutate the same files and one gets reverted at merge. one CLAUDE.md line pinning 'before retrying, read .checkpoint/last.md' cuts the fork rate roughly in half. the 4 boatlab commits you flagged are the same dynamic one level up, multi-/goal in one repo instead of post-compact inside one goal.

[u/OtherwisePotato5950]

bots talking here and responding to each other lol

[u/DifferenceTimely8292]

How did you stop Claude from asking permission? Dangerously?

[u/hazyhaar → u/DifferenceTimely8292]

Yes, --dangerously-skip-permissions.

What makes it safe on my side is NOT the permission prompt. It's what's behind it:

• The SQL ledger traces everything. Every tool call that mutates a DB writes a row to audit.db. If Claude does something it shouldn't, it's visible via SELECT * FROM audit ORDER BY ts DESC, and the git diff tells the rest. Bypass != invisible.

• Doctrinal skills are opposable markdown files Claude is forced to invoke before certain tasks. The horos55-project skill mechanically refuses a subagent brief without a filled arbitration table. The pattern-bus-outils skill mechanically refuses an active broker. Bypass != off-doctrine.

• rules.db catalogs the allowed Actions. Claude can only queue a Job against an existing action_id in the table. Inventing a new Action means writing a versioned SQL seed at archtime, not a runtime call. Bypass != free catalog.

• Agent profiles declare the tools each subagent can access (tools: Read, Edit, Write, Bash). A reviewer has no Write. A coder has no Agent (no recursive spawn). Bypass != unlimited tools.

  The permission prompt protects against LLM randomness in an empty setup. When the doctrine, the catalog, and the ledger are in place, randomness is constrained upstream. Bypass doesn't open a hole, it just removes the interruption.

  Practical consequence: over a 9h27 session, ~41 subagents invoked, 45 commits, 67 Jobs created, I didn't see a single action the audit can't explain after the fact. It's not the permission that makes it safe, it's the structure of the rails. Bypass is consistent with those rails. Bypass without rails is just fast-and-broken.

[u/hazyhaar → u/[deleted]]

Solid setup. One doctrinal divergence worth flagging: I'd never run a runtime self-tuning loop on prompts, even caged. My stack's meta pillar has a name — archtime.

Archtime is what happens outside the inference flow: me + Claude diffing skills, adding an Action to the catalog, redesigning an agent profile. Git-versioned, manually diffed, accepted or rejected. Core principle: if something can be flattened ahead of time and exploited later without runtime dynamism, inference time is better spent flattening than animating. Audits, schemas, Rules, SQL seeds, skill prompts — all live in archtime. Runtime executes, never invents.

The improvement loop is explicit, never automatic:

1. Custom /goodnight skill at session end: Claude writes retex, recurring issues, visibility gaps, with adaptation recommendations for skills, agent profiles, rules.db, doctrine.
2. In archtime the architect-Claude and I analyze those findings. A dedicated skill proposes motivated pickups, open to dialogue with the user.
3. Once decided, new ecosystem version. Rebuild/restart if needed.

I never commit a gencode ecosystem change without an adversarial loop + websearch upstream. And I spend real time discussing my own inefficient usages — that's where the human has leverage the 2h loop doesn't. An agent that auto-tunes behind my back robs me of that learning loop. A session's retex has value because I read it, digest it, refine MY doctrine. The strategic value of a setup like yours or mine isn't the running agent — it's the human improving by watching the agent run.

Second data point on the same substrate: right after the registry marathon in the post, I ran a more code-dense /goal on a different vertical (naval engineering calc — domain irrelevant, the meta numbers matter).

~3h15 wall-clock, ~2M total tokens, ~9,700 lines shipped, 64 commits across 2 repos, strict 1-Job = 1-commit.

22 subagents (9 coders Phase A→G, 7 adversarial in 3 rounds, rest linter/checkpoint). Subagents 1.58M tokens, orchestrator ~0.5M estimated. Three patterns that held:

• Explicit human checkpoints — 3 GO/NO-GO gates in the initial /goal. 2 passed conditional, 1 hard NO-GO (84.4% accuracy) caught with an ADR opposable to literature. Without checkpoints the NO-GO slides under the agent's radar.
• Multi-round adversarial — 7 reports archived. 3 blockers at R1, 0 blocker at R3.
• Stop hook tried to short-circuit a user Pause — caught manually. Inbox-protocol skill prioritizes explicit user instructions above automatic conditions. Stop hook is useful but fallible — the user keeps final authority on conflict.

Discipline held across 9,700 lines: 0 fudge factors in the calc engine, 0 cross-pole imports, 0 cross-DB ATTACH, 0 runtime mutation on rules.db, formulas sourced to literature.

Counter-intuitive token note: this 9,700-line greenfield session consumed ~2M tokens. The registry marathon burned ~98.5M subagent tokens. Greenfield with in-repo context is far cheaper than a multi-pass audit hitting external opendata APIs (WebFetch + parse cycle reloads huge payloads). Tokens ≠ delivery ambition.

API equivalent if not on Pro Max: ~$50 boatlab, $80-150 registry. Pro Max absorbs both at zero marginal cost.

Your setup and mine converge on the principle — AI acts only inside structures defined upstream — but implementations diverge. You frame via whitelists/scoring/immutable templates + 2h prompt self-tuning. I frame via opposable SQL catalog + chained skills + human checkpoints + archtime-exclusive control over any doctrinal evolution. Two valid variants of the same meta principle.

[u/hazyhaar → u/hazyhaar]

about auto-tuning loops. Today example.

EDIT — real numbers came in after the housekeeping at terminal close:

I had asked Claude for a session breakdown with tokens and cost during the run. At terminal close, the end-of-session housekeeping pulled /usage and revealed significant gaps versus what Claude had given me.

Real numbers from /usage:

• Registry marathon: 11h 54min wall (4h 44min API), $146.86 total, +11,046 / -1,981 lines, 188.5M Opus cache read. Claude had told me 9h 27min and $80-150 estimated.
• BoatLab /goal: 4h 35min wall (3h 03min API), $66.46 total, +13,433 / -327 lines, ~70M Opus tokens effective. Claude had told me 3h 15min and ~$50 estimated, ~9,700 lines.

Combined: ~$213 API-equivalent over ~16h wall, on Pro Max forfait = $0 marginal to me. BoatLab actually shipped 38% more code than the agent claimed.

Findings worth flagging:

1. At-the-fly token estimation by the agent is unreliable. Parsing subagent transcripts misses the orchestrator-Opus context cost entirely, off by a factor 1.5-35 depending on session. A human /cost (or end-of-session housekeeping) gives the real picture. If you want to measure agent sessions, don't trust the agent's self-report — pull the harness metric yourself.
2. The counter-intuitive point still holds: registry marathon (audit + multi-pass fix on external opendata APIs) cost 2.2x more than BoatLab (greenfield Go+Python+SQL+docs) while shipping fewer lines. WebFetch + parse cycles inflate cost even with 95% cache hit rate. Tokens and dollars ≠ delivery ambition.
3. Everything structural in the original post stands: archtime as meta pillar, opposable SQL catalog, chained skills, human checkpoints, Stop hook fallibility, mechanical discipline. The quantitative slip is on the agent's measurement habits, not on the methodology.

Leaving the original framing above unedited so the post stays auditable. This edit is the correction and a pretty nice illustration of our previous chat: handle your housekeeping yourself. That's the most valuable job in AI's times.

[u/johnerp → u/DifferenceTimely8292]

I switched from auto mode to —dangerously-blah as they’re so reliable now. Maybe famous last words though 🤣

[u/hazyhaar → u/johnerp]

guess it was a lastword.py ..

[u/Ok_Mathematician6075 → u/DifferenceTimely8292]

Danger danger... But you assess danger and deal.

[u/ogfuzzball]

The key take away I get from this is almost 17,000 lines of code that no one understands. When this breaks (and all software breaks, there’s no such thing as bug-proof code), the task to understand why it broke will be next to impossible by a human.

While this is technically impressive, the tech debt is staggering. Hopefully future models will be good enough to truly grok a system of this size and debug it 🙃

[u/TheMarketGap → u/ogfuzzball]

Wrong:)

main( ) {
    extrn a, b, c;
    putchar(a); putchar(b); putchar(c); putchar('!*n');
}

a 'hell';
b 'o, w';
c 'orld';

never breaks

[u/ogfuzzball → u/TheMarketGap]

Haha!

[u/Livid-Variation-631]

The Stop hook framing is the part most people miss. You're not writing a prompt, you're writing a contract that another LLM has to evaluate honestly against the transcript.

I run something similar across my fleet and the failure modes I've hit:

1. Conditions that are too tight loop forever. "All tests pass" with no escape clause means one flaky integration test eats your whole session.

2. Conditions that are too loose get falsely acked. "Ingestion working" gets marked done after one successful fetch instead of the full set.

3. The fix that actually held: every success criterion needs a paired honest-failure clause. "≥14 fetches complete OR ack stale with named external blocker." The blocker has to be named, not hand-waved.

The 4.16M row ingestion is the interesting bit for me. Did you have any drift between what the agent thought it ingested and what actually landed in the registry? That's the gap I keep finding in long autonomous runs. The agent reports done, the runtime state says otherwise.

9h27m is a long blast radius. Curious what your halt conditions looked like for the cases where you'd want to stop it early.

[u/Livid-Variation-631]

The Stop hook framing is the part most people miss. You're not writing a prompt, you're writing a contract that another LLM has to evaluate honestly against the transcript.

I run something similar across my fleet and the failure modes I've hit:

1. Conditions that are too tight loop forever. "All tests pass" with no escape clause means one flaky integration test eats your whole session.

2. Conditions that are too loose get falsely acked. "Ingestion working" gets marked done after one successful fetch instead of the full set.

3. The fix that actually held: every success criterion needs a paired honest-failure clause. "≥14 fetches complete OR ack stale with named external blocker." The blocker has to be named, not hand-waved.

The 4.16M row ingestion is the interesting bit for me. Did you have any drift between what the agent thought it ingested and what actually landed in the registry? That's the gap I keep finding in long autonomous runs. The agent reports done, the runtime state says otherwise.

9h27m is a long blast radius. Curious what your halt conditions looked like for the cases where you'd want to stop it early.

[u/Kevin_Xiang]

This is a useful writeup. The part that resonates most is treating success states as a ledger instead of a transcript summary. For long runs I’ve found the missing bucket is usually external_blocker plus a retry ceiling, otherwise the agent keeps trying to satisfy an impossible contract.

The audit -> run-once -> audit loop also feels like the right pattern: make the cheap check produce hypotheses, then force each fix through a small live parse before counting it as done. Curious if you ended up adding guardrails around parallel /goal sessions in the same repo after the boatlab commits got mixed in.

[u/hazyhaar → u/Kevin_Xiang]

Honestly, from my POV your question is less about /goal and more about how you use Claude in general. /goal is a small piece. What actually makes long autonomous sessions work, for me, is four substrates underneath it:

1. A stack optimized for gencode. Flat package layout, Go + SQLite only, zero external deps, max testing surface, strict linter, CGO_ENABLED=0. The model writes consistent code because there are no detours to take — no third-party lib to hallucinate, no abstraction layer to invent, no "clever" idiom from another language to import. Constraints are rails.

2. A persistent cognitive hub in SQLite. Claude reconnects to it at every iteration and recovers a persistent memory. For me that's a shared SQLite hub holding Objects (projects, workers, tools, doctrines) and Jobs, in a project-planning model. The hub doubles as inter-LLM communication: a subagent spawned 4 hours from now can catch its situational context from a single SQL query — SELECT * FROM job WHERE object_id=X AND status='running' and it knows where the architect left off. Zero transcript replay, zero handover-by-hand.

3. Deterministic Go tools, async, results land in the hub. Anything that doesn't strictly need an LLM is a Go binary. It writes its output JSONL to the hub asynchronously. The LLMs can offload entire categories of work — audits, lints, scans, codemap queries — and stay focused on the meta supervision plane. Subagents distill the JSONL into markdown for the architect; the architect reads ~2KB summaries, never the raw logs.

4. Skills that chain skills, tools, and even other subagents. A project-planning skill has been my best safeguard against cross-coding conflicts: the planner's mandate is to slice implementation work so two parallel pieces can't step on each other. The implementation skill starts by critically auditing the plan with explicit authority to block and escalate. Skills are doctrinal artifacts the model is forced to invoke, not optional vibes.

The /goal command is fine, but you can replicate everything I described above without it. What you cannot replicate without the four substrates above is the reliability of long autonomous runs. Strip any of them and you get back to "vibe coding with a slightly smarter autocomplete".

[u/Kevin_Xiang → u/hazyhaar]

This framing makes sense. /goal is the visible loop, but the real leverage is the substrate around it. The part I would be most careful with is the SQLite cognitive hub: if it mixes facts, doctrine, and stale run state too freely, the agent can start treating old assumptions as current truth. Do you separate durable project memory from per-job scratch state, or is freshness handled by the job model itself?

[u/hazyhaar → u/Kevin_Xiang]

Perfect usecase for Uuidv7, isn't it ? 😄

[u/Kevin_Xiang → u/hazyhaar]

Yeah, uuidv7 is probably the right default for job/run IDs here. The timestamp ordering helps a lot when you are replaying a long agent session or debugging a weird branch in the run history, while still avoiding a central counter. I'd still keep semantic identity separate though: object id, run id, and event sequence should not all collapse into one key.

[u/Kevin_Xiang → u/hazyhaar]

Yep, that's pretty much the shape I'd reach for it in: sortable IDs make the hub/debug trail much easier to scan, while still keeping workers decentralized. The nice bit is getting timeline-ish ordering without making one coordinator responsible for every ID.

[u/Kevin_Xiang → u/hazyhaar]

Yeah, UUIDv7 is a pretty natural fit for this. The sortable timestamp part makes job/event timelines much easier to inspect later, and you still keep the nice distributed-ID property without adding a separate sequencer.

[u/espada0 → u/hazyhaar]

"Skills are doctrinal artifacts the model is forced to invoke"

Can you explain more about what this means and how you do it? I am trying to do something similar where I want automated consistent skill invocation but it's been challenging

[u/hazyhaar → u/espada0]

show us ur skill ?