Ai-Generated

Most agent tutorials show you the happy path. They give you a chat UI, a tool, and a one-shot demo. Then you try to build something real, and the demo collapses under a single missing concept: how state actually flows, how to test a non-deterministic system, what to do when a tool takes ten minutes instead of ten milliseconds, or how two agents from different teams find each other in production. The 5-Day AI Agents course on Kaggle is the closest thing I have found to a structured curriculum that covers the full life-cycle of an agent system, not just the demo. Ten codelabs, five whitepapers, and a single coherent framework that ties it all together. I worked through every codelab end-to-end. This post is the tutorial I wish I had read first: what each lab is actually trying to teach, the actual code from the codelabs, how to think through the exercises, and the parts of the material that translate cleanly into a real production system. The patterns in the course are not tied to one framework. The same ideas show up in LangGraph, CrewAI, AutoGen, and any custom agent runtime. I am using the course’s framework vocabulary here, but the lessons are not. ...

I have a bad habit. When I read a good blog post, I read it once, nod, and never actually try the thing it describes. This time I was determined to break that pattern. The post was Cloudflare’s “Build Your Own Vulnerability Harness”. It described a 6-phase multi-agent security audit pipeline. I had been wanting to test something like this for months. So I read the post, closed the tab, and opened a terminal. This is what happened next. The good parts, the embarrassing parts, and the part where I found a real authentication bypass in a 6,000-line Python library that downloads 50 million times a month. ...

TL;DR Three minutes, top to bottom: It works. Bridging Presidio’s EntityRecognizer contract to PyThaiNLP’s thainer-v2 engine (WangchanBERTa fine-tuned on Thai NER corpus) gives a usable PII de-identification pipeline for Thai text in ~250 lines of glue code. Final headline numbers (60-case test corpus, strict mode): F1 = 66% overall (P=80%, R=56%) EMAIL, IP, URL, THAI_NATIONAL_ID (with checksum), THAI_PHONE_NUMBER, MONEY: 88-100% F1 PERSON: 57% F1 (80% precision, 44% recall — the free-text bottleneck) The Thai national ID recognizer is the new piece: 13 digits with the official mod-11 checksum algorithm. Distinguishes category prefixes (1-8 valid for citizens, 0/9 reserved) and rejects bad checksums at the recognizer layer. Score 0.95 if checksum valid, 0.5 if just format match. The Presidio default English NER is destructive on Thai text. spaCy’s English NER running on Thai sentences produces many false positives (PERSON on เบอร์โทร, ORG on ลูกค้า). Solution: gate the English NER recognizer behind a “text is mostly non-Thai” check; route Thai text to WangchanBERTa. The interesting finding: a WangchanBERTa recognizer that filters out spans containing common Thai particles (ผม, อยู่, ที่, ฝากเงิน) drops the over-tagging rate by ~60% with no measurable recall loss. The model knows it’s a PERSON, it just doesn’t know where the name stops. Tokenizer drift is real: WangchanBERTa’s tokenizer emits <unk> for OOV characters, and the 5-char <unk> token doesn’t match the 1-2 source chars it represents. Naive offset arithmetic drifts after the first <unk>. Fix: walk the source text alongside the token stream and search for each token’s actual position. Don’t ship a recognizer without a no-PII control case. Case 4 in the test corpus (a weather sentence in Thai) is the most important test — it shows whether your pipeline over-fires. Real PII systems miss more from false positives than from false negatives in production logs. This post walks through the integration step by step, the test corpus, the quantitative evaluation, the checksum-validated Thai national ID, the things I’d do differently in a real production deployment, and the honest list of what still doesn’t work. ...

TL;DR for busy operators Three minutes, top to bottom: DeerFlow is powerful and highly composable: LangGraph runtime, FastAPI gateway, MCP extensibility, skills, channels, memory, subagents, sandbox modes, custom agents, and a guardrails layer for pre-tool-call authorization. This is not a toy stack. Power comes with a steep security responsibility curve: the docs and config make it easy to run in insecure ways — skip ingress auth, overexpose API routes, enable high-impact tools broadly, or run local sandbox in shared contexts, and you’re asking for trouble. OpenClaw is more opinionated operationally about channel policies, trust boundaries, gateway hardening, and tool restriction baselines for a personal-assistant model. Clearer security defaults out of the box. Runtime reality matters: DeerFlow can run in constrained environments, but full-stack convenience depends on host prerequisites (nginx/docker/toolchain), and no configured model means no actual agent run. Bottom line: treat DeerFlow as a programmable power framework, not a safe appliance. Explicitly harden ingress, authz, tools, sandbox mode, MCP secrets, and channel trust before exposing it to real users. Why this analysis exists Most AI-agent platform writeups make one of two mistakes: ...