> ## Content Index > Fetch the complete content index at: https://operators-ai.ghost.io/llms.txt > Use this file to discover other available public pages before exploring further. # This week: everyone's data got cheaper. Yours didn't. - URL: https://operators-ai.ghost.io/your-data-vs-everyones/ - Published: 2026-10-02T12:50:08.000Z - Updated: 2026-10-02T12:50:08.000Z - Description: Amazon opened Seller Central to agents and kept the storefront shut. The side window is closing. A member's repricer numbers came in. And I broke the system that holds my timesheets on the last day of the month. Plus the ingestion job spec for paid members. - Author: Justin Zsimovan - Tags: weekly Last weekend I told our Discord we're going to push harder on data: getting it in, storing it, shaping it, getting it back out. The members kept telling me that's where the value is, and when my agent went back through months of our chat history it agreed with them. This is the first weekly built that way, and the week cooperated. The data your business runs on got sorted into two piles this week. Anything anyone can scrape is either getting locked down or getting cheaper for everybody at once. The data only you hold (your orders, your books, your history, your notes) is getting easier for your agent to reach through official doors. One pile is a race you're renting. The other one is yours, and this week I found out how much I depend on it. ## On the bench On Wednesday I was at my desk with some time, so I decided to update GBrain, the memory system my agent reads before it does anything. That afternoon I posted in the Discord: "fair regular warning with gbrain: its transformative but fussy." A minute later: "I think it broke in about 100 different ways." Any other week that's an irritating afternoon. Wednesday was September 30. Here's what lives in that system. Every client, every person, every deal, the code I write for them, the notes from every call. My consulting business is built around it, because it's how my agent knows where everything stands when I open a new session. It is also my timesheet ledger. My hours get written there all month, and at month-end my agent reads them back and builds the invoices. The last day of the month is invoice day. I went to do it and couldn't. The project I run it on had changed how some core pieces work in that release, and the changes stacked. The next morning I pulled the flagship model off the bench for the first time in two weeks and had it take inventory. Here's what it found: - The system's own health score was sitting at about a quarter of its max. - The sync that keeps it current had stalled overnight on a single file. - The new version changed how one overnight job identifies itself, so the job lost track of what it had already done. It re-processed a whole month of old material and wrote roughly fifty duplicate pages. - Five of my longest meeting transcripts were each too big for the model to read in one pass. Each one failed three times an hour and got resubmitted on the hour. In one day that burned tens of millions of tokens on jobs that could never succeed. None of that lost data, and I want to be precise about it. A few weeks ago I wrote about [a backup that sat on the same volume the agent could reach](https://operators-ai.ghost.io/the-agent-did-the-hours/). That isn't what happened here. Every page was still there. The copy was fine. The problem was that the system behaved differently after an update, on the one day of the month I couldn't afford it. What got invoicing done was boring. Underneath all the search and indexing, every page in that system is a plain text file in a folder. My agent read the ledger file directly, the way you'd open a spreadsheet, and the invoices were drafted the next morning. Then we spent the rest of the day putting the clever parts back together. The confession is simple. I spent years on the enterprise side, and I would never let a client patch the system that runs their billing on the last day of the quarter. Big companies call that a change freeze, and they enforce it with a calendar. I did the opposite to myself because I had a free afternoon and the update was sitting there. This is the bench because it's the other half of everything below. The data only you hold is the kind nobody can commoditize, and it's getting easier for your agent to use every month. It's also the kind you can lock yourself out of, because nobody else has a copy of my hours for September. ## The gauges ### The front door: Amazon opened Seller Central to agents What I saw: at its Accelerate conference on September 23, Amazon [announced Seller Assistant workflows](https://www.aboutamazon.com/news/innovation-at-amazon/seller-assistant-plugin-amazon-quick-claude?ref=operators-ai.ghost.io) that "run continuously... even when the seller isn't logged in to Seller Central." For each workflow you choose whether it only makes recommendations or takes actions, and actions get your approval before they run. Every action lands in an audit trail. The same announcement launched a Selling Partner plugin for Amazon Quick, plus a beta in Claude for U.S. stores, which Amazon says connects in about 60 seconds. Primary account holders can claim a free year of Quick Plus through December 31. The best look under the hood came from [API Evangelist](https://apievangelist.com/2026/09/24/amazon-opened-seller-central-to-agents-and-kept-the-storefront-closed/?ref=operators-ai.ghost.io), who went and checked what an agent actually meets. The plugin is open source. It's one official connection point for agents plus eleven written skills (listing fixes, stockout checks, the full FBA inbound workflow), and each skill ships with its own test cases. Write actions are always drafted for your approval. Admins grant agent access to other users on a Seller Central page called Manage Agents. A [walkthrough from Stellagent](https://stellagent.ai/insights/amazon-seller-assistant-agentic-workflows?ref=operators-ai.ghost.io) adds two details worth knowing: new workflows preview against simulated data before they touch your account, and the primary account plus every secondary user can view, edit, approve and run every workflow. The day after, [Marketplace Pulse reported](https://www.marketplacepulse.com/articles/amazon-opens-seller-central-to-rival-marketplaces?ref=operators-ai.ghost.io) Amazon is also pulling eBay, Shopify, TikTok Shop and Walmart management into Seller Central for free. One number to read carefully: Amazon says sellers accept Seller Assistant's recommendations more than 90% of the time. That tells you people click yes. It doesn't tell you whether yes made them money. The door doesn't open every room yet, either. One of our members built a page in their own database to catch missing inbound units and file reimbursement claims. Their agent found the API was serving stale inbound data that Seller Central had already corrected. They also wanted to manage sourcing costs the same way, and the agent found no API for that screen at all, even after being handed a capture of the page's network traffic to hunt for one. That one stays a download-edit-upload chore for now. And one rule I learned about this week, which surprised a few people in the Discord: Amazon's [developer policy](https://sellercentral.amazon.com/mws/static/policy?documentType=AUP&locale=en%5FUS&ref=operators-ai.ghost.io) says not to "aggregate data across Authorized Users' businesses." That rule is aimed at apps and developers pooling many sellers' data. A single seller connecting to their own store is exactly what the API is for. Should you pay attention? If you sell on Amazon, yes, this month. This is the official way in for your agent, and it's free. If you don't sell on Amazon, watch it anyway. Every platform holding your records is going to build a door like this, and Amazon's is the clearest example so far. My position: use the door, and start it in recommend-only mode. Before you turn on anything that acts, open your user permissions and look at who has secondary access, because your VA or your agency can approve and run these workflows too. And keep your own copy. One Amazon VP put the goal plainly: ["Our vision was that they would never have to log into Seller Central."](https://apievangelist.com/2026/09/24/amazon-opened-seller-central-to-agents-and-kept-the-storefront-closed/?ref=operators-ai.ghost.io) That's convenient, and it also means the memory of how you run your business lives on Amazon's servers. Pull what you can into a database you own. The member above only caught the stale data because their agent had its own copy to compare against. ### The side window: closing, and getting cheaper for everybody What I saw: on September 21, Amazon [cut off Meta's Muse agent](https://www.geekwire.com/2026/amazon-blocks-metas-muse-ai-assistant-in-new-standoff-over-agentic-shopping/?ref=operators-ai.ghost.io) from shopping its site, with a popup that reads "Continued access by an unauthorized AI agent violates Amazon's Conditions of Use, to which our customers have agreed." The wording matters. In August the Ninth Circuit [ruled](https://cdn.ca9.uscourts.gov/datastore/opinions/2026/08/04/26-1444.pdf?ref=operators-ai.ghost.io) in the Perplexity case that the user, not the AI company, was the one accessing Amazon's computers under federal anti-hacking law. That left contract and terms-of-service claims open, and the popup is built on exactly that. The other half is infrastructure. Cloudflare's [new defaults](https://developers.cloudflare.com/bots/additional-configurations/block-ai-bots/?ref=operators-ai.ghost.io), effective September 15 for newly added domains, block bots classified as Agent on pages that show ads. Cloudflare's definition of Agent explicitly includes "browser-use agents." That's new domains only, so don't read it as the whole web flipping overnight. It does mean the default for the next generation of websites is no. Our Discord ran this experiment live all week. One member tried to read a big off-price retailer's site and found it a lot harder than expected, then ran into the retailer's terms. Another found that a different agent product could reach some blocked stores from its own cloud computer when their main setup couldn't. A third found two agent products that each worked on sites the other couldn't. My answer to the question was honest and not very satisfying: try browser control, try another tool, and past that you're paying a scraping service or a stealth browser to play cat and mouse. Then there's commoditization, which is the side window's slower problem. Even when you can get the data, so can everyone with the same subscription. A sourcing-data tool in our corner of the world launched a discounted partnership this week, and my gut said what it usually says: tools like that open a window, and the margin shrinks as the data gets commoditized. A former colleague started a data-transformation firm a few months ago and is watching the big providers ship his features as table stakes, roughly every week. One member put the conclusion well in the Discord: anything outward-facing (scrapers, sourcing tools) is going to get commoditized, and bespoke internal tools are the real play. I wrote my version of this [on X on Wednesday](https://x.com/Flippin4Gold/status/2105322339806105816?ref=operators-ai.ghost.io): "The model thats going to get nuked is the one where a live price is compared to a sale price on amazon." And: "The arbitrage models that survive and thrive will be based on relationships with suppliers, speculative judgements, holds, etc." That's reselling. Swap in your industry. The part of your business that runs on public prices is turning into a volume game. The part that runs on relationships and judgment isn't. Now some speculation, labeled as speculation. I think the big retailers figure out they want agent traffic, and then they serve agents different pages, and different prices, than they serve people. Whatever window you're using today may hand you a different number tomorrow, and you won't know it. Should you pay attention? Yes, if any part of your margin comes from reading somebody else's website. Every quarter that window costs more to keep open and returns less, because more people are standing at it. My position: use the window while it's open. I'm not going to tell you to stop. But don't build the business on it. Put your engineering time into the data only you hold, because that's the one asset in this issue that gets more valuable as everyone's agents get better. ### Follow-up: the AI repricer numbers came in What I saw: [three weeks ago](https://operators-ai.ghost.io/the-agent-did-the-hours/) I told you a founding member was testing SellerSnap's new AI repricing engine against his own books before trusting it, and that there was no result yet. This week, a different member brought numbers. Their agent went through last month's orders. About 30% of shipped units sold at the minimum price. Most of the units that sold at the minimum already had a 30-day average price at that level, so the engine's promise of extra profit didn't show up on those products. Their June through August history showed a larger share of sales landing above the minimum than September did. One honest caveat, which they raised themselves: after switching engines they raised a lot of minimums on gut feel, so September's baseline isn't clean. The yo-yo pricing they relied on still works about as well as it did on the old engine. A second member is testing the same engine and thinks its Balanced setting runs too aggressive. Their plan is to add their own conditions in front of the AI, so it checks a few factors before the engine takes over. They give the API read-only access and have Claude build the upload templates. I've only found one lever myself, the min and max values, and I haven't given my agent write access to the repricer yet. SellerSnap's [own page](https://sellersnap.io/newera/?ref=operators-ai.ghost.io) claims about 10% more profit than its previous engine "across 12+ months of testing with real sellers." It also says the new engine always respects your min and max, and that the old engine is still available. You can switch back per product at any time. Should you pay attention? Yes, if you've turned on any vendor's AI mode that touches price, and that's most of you this year. The same test applies to an AI bid tool, an AI scheduler, or an AI quoting feature. My position: the most useful thing in that thread was a metric. Where do your sales land inside your min/max window, before and after you switched? The first member came up with it, and the second said they'd never used that benchmark. You can only run it if you own the history: the member's own database is what made the number possible, because the vendor's dashboard grades itself. One month on a moving baseline isn't a verdict. It's enough to make me switch a test group back to the old engine and compare, which costs nothing. ### Quick reads - **OpenAI DevDay: always-on agents, a cheaper Sol, and a smaller Pro 200.** The [recap](https://openai.com/index/devday-2026-recap/?ref=operators-ai.ghost.io) introduced Dots, always-on agents for Pro and Business Premium, and GPT-6.1 Sol, which OpenAI says gives near-Astra results "at a fifth of its standard input and output token prices" and is available to API, Plus, Pro and business plans. The fine print is on the [Pro tiers page](https://help.openai.com/en/articles/9793128-about-chatgpt-pro-tiers?ref=operators-ai.ghost.io): Pro 200 is back for new subscribers with a lower usage allowance at the same $200\. If you were subscribed at any point from September 22 to 10am Pacific on September 29, you keep the old allowance through October 29\. The same page says Pro accounts can't be used for "automatically extracting data." If your agent scrapes through a ChatGPT subscription, that's the side window again. - **ChatGPT scheduled tasks lose GPT-5.5 on October 14.** Per OpenAI's [scheduled tasks docs](https://learn.chatgpt.com/docs/automations?ref=operators-ai.ghost.io), GPT-5.5 retires from ChatGPT, ChatGPT Work and Codex on all plans that day, and any scheduled task using it needs a new model before then. This is last week's [re-seat](https://operators-ai.ghost.io/the-chair-got-the-upgrade/) with a deadline. Go look. - **Claude Sonnet 5.5 is a strong option for the middle seat.** [Anthropic shipped it](https://www.anthropic.com/claude-sonnet-5-5?ref=operators-ai.ghost.io) September 28 at $2/$10 per million tokens, the same price as Sonnet 5, and says it runs 30% faster and costs up to 30% less per task. Anthropic also says Opus 5.5 "remains clearly stronger" for complex work that needs judgment. On my own week with Opus 5.5: max effort ate about a fifth of my weekly allowance in one night and ran slow. Medium is the sweet spot for back-and-forth work. It's the first model I'll test in the middle seat from last week's re-seat. ## Your move Ten minutes. Pen and paper works. 1. **(3 min) List the data your agent or automations actually read to do real work.** I mean data, not tools: sales, orders, timesheets, supplier prices, competitor prices, your inbox, your reviews. Five to ten lines. 2. **(3 min) Mark each line with one letter.** M if only you hold it (your books, your history, your notes). F if you reach it through a front door the owner built for you (an API, an export, an official connector or plugin). W if you reach it through a window: scraping someone else's site, a logged-in browser session, or a tool that does one of those for you. 3. **(2 min) Next to every W, write one sentence: what happens if this closes tomorrow?** If the answer is "I lose my edge," that line is your biggest risk, and the risk grows every quarter. 4. **(2 min) Next to every M, write where the plain copy lives and whether you could read it with the tool on top turned off.** Then find the day of the month that line matters most (close, invoicing, payroll, reorder day) and put a no-upgrades block on your calendar for the three days before it. That's the change freeze I didn't follow. If your list has no M's on it, reply and tell me. That's the conversation I most want to have. ## The meme ![Expanding brain meme: scrape the retailer's site, run a stealth browser so they can't tell, pay a service to play cat and mouse for you, read your own sales data through the front door](https://storage.ghost.io/c/6f/e7/6fe775a0-dff8-49ae-9628-ec858b8ecd0e/content/images/2026/10/2026-10-02-expanding-brain-front-door.png) The most advanced move on the list is also the least exciting one, and it's the only one that gets better as everyone else's agents improve. ## The playbook: the ingestion job Operators: two threads in the Discord this week were really one question. One was about Keepa tokens: how to run big jobs without draining the plan or stalling halfway. The other was about buy sheets: one member's agent reads order emails and expands the purchase records, and they asked whether it's best to let the agent do that on its own in production. My answer that day was the spine of this playbook: use the agent to nail the pipeline, with the goal that the final pipeline is boring code that runs predictably on a schedule. This playbook turns the M and F lines from Your move into data you own. It covers the five parts every ingestion job needs, the ladder from agent to skill to boring code, where each step lives in the harness you already run, and a prompt to hand your agent. As usual, it's written so your agent can build from it. ### The five parts Every job that pulls data from somewhere into a place you own needs these five things. Most homegrown jobs have one or two. The missing ones are where the silent failures come from. | Part | What it does | What happens without it | | --------------------- | ---------------------------------------------------------- | -------------------------------------------------------------------- | | Pull budget | Spends the source's rate limit on purpose | The job drains the plan, stalls, or starves your interactive lookups | | Checkpoint and resume | Records how far it got | A failure at row 4,000 restarts at row 1, or double-writes | | Exception log | Puts anything it can't handle where you'll see it | Bad rows get skipped silently and the totals look fine | | Freshness check | Proves the data matches the source of truth | You make decisions on stale numbers and can't tell | | Promotion path | Moves the job from agent to skill to code as it stabilizes | You pay the model to repeat the same steps forever, and they drift | ### Part 1: The pull budget Most data sources you'll pull from use a token bucket. Learn the two you're most likely to hit. **Keepa** ([plans and tokens](https://keepa.com/api-docs/plans-tokens.html?ref=operators-ai.ghost.io), [request basics](https://keepa.com/api-docs/request-basics.html?ref=operators-ai.ghost.io)): your plan adds a fixed number of tokens per minute, and unused tokens expire after 60 minutes. So the bucket never holds more than your rate times 60\. On a 25-per-minute plan that's 1,500\. Every response tells you `tokensLeft`, `refillRate`, and `refillIn` (milliseconds until the next refill). `tokensLeft` can go negative, because Keepa runs any request submitted while your balance is positive. Running out returns HTTP 429\. Offer data costs extra (6 tokens per offer page on product requests), which is why offer and seller-competition pulls eat a plan alive. **Amazon SP-API** ([usage plans and rate limits](https://developer-docs.amazon.com/sp-api/lang-US/docs/usage-plans-and-rate-limits?ref=operators-ai.ghost.io)): every operation has its own rate and burst limit, usually per seller-and-app pair. A throttled request returns an error. Some operations report their limit in a response header. Read it when it's there, and don't build anything that depends on it being there. What our members do, which I'd copy: - Trickle slightly slower than the refill rate, and only allow a big burst when the balance is well above the burst size. One member bursts 800 only when they have more than 1,400. - Stop with a buffer instead of at zero, so you always have tokens for a lookup you need right now. Another member stops at around 200. - Work out the wait from the refill numbers instead of sleeping a fixed time, and do other useful work while you wait. - For live data that doesn't need history, use SP-API instead of Keepa. It's fresher and it doesn't cost Keepa tokens. The spec, as rules for your agent: 1. Read the budget from every response. Never assume it. 2. Set a floor (for example, 15% of bucket capacity). Stop pulling at the floor and record where you stopped. 3. Calculate the wait from `refillIn` and `refillRate`, not a fixed sleep. 4. Log tokens spent per run. If a run spends twice what it did last week for the same work, that's an alert. ### Part 2: Checkpoint and resume One member put it in one line: their scripts stop with a buffer and resume from the same spot the next time they run. That's the whole idea. 1. Keep a cursor: the last ASIN, order ID, date, or page completed. Store it in your database or a small file next to the job. 2. Write the cursor after each batch, never only at the end. 3. Make writes idempotent. Key every row on something natural (order ID, ASIN plus date) and upsert, so running the same batch twice changes nothing. 4. On start, read the cursor and continue. A crash, a 429, or a closed laptop costs you one batch, not the job. ### Part 3: The exception log This is the part most people skip, and it's the one that bites. My VA once mistyped an entire date column in a lead spreadsheet, and the import job carried on without complaint, skipping dozens of leads. Nothing errored. The totals just came out wrong. The member with the email-reading buy sheet had already built the fix without calling it that. When their agent couldn't match an item from an order confirmation to an ASIN, it wrote the row to an exception log. They filled in what was missing, ran the job again, and the exceptions cleared. 1. Every row that fails to parse, match, or validate goes to an exceptions table with the source row, the reason, and the run ID. A skipped row with no record of it is a bug. 2. Every run reports three numbers: rows in, rows loaded, rows excepted. In must equal loaded plus excepted. If it doesn't, the run failed, whatever the exit code says. 3. Re-runs retry open exceptions first. 4. Exceptions older than a week get surfaced to you, not buried in a log. ### Part 4: The freshness check The member whose agent caught stale inbound data could only catch it because they had a second source to compare against. Make that deliberate. 1. Stamp every row with `pulled_at` and, if the source provides one, the source's own as-of time. 2. For each source, pick a few canary records you can check by eye against the source's own screen (a shipment, an order, a price). 3. Once a week, have the job compare a small sample against the source of truth and log disagreements as exceptions. Don't let it "fix" them. Disagreement is information. 4. List the fields that have no API (for Amazon sellers, sourcing cost is one today) and make the manual bulk-sheet routine its own scheduled reminder, so a chore you do by hand still happens on a schedule. ### Part 5: The promotion path The buy-sheet question, whether to let the agent run it in production or have it write code, deserves a ladder, not a yes or no. | Stage | Who runs it | Move to the next stage when | | ----------------------------- | ----------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | | 1\. Agent, by hand | You ask the agent each time; it figures out the steps | You've run it at least three times and the steps were the same each time | | 2\. Skill on a schedule | A scheduled job calls a written skill; the model follows the steps with room for judgment | The exceptions it raises are all ones you understand, and the output should be identical every run | | 3\. Boring code on a schedule | A plain script runs; the agent only gets involved when an exception needs judgment | Stay here. Revisit only when the source changes | Stage 2 is the middle ground I recommended in the Discord: put the generalized steps in a skill and have the scheduled job call the skill. It's predictable, and it can still handle a weird email. Stage 3 is where one member has been for about five months: a push-button script that pulls their purchases from a Google Sheet into SQLite and hasn't needed a code change. In their words, they'd rather do things without the agent in the middle if they can. For a job that should do the same thing every time, that's the right instinct. ### Where each stage lives in your harness | Harness | Stage 2 (skill on a schedule) | Stage 3 (code on a schedule) | Trap | | ------------------- | ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Hermes** | hermes cron create "every 6h" "Run the buysheet ingest" --skill buysheet-ingest. Pin the model with \--model | [No-agent mode](https://hermes-agent.nousresearch.com/docs/guides/cron-script-only?ref=operators-ai.ghost.io): \--script ingest.py --no-agent. Zero tokens per run | Scripts must live in \~/.hermes/scripts/. Empty output is a silent run, so print only when something needs your attention | | **Claude Code** | Desktop **Routines**, new local task, with the model picked in the instructions box | Same, with the instructions reduced to "run this script and report the counts" | Per the [docs](https://code.claude.com/docs/en/desktop-scheduled-tasks?ref=operators-ai.ghost.io), local tasks only run while the app is open and the computer is awake. Cloud routines run with the computer off but can't see your local files, and the minimum interval is one hour | | **ChatGPT / Codex** | [Scheduled tasks](https://learn.chatgpt.com/docs/automations?ref=operators-ai.ghost.io), paired with a skill | Ask the desktop app to schedule the script run in your project folder | The CLI and IDE extension can't create schedules. The desktop app needs the computer on to reach local files. Tasks on GPT-5.5 need a new model by October 14 | | **OpenClaw** | openclaw automations create with an agent-turn payload and \--model | A [script payload](https://docs.openclaw.ai/automation/cron-jobs?ref=operators-ai.ghost.io) on the same scheduler | Check run history with openclaw automations runs . A job that delivers to "nowhere" can fail for weeks without anyone noticing | ### Hand this to your agent ``` Build an ingestion job for [SOURCE] into [MY DATABASE / SHEET / FILE]. Use the five-part spec below. Do not schedule anything yet. 1. Pull budget. Find this source's rate limit from its current docs (fetch them, do not work from memory). Read the remaining budget from every response. Stop at a floor of [15]% of capacity, record where you stopped, and calculate the wait from the refill fields. Log tokens or calls spent per run. 2. Checkpoint and resume. Keep a cursor of the last record completed and write it after every batch. Key every row on a natural key and upsert, so re-running a batch changes nothing. On start, resume from the cursor. 3. Exception log. Any row that fails to parse, match, or validate goes to an exceptions table with the source row, the reason, and the run ID. Never skip a row silently. Every run reports rows in, rows loaded, and rows excepted, and fails loudly if in != loaded + excepted. Retry open exceptions first on every run. 4. Freshness check. Stamp every row with pulled_at. Pick 3 canary records I can check by eye in the source's own screen and tell me which they are. Write a weekly check that compares a sample against the source and logs disagreements as exceptions without "fixing" them. List any fields I need that this source has no API for. 5. Promotion. Write the steps as a skill first. Run it with me three times. Then tell me whether it is ready for a scheduled skill run (stage 2) or a plain script (stage 3), and why. Show me exactly where the schedule will live in my harness and what happens if my computer is asleep. Report back: the schema, the first run's three counts, the exceptions it raised, and the canary records. I approve the schedule. ``` If it gets stuck on any step, reply and tell me where. The spec gets better every time a member's agent hits a wall. ### What not to do - Don't schedule a job that hasn't run clean by hand three times. You'll just automate the first version of your mistakes. - Don't let the agent fix data it can't reconcile. It should log the disagreement and stop there. - Don't run your biggest pull on the day you need the data. Pull ahead of month-end, not on it. - Don't upgrade the system that stores this data in the three days before you need it. Ask me how I know. **Steal this:** pick the one M line from Your move that you'd miss most, and have your agent build just Part 3 for it tonight: the in, loaded, and excepted counts. Run it once. If the three numbers add up, you've learned something. If they don't, you've found the leak you've been paying for. Hit reply and tell me what's on your bench this week. I read every one.