Lesson 1: work offline first, then sync

I tried running Claude Cowork and Claude Code across three devices while the working files sat in OneDrive. It kept breaking. On Windows, placeholder files, partial sync, and mid-write collisions are enough to corrupt a WAL SQLite setup when `-wal` and `-shm` files get out of step.

Now, live runtime stays local at a default folder. Cloud storage is for archive and distribution, not for active runtime state.

Keep live DB files and active snapshots in a local non-synced folder. Mirror only what needs to be inspected or backed up.  

This one change removed a lot of avoidable failure.

—

Lesson 2: go model agnostic

Claude and Codex (ChatGPT) are both useful, but each one repeats certain mistakes. As versions change, the mistakes change too. If the whole workflow depends on one model, you inherit its blind spots.

I now treat agents as interchangeable workers behind shared infrastructure. Skills, rules, and memory stay in vendor-neutral files, accessible from the same VS Code and CLI.

Role split works better than model loyalty:

• one agent builds,
• one or more review/red-team,
• one referees,
• deterministic checks decide pass/fail when possible.

When there is disagreement, escalate to referee logic.

—

Lesson 3: build a loop

The core pattern comes from the LLMOps loop in a YouTube video by Sean’s AI Stories You Can Learn AI Agent Harness & Loop Engineering In 19 Min | LLM Ops, Eval, Tracing, RAG.

Operationally, each run should pass through:

trace -> eval -> observe (tokens, latency, errors) -> diagnose -> gate -> release -> prompt/config update.

The loop makes improvement systematic. Therefore, any workflow that can use a system, should in theory use a loop.

Eval needs two lanes

Some outputs are measurable. Some are not. Treat them differently.

1. Quantitative lane: code, data, strict formats, factual claims. Use reproducible scorers (benchmarks, eval harnesses, pytest/additive diff, rubric-based LLM judge).
2. Taste lane: voice, design quality, strategic fit, brand tone. Here, human scoring is still the right call.

The hard part is not “doing eval.” The hard part is routing each artifact to the right evaluator.

Nothing would matter if a system cannot store memory

There should be a dedicated memory system surrounding the loop:

1. procedural memory in `skills/`, –> I’m using MD (Skills.MD)
2. semantic memory for durable facts, –> I’m using WIKI (MD)
3. episodic memory for what happened and why. –> I’m using SQLite

Then improvements can move across devices through harvest -> promote -> distribute.