ai

The chat surfaced a valid new angle and one unverifiable statistic. Finding angles and proving claims are different jobs; only one of them belongs to the chat.

TL;DR: An AI chat surfaced a genuinely new research angle, but then invented a stat attributed to Stanford HAI that couldn't be verified anywhere. The lesson: finding angles and proving claims are separate jobs, so the pipeline now asks AI for angles, then opens every primary source manually. Citations offer traceability, not truth; walking the trail is your job.

The fallback fired, the article shipped, and the real failure was one clipboard probe returning 410 Gone. Diagnosis before fallback, now a written rule.

TL;DR: A clipboard probe returned HTTP 410, exposing that an automated fallback had silently routed around a Qwen generation failure. The fallback fired on exit code 1 without diagnosing the cause, so the pipeline looked green while the primary path rotted. Now every failure triggers a doctor script first, and exit codes are disambiguated.

My agent's memory only ever grew, so I built a weekly no-agent cron that turns seven days of messages into a ratify-it-myself candidate report.

TL;DR: The author audited their agent's memory files and found everything only accumulates, never gets pruned or corrected. ChatGPT and Letta solve this with out-of-band batch synthesis, so the author built a weekly Python script that generates a candidate report instead. They insist on manual ratification since a single fabricated entry could poison a single-agent setup.

Queries returned just a path and a score. So I stole OpenViking's L0 summary pattern: one line per dossier, no new infrastructure.

TL;DR: Search results in my knowledge base showed only scores, so I kept opening dossiers just to judge relevance. Rather than install OpenViking, I stole its L0 tier pattern and added a mandatory one-line summary field to each dossier in about 40 lines of Python. Making summaries a hard requirement keeps them consistent, no new dependency needed.

ChatGPT memory is not a real-time summary of your sessions. I break down the real mechanism: periodic synthesis, system prompt injection, and the privacy cost.

TL;DR: ChatGPT doesn't scan your chat history with RAG. Instead, it periodically synthesizes your conversations into a static profile injected into every new session's system prompt, including roughly your last 40 typed messages. Since deleting one chat won't erase derived insights, treat memory as a managed archive, not a perfect record.

A repo with many coding agents needs more than one instruction file: AGENTS.md for procedures, user memory for preferences, a fact store for on-demand facts.

TL;DR: Repeated agent mistakes in a repo pointed to missing documentation, not a bad agent. The fix is a three-layer setup: AGENTS.md for repo procedures, user memory for personal preferences, and a fact store for reference material. Claude Code reads the same rules through a CLAUDE.md that imports AGENTS.md, keeping every session consistent.

A plain-language glossary of AI agent terms from primary sources: agent vs workflow, skills, three kinds of memory, RAG, and pipelines.

TL;DR: Agents decide their own next steps while workflows run on fixed code paths, and the distinction comes down to who holds the steering wheel. Skills are procedural SOP files loaded only when needed, unlike memory, which carries procedural, semantic, or episodic information across sessions. Pipelines add triggers, gates, and watchdogs to make autonomous agents trustworthy.

A crashed cron loop resent the same prompt. A send-then-poll async contract plus two state files make Qwen chat generation safe to re-execute.

TL;DR: After a cron crash resent duplicate prompts and burned quota, the author swapped queue infrastructure for two empty files as idempotency keys: one marks the prompt sent, the other the result done. A four-state exit code contract (42, 3, 0, 1) mirrors the async request-reply pattern client-side. Since cron retries crashed jobs, making re-runs harmless beats a database or broker.

OpenCode's usage board is led by cheap open models, not benchmark kings. How I read usage, retention, and price before switching models.

TL;DR: Benchmark leaders like GPT-5.6 top SWE-Bench, yet deepseek-v4-flash leads OpenCode's real-world usage, suggesting cost, speed, and context length matter more than peak scores. The author recommends checking usage volume, momentum, and weekly retention as satisfaction signals. Treat official model lists as a starting point, then validate against usage data and a small trial in your own repo before committing.