Something I've been thinking about is how AI agents handle data that changes while they're processing a task. For example, an agent checks a booking slot and sees it as available. Before it actually creates the booking, another process books that same slot. The agent made its decision using valid information, but that information was already outdated by execution time. I'm curious how experienced n8n builders handle this. Would you use optimistic locking, database transactions, or revalidate the resource immediately before committing the action? It seems like a small timing issue that could create some surprisingly difficult bugs.

A high score does not mean the chunk belongs to the right client. I check the client id and the source file on each chunk before the model sees it, and I drop what does not match. That check after retrieval is useful, but on its own it has two gaps. First, if the top five results all belong to the wrong client, dropping them leaves you answering from whatever scored sixth. The wrong text has already passed through the pipeline and its logs by then. Second, a chunk can belong to the right client and the right version, and still be the wrong paragraph, because the answer uses a sentence from somewhere else in the document. So I use two layers, in this order. Filter at the query. Ask only for chunks with the right client id, so the other client's chunks never come back at all. Verify after retrieval. Check the client id, the source file and the version on each chunk that comes back, before the model sees it. Check the sentence, not just the chunk. Make the model return the exact sentence it used, then check in code that the sentence sits inside the chunk it was given. Set a minimum score. If nothing clears it, the answer is I cannot find that in your documents, not the sixth best chunk dressed up as an answer. Log every drop, with the reason: wrong client, stale, low score. A rising count of wrong client drops means the indexing is mixing clients, and that is fixed at the source. The filter does the main work, the check after retrieval is the backup, and the minimum score stops a weak chunk from becoming an answer. What do you check on a retrieved chunk before you trust it?

I have one Tavily key on the free tier, 1,000 credits a month, reset on the 1st. Claude Code, Codex and Hermes all use that same key. When sessions run in parallel they drain one pool, and none of them sees what the others spent. On 2026-09-15 I measured it: 786 credits across 113 calls. So a single Tavily MCP call costs several credits, not 1. The heavy calls are worse. A crawl is 100+ credits, and tavily_research can be anything from 4 to 250. So research is never called now without flagging the cost first. On 09-19 I moved whole-site and follow-links jobs to Scrapling, free and local. Tavily crawl/map is only the fallback now. The order is WebSearch, then Google in the browser pane, then Scrapling, then Tavily. One task gets at most ~3 Tavily escalations before it stops and says so. Scrapling has its limits too, measured the same day. Cloudflare-walled pages only pass with real_chrome=True, the bundled Chromium fails there. DataDome on ImmoScout24 stays closed. What I take from it: pick the tool that's most effective first, and the free one only when it's a tie. And measure what a metered call really costs before you budget around it. If you share one metered API key across several agents or tools, how do you track and cap what each of them spends?

I’m starting out with roofers. I follow up on their online leads and only charge when an inspection is booked on their calendar. I’m trying to work out how people make this into proper money. do you keep the price per booking low and go for volume, or charge more per booking and take fewer clients? or add a monthly fee on top? and roughly how many roofers does it take before it’s a real income and not just side money? like if someone wanted to get to ~5k a month, what would that look like, number of clients, price, anything?

I successfully completed day two and scraped a job board. However, this activity really consumed a lot of my session tokens (23%). It was actually my fault as I didn't fully understand the extent of what I agreed on during the planning stage. But it's a great lesson to use the planning stage to narrow down what you really want to achieve. Anyway, I did a second run, which I find more useful for the kind of work that I do. It's scraping off a branding guideline from a website and saving it as a design system for possible use with Claude Design. I think this really saves time rather than doing it manually.