So I stopped comparing feature lists and started breaking things.

I built the same small agent three times, once in Python, once in LangGraph, and once in n8n. The agent is deliberately plain, so the only thing changing between runs is the tool underneath.

Then I put each one through two failures every agent meets eventually. I crashed it at the worst possible moment, and I restarted the whole tool while a run was still going. One tool brought a paused run back from the dead. Another did the same thing twice, the kind of mistake that charges a customer twice. The protection that would have stopped it was missing from all three.

My paid subscribers make it possible for me to keep running builds and tests like these.

Below, I break down exactly how I ran each failure, what every tool did when it hit them, and the one piece you have to build yourself no matter which tool you pick.

Read more

By the end of this, you’ll be able to see every step your agent takes, with a rule that stops it before it does something you didn’t approve.

You want to follow an agent through every step, so you catch a mistake the first time it happens instead of after it has cost you. In yesterday’s live, I gave you the three parts that make it possible: log what the agent read and did, trace a single run from the request to the final action, and gate the actions you’d want to sign off on, so the agent pauses for you before it runs one.

Today we’ll build the agent and add all three parts.

We’re building it on a support agent that issues refunds through Stripe. This is the same observability layer I built for my own agents at Asaura AI. The setup works the same on any agent you run.

We’ll build the agent, add the three parts, and add a rule that pauses the agent before a step you’d want to check, so a person signs off before it goes through. On this agent, that step is a refund. On yours, it might be sending an email or changing a record.

Read more

He never got the chance, so nobody in the room knew what they were missing by cutting him out.

Friday, I called this the Compounding bucket: the work that’s worth more the more your teams build. When every department can build its own tools this fast, someone has to see how those tools fit together and what each one costs the company over time. This skill gets more valuable the more your company builds. This article gives you a scorecard to measure this. You give an internal tool five scores, and it tells you what that tool will cost your company and whether you should back it, fix it, or flag it to leadership.

A tool that works today has cleared the lowest bar. It ran once, for one team, on the machines it was built on. What that tool costs your company shows up over the year that follows. Software maintenance and evolution runs to roughly 60%-80% of a tool’s total lifetime cost, and yearly upkeep alone often runs 15%-25% of what the tool cost to build. A tool a contractor builds in an afternoon costs far more than that afternoon. It brings a year of upkeep, security fixes, and support that nobody counted when they approved it.

A contractor building a tool for one department answers one question. Can I get this working for them now? That’s the right question for them to answer. Your value is answering the one their job doesn’t ask them to. What will this tool cost the company once it’s running, and does it work well with everything else your teams have built?

Read more

On yesterday’s live session, I walked through why every AI workflow at your company needs a test layer, and introduced the two kinds of evals every team using AI should run. Capability evals measure what the AI does well and where it struggles. Regression evals measure whether the AI still handles the outputs your team already relies on. Together they answer whether the AI is safe to use, and whether the work you’re putting into improving your processes is paying off.

Today I’m giving you the entire testing system. A workbook with both tests (capability and regression) already set up, so you can drop your test cases straight in. A starter list of 21 conditions an AI output can be required to meet, sorted into six categories, that your team can copy from and adapt to your workflows. An AI grader prompt that scores each output against each condition, so one person can run both tests in the time it used to take to manually review a single output.

Here are some recent popular articles you may have missed:

➡ A four-artifact workflow for calculating AI ROI in a format your CFO will approve, built in 90 minutes.

➡ The intake form, screening guide, vendor checklist, and documentation workflow every enterprise AI project now runs through under U.S. state AI regulations.

Read more

Today’s build turns that definition into a working system you can copy.

A multi-agent system is an AI setup where one agent coordinates the work of two or more other agents to finish a job. The coordinating agent is called the parent. The agents it coordinates are called subagents. The parent decides which subagent handles each part of the job, reads each subagent’s output, and either combines the finished outputs into a final result or sends a subagent back with a narrower request if the output isn’t specific enough.

The reason to use a multi-agent system instead of one large agent is that each subagent gets to focus on a single task with its own instructions. That focus produces better output than asking one agent to keep every task in its memory at once. It also means the parent can send two subagents off to work at the same time, which gets the job done faster than doing every step in sequence.

The build below turns this diagram into a working system on your machine.

What it includes: the three files you can copy directly into your own setup, a step-by-step walkthrough of a live run with every part of the system labeled inside the transcript, the follow-up request that shows the parent agent adjusting its next step based on what came back, and a set of concrete swaps for adapting this pattern to other recurring jobs your team runs every week.

Here are some recent popular articles you may have missed:

➡ An n8n agent that reads your live metrics and reports them every Monday morning, grounded in a real spreadsheet so it stops inventing numbers.

➡ A four-artifact workflow for calculating AI ROI in a format your CFO will approve, built in 90 minutes.

➡ The intake form, screening guide, vendor checklist, and documentation workflow every enterprise AI project now runs through under U.S. state AI regulations.

In a few minutes, you’ll have a working multi-agent system running. Let’s build it.

Read more

That decision fits on one page. I call it an Exit Map. Down one side you list the kinds of data your company works with. Across the top, where each kind is allowed to go, whether that’s a personal AI account, your company’s approved account, or no AI at all. Public marketing can go anywhere. Internal documents go only to the company account. Send confidential client data and credentials to no AI at all.

I went through this live yesterday. You can watch the full episode here.

Deciding is the easy part. The hard part is making your tools obey that decision. The settings that do it are inside each platform’s admin area, and few teams switch them on.

Do this and your team keeps the AI they want, your confidential data stays in-house, and when your annual review comes you can show which kinds of data your team may send to an AI tool, and which never go near one. Below, I walk you through that setup for both Claude and ChatGPT, one row of your Exit Map at a time. Upgrade to get every step. By the end, your team’s AI tools will be locked down so your private data can’t slip out, and you’ll have the records to prove it if you’re audited.

Read more

Yesterday’s live session opened with a diagram from a 2015 Google paper called ‘Hidden Technical Debt in Machine Learning Systems’. That paper made an argument that changed how teams build with AI: writing the model is the fast, cheap part. Running it inside a company, and keeping it working over time, is where the cost and the risk sit. By the authors’ own estimates, a mature AI system is around 5% model and 95% that surrounding infrastructure.

That 95% is where AI projects fail, and it’s what you get asked to approve as a leader, even though it’s the hardest piece for a non-technical person to assess. So on the live, I gave you a way to break any AI project into five layers, and for each layer, the one question that tells you whether it’s a good investment or a risk. Together, the five answers show you where a project is strong and where it will cause trouble, before you commit budget or scale it. Those five layers are model, compute, data, orchestration, and governance. Work through them in order, and you can sit in a leadership meeting and say, with evidence, which layer is ready and which one needs work before the company invests further.

If you missed it, watch the recording here. It includes a link to the deck and the Google paper. This article picks up where that session ended.

What you’re building today

On the live, you learned how to read an AI project across the five layers. Today you turn that into something you own. You’ll build a Claude Project that takes about 30 minutes of notes from a working session with your team and returns a leadership-ready assessment that shows where the project is solid, where it’s exposed, and what to resolve before you scale. Build it once, and you reuse it on every AI project after this, without relearning the framework or writing the assessment yourself.

Below this line is the full build. You get the questions to work through for each layer, the scoring system that shows where the project is solid and where it’s exposed, the instructions you paste into Claude to set the tool up in 10 minutes, and a worked example that turns one messy set of notes into an assessment you could put in front of your CEO that same afternoon.

Read more

It’s more difficult than it seems because no one documented the costs of running a workflow before the tools were introduced, leaving you without earlier figures to compare today’s performance against. Usage goes up, people report saving time, but none of it converts into dollars anyone can put in a budget.

This article gets you that figure for one workflow, and gets it accurate enough to put in front of your finance team.

The method is a Friction Ledger, which is three columns you fill in for a single workflow before you spend anything. Column one is frequency, which is how many times a week the task happens. Column two is proximity to cash, which is how many steps sit between that task and cash entering or leaving your company. Column three is handoff cost, which is how many minutes a person spends on the output after your AI produces it. Column three decides whether the workflow returns dollars or costs them, because every minute your reviewer spends is a minute subtracted from what the AI saved.

Thursday’s live session ran that through a worked example. You can open the slides I used for that here.

Getting from the method to your own figure takes about 90 minutes, spread across a week.

Every workflow has a review time above which it costs your company more than it returns. Cross that line and your AI spending is a loss, however good the tool is. Almost nobody knows their own figure, and one formula produces it in under a minute.

The rest of this article gives you four things:

1. A spreadsheet with the break-even formula already in it, where you enter your own workflow’s numbers and read the annual return off the bottom.

2. Nine questions to ask the person who usually manually runs the workflow, so your timings come from watching rather than remembering.

3. A prompt that turns those numbers into a one-page summary you can send to your finance team.

4. Six slides you can copy for the meeting where leadership decides whether to keep paying for your AI tools.

Read more

First, the four regulations reshaping enterprise AI in 2026:

• The June 2nd federal executive order on frontier model pre-release review.

• State-level frontier AI laws, led by California TFAIA and New York RAISE.

• State-level automated decision-making laws, led by California ADMT, Colorado SB 26-189, and Texas TRAIGA.

• Federal procurement guidance from the White House Office of Management and Budget.

Second, why enterprise AI adoption is no longer a software-access problem. The review functions your company already runs still apply, but each one now has to evaluate categories of exposure that traditional enterprise procurement was never designed to handle.

Third, the four Adoption Gates every AI project now clears before deployment: vendor selection, use-case screening, monitoring, and documentation.

Fourth, three practical steps to prepare: build a use-case intake before you build any pilot, ask vendors for evidence instead of assurances, and reduce your company’s dependency on any single AI vendor’s release schedule.

📌 A quick note before we start. My paid subscription price is going up at the end of day July 31st from $5/month or $50/year to $10/month or $100/year. If you upgrade before then, or if you’re already a paid subscriber, you’ll stay at the current price for as long as your subscription remains active.

What this piece gives you

The live gave you the framework. This piece gives you the workflow.

By the end, you’ll have six artifacts your team can install this week:

• A one-page use-case intake form.

• A screening guide that maps every AI project to the specific state laws that apply to it, across the seven U.S. states with active or upcoming AI regulations.

• A vendor evidence checklist covering eleven categories of documentation your legal team should require before any AI vendor evaluation begins.

• A monitoring log schema your data engineer can implement without additional infrastructure.

• A documentation template designed to survive a regulatory audit.

• A build order that shows your team how to put all five into place, in the sequence that saves the most rework.

Read more

Today, you’re going to be that someone. You’re going to build the thing Microsoft and AWS charge millions for, at your own desk.

What you’re building

By the end of this build, you’ll have a working, autonomous agent that watches your team’s support intake queue in Notion, reads a written playbook for how your team already answers common questions, drafts a response in your team’s voice, and hands that draft to a person for approval before anything goes out.

It checks the queue every 30 minutes on a set schedule; no one has to open a chat window and trigger it. I set mine to check only during work hours, since a person still needs to be around to review what it drafts, but you can widen that window to whatever hours your team covers.

I ran this against my own company’s queue, and every screenshot in this piece comes from that run. My team gets a handful of the same questions from new users, over and over. That’s the type of request this build is for.

You’ll use Claude Code to run the agent, and Notion to store incoming requests and the playbook that agent follows. If your team tracks requests somewhere else, the same setup works with whatever you’re already using.

Read more

That decision happens dozens of times a day. Every ticket follows the same steps and uses the same types of information, even though the tickets themselves are different. High volume and a repeatable process are what make a decision a good candidate for AI to handle.

Every team has decisions like this. Support triage. Sales escalation. Refund reviews. Vendor evaluations. Once you can name these decisions, you can build AI tools that handle the parts that don’t need human judgment.

The way you identify these decisions on your own team is a 4-step audit. Recognizing these opportunities shows your team’s proactive approach and builds confidence in your ability to leverage AI effectively.

Step one names the decision that recurs.

Step two names who does each step today.

Step three names the information each step needs.

Step four circles the steps an AI model could handle.

Those four steps together give you a clear specification you can hand to your Revenue Operations team, or use to build the tool yourself in Claude Projects, empowering your team to innovate and improve efficiency.

Subscribe now

What’s below

The full audit walkthrough applied to customer support triage. A worksheet template you fill in for any decision on your team. The four outputs of a completed audit, and what each one tells you about the tool to build.

Then the Claude Project: the system prompt with six triage criteria, three sample tickets to calibrate the criteria before you connect anything, the connector setup for your support inbox and CRM, the approval flow that keeps a person in the loop until your team trusts the scoring, and four other decisions you can adapt this same setup to inside your team.

Setup takes about an hour once you’ve picked the decision you want to automate. If a support team of five is spending 45 minutes per day each on manually triaging, this build gives them back about 18 hours a week combined. That’s roughly half a full-time work-week of hours, returned to the work your team does best.

Read more

She didn’t have to search for the trend herself.

That advertiser’s workflow is one example of what Pinterest changed in June. The same pattern is rolling out across its advertiser tools, and operators outside ad-tech should look closely at how Pinterest is using its data to take repetitive analysis off the human side of the workflow.

What Pinterest Shipped a Week Before Cannes

On June 17, Pinterest announced four AI products ahead of Cannes Lions: Business Assistant, Pinterest MCP, a new Performance+ creative model, and Ask Pinterest. The announcement reads like an ad-tech story. Underneath the ad-tech framing, Pinterest is using a decade of taste and intent data to automate the analysis and selection work advertisers used to do themselves.

In the announcement, Pinterest’s Chief Business Officer Lee Brown said, ‘The future of discovery won’t be driven by keywords alone. It will be shaped by context, taste, and trusted recommendations.’

Users don’t want to type queries anymore. They want the platform to already know what they’re looking for, and Pinterest is rebuilding its advertiser tools around the same idea.

Subscribe now

Which Advertiser Decisions Pinterest’s AI Now Handles

Each of the four products replaces a task someone on the advertiser side used to do manually.

• Business Assistant automates the trend monitoring a campaign manager used to do by scanning dashboards.

• The Performance+ creative model automates the asset selection that a creative lead used to do through A/B testing.

• Pinterest MCP gives an agency analyst direct access to Pinterest campaign data and analytics from inside the analyst’s own working tools, instead of having to log into Pinterest separately to pull the same numbers by hand.

• Ask Pinterest automates the multi-step planning a shopper used to do across several searches.

The people doing the work stay in place. What changes is the part of the job they spend time on.

A campaign manager defines what a winning campaign looks like and reviews the recommendations Business Assistant surfaces. A creative lead sets the brand voice and approves which AI-selected variant runs. An agency analyst advises the client using insights MCP delivers automatically. The strategy and judgment stay with the human. The retrieval, comparison, and selection now sit with the model.

Advertisers spend less time on retrieval and comparison and more time on strategy, judgment, and client relationships.

Subscribe now

Why This Matters for the Team You Run

Pinterest spent two years building infrastructure to automate the repetitive analysis its advertisers used to do themselves. The Performance+ model improved click volume by 7.5% in Pinterest’s own testing. Pinterest MCP is letting agencies like PMG, Pacvue, and Omnicom’s Jump450 plug Pinterest insights directly into their AI workflows.

The pattern is borrowable. The technology is open. Pinterest MCP runs on the same protocol your team can run.

Technology is the easy part. The harder part is auditing your team’s decision flows in enough detail to see which steps an AI tool could handle on its own. Without that audit, applying AI to your team stays abstract.

Many operators can name three or four obvious time sinks. Status meetings. Slack triage. Pulling numbers for the weekly review. Those are the symptoms a team sees.

The deeper layer is the work nobody tracks. Context switching. Re-reading yesterday’s threads to remember what was decided. The seven-minute Slack derail that costs forty minutes of regained focus. The constant low-grade pattern-matching across dashboards that no one would call work but everyone does anyway.

Until a team can name those untracked tasks specifically, no AI tool can handle them. The audit has to come first.

In case you missed last week’s Data Letter sprint, it covered the same problem from a different angle. Samsung is rolling out ChatGPT, Gemini, and Claude to all 260,000 of its employees and measuring the rollout by full-time-equivalent.

• Samsung Gave 260,000 Employees AI. Few Will Use It Well. explains why access to AI doesn’t change how the work gets done.

• Build the AI Scoring System Samsung’s 260,000 Employees Aren’t Getting is Wednesday’s live recording, where I built a working scoring system from scratch.

• I Built an AI Lead Scoring System That Reads My Inbox and Writes to HubSpot. Here’s How. is the full implementation guide: the Claude Project setup, the system prompt, and the HubSpot connector flow.

One Thing to Try This Week

Pick one decision your team makes every week. Something like ‘which support tickets get escalated this morning’, ‘which leads sales should prioritize, or ‘which marketing campaign deserves more budget this week’. The decision should recur often, have a clear input, and produce a clear output.

For each step in that decision, write down two things: the person who currently does the step, and the data or context they pull to do it. For a ‘pipeline coverage review’, for example, the person is the sales manager and the data is the current week’s deal stages from the CRM.

Many teams find that around 60% of the cognitive effort involves retrieval, comparison, or pattern matching. Work an AI tool can do faster than a tired manager at the end of the week.

If an AI tool handled the 60% that’s retrieval and comparison, the hours your team spends on that work would free up for the 40% that requires judgment, strategy, and client time.

Pinterest finished that audit for its advertisers two years ago. The same exercise is overdue on many teams.

Next Step

This Thursday, July 2nd, I’m going LIVE to walk through how AI is redistributing cognitive labor across organizations. What the pattern looks like, where it’s working, and the framework operators can use to map their own teams.

On Thursday, I’ll release the full build: Map Where Your Team’s Mental Energy Goes, and Build an AI to Redistribute It. The Pinterest story above explains why this redistribution matters. Thursday’s build walks through a full example: a team’s weekly decision flow, the audit that identifies the 60%, and the AI tool built to handle it. You can run the same approach on your own team’s workflow.

Subscribe now

The way Samsung plans to measure whether the rollout works is the part of the story every operator and manager needs to understand, because every other large enterprise AI rollout has hit the same wall: access without a system for using that access well.

What Samsung Just Did for 260,000 Employees

Samsung Electronics has around 260,000 employees globally. By the end of 2026, every one of them will have access to ChatGPT, Gemini, and Claude. The DX Division, which builds phones, TVs, and home appliances, gets access first. Every other Samsung subsidiary, from Samsung Display to Samsung SDI to Samsung Biologics, follows after.

To get there, Samsung is running a top-down training program. About 50 senior leaders are training first. 2,300 executives follow through August. Then everyone else, in waves, through the rest of the year.

The metric Samsung is using to measure whether the rollout worked is full-time equivalent, or FTE. One FTE equals one person working a 40-hour week. Samsung will measure AI success by how many people’s worth of work a single employee can do with AI. If a marketing manager using ChatGPT produces what used to take three people, that’s a 3.0 FTE.

Samsung is the first of Korea’s four largest business groups, called chaebols, to fully adopt external AI tools across all its companies. The other three are SK, Hyundai, and LG. Together, these four groups account for a large share of Korea’s industrial economy. Whatever Samsung does, the other three watch. Whatever Samsung measures, the other three are likely to measure too.

The FTE metric is worrying some Samsung employees, who said AI adoption ‘could be perceived as a measure for ultimately determining how many jobs can be cut rather than being used as a means of improving work efficiency.’

Here are some recent popular articles you may have missed:

I Built an AI Agent That Sends Me My Numbers Every Monday Morning → A step-by-step n8n build for an AI agent that reads your live metrics, remembers context, recovers from failures, and runs on its own every Monday.

Build Your Own Local AI Stack: A Session on Models, Hardware, and Quantization → How to choose an open-weight model that fits your local machine, runs without a cloud subscription, and can’t be shut down by a vendor.

3 Pieces of Free Software That Install a Private AI → The full step-by-step build for a private AI on your laptop in under an hour. Free, offline, yours.

I sat down with for her Career Pivot Playbooks series to talk about how I got from data science to building AI for productivity. Read the interview here.

Why Giving Employees AI Doesn’t Change How Work Gets Done

Samsung’s rollout is the largest one announced this year. It isn’t the first to hit the same problem.

In May, Marc Benioff said on the All-In podcast that Salesforce will spend $300 million on Anthropic tokens this year, primarily for coding. He described the efficiency gains across service, support, and marketing as ‘unprecedented.’ Salesforce’s support team went from 9,000 people to 5,000 over the past year as AI agents took over more of the work.

Later in the same interview, Benioff said Salesforce still needs a smarter routing system to connect its employees with the models they use. Right now, every request from an employee goes to the same top-tier model.

Benioff said simpler requests should be sent to smaller, cheaper models, and only the complex ones should reach a frontier model like Claude. Salesforce is spending $300 million a year on Anthropic, and the routing system Benioff wants doesn’t yet exist at his company.

Two weeks before this appearance on the All-In podcast, Microsoft started canceling Claude Code licenses for the engineers who build Windows, Microsoft 365, Outlook, Teams, and Surface. The cancellations will finish by the end of June. The official reason was that Microsoft wanted to consolidate its own GitHub Copilot CLI. The reason underneath was cost. Claude Code usage at Microsoft grew faster than the team’s budget could absorb.

Subscribe now

Each of these companies invested heavily in access to AI. None of them built the system that sits between the employee and the model and decides what the model should be asked to do, with what inputs, and scored against what criteria. That system is what’s missing. Without it, $300 million in token spend produces uneven output. Without it, access to frontier models becomes a budget problem. Without it, 260,000 employees with three AI tools each will fall back to the few uses they already know.

What a Scoring System Is

The operators I work with don’t ask the model to make the decision. They write down the criteria a good decision would meet, hand the model those criteria, and ask the model to score the option against them.

Let’s take a simple example: qualifying inbound sales leads. A new lead arrives through a contact form on your website. The sales manager writes down what makes a lead worth a call: job title fit (30 points), industry match (25), company size (20), intent signals in the message (15), tech stack overlap (10).

Each lead gets scored out of 100. The model reads the lead, scores it against the criteria, and returns the number, a tier (hot, warm, cold), and a written explanation of how it arrived at the score.

The sales team trusts the output because they can see exactly how the model arrived at the number, and they can change any single point value within 30 seconds if they disagree. The model applies the same scoring across hundreds of leads a week, faster than any one person could.

The same scoring approach works for almost any decision your team makes regularly:

• Evaluating vendor proposals

• Triaging customer escalations

• Reviewing inbound resumes

• Flagging unusual expenses

• Prioritizing bug reports

A scoring system is what your team would write down if they had unlimited time to document how they make these calls. It’s the criteria, the point values, and the explanation requirement, written down once and applied consistently thereafter. AI handles the volume. Your team keeps control over the criteria.

Samsung’s training program covers how to use ChatGPT, Gemini, and Claude. From everything Samsung has announced publicly, it doesn’t cover how to build the system that turns those tools from a chat window into a decision engine the team can trust.

Subscribe now

Your Next Step

Two days is how long it’ll take you to build the system that Samsung’s 260,000 employees aren’t getting.

This Wednesday at 8:30 AM EST, I’m going live on Substack to build a working scoring system from scratch. Here’s what I’ll be covering:

• How to take the way your team already makes a decision and turn it into a written scoring system

• The structure of a scoring prompt that returns a usable number every time

• How to write the explanation field so your team trusts the output

• What to do when a domain expert on your team disagrees with the model’s score

• Why a short, plain scoring system outperforms a complicated AI agent

Thursday’s article is the full implementation guide of what we built on the live. Every line of the scoring prompt, the workflow setup, the structured output format, and the integration into your existing tools.

By the end of this week, you’ll have a working scoring system running on your team’s own decisions, in your own tools, with your own criteria. You’ll be the person on your team who built it.

Subscribe now

The second is the one a smaller group has already started: what does our team own, and what runs regardless of whether others are having an outage today?

This article is for people moving into the second conversation. The full step-by-step build for a private AI on your laptop in under an hour. Free, offline, yours.

Read more

Some people spent last week building with Fable 5, but you’re the person on your team who already runs AI tools locally, so a frontier model going down didn’t affect you.

For those of you who aren’t this person or that team yet, this was hopefully the wake-up call you needed to start owning more of your AI stack.

The good news is that the tools you need to build with are free.

Work through the builds below in order, or pick whichever sounds closest to what you’re working on this week.

Subscribe now

Run a model on your own machine

n8n. local. A private AI agent on your laptop, no API keys.
How To Fine-Tune and Deploy an LLM Without an ML Engineer. A support assistant grounded in your own docs, running locally.

Use it on a recurring job

I Built an AI Agent That Sends Me My Numbers Every Monday Morning.
Build a RAG System with NotebookLM in Under an Hour.
Build Your Own AI Productivity App with Codex.

Give it memory so it stops losing your context

I Built a Second Brain to Help Me Run My Company.
Every Time You Start a New Chat, You Lose Everything. Here’s How I Fix That.
How We Use Agentic AI to Help Us Make Big Product Design Decisions.
How to Use AI to Do the Executive Function Stuff Your Brain Skips Over.

What this means for how work is changing

AI Agents Are Redesigning Workflows. Your New Skill Is Staying in Motion.
Agentic AI Matters More to ADHD Brains Than Getting Faster Answers.

This week on The Data Letter: Wednesday’s live session is free and open to everyone. We’re going deep on local model selection, hardware sizing, and quantization, so you walk out knowing which model fits your machine.

Three pieces of free software install a private AI on your laptop gets published Thursday, with the full build ready to deploy.

Read it here:

Every build I’ve published over the past few weeks has given you one piece of this. The local agent build put a private model on your laptop with n8n, Ollama, and Docker. No API keys necessary. The Monday metrics build taught the agent to answer from wherever you’re storing your data instead of inventing numbers, and to say ‘I don’t have that’ when the answer wasn’t there. The RAG build in NotebookLM showed how retrieval lets a model answer from your documents. The prompt engineering piece made the case for treating your system prompt as an asset, versioned and tested, not a throwaway string.

Today, those pieces become one thing you own: a support assistant that runs entirely on your own machine, answers from your team’s documents, speaks in your team’s voice, and refuses to make things up. This is the same system I built for Asaura AI. You’ll build your version of it in the next half hour, for free, and when you’re done, the model is yours. No vendor update can take it out from under you, because no vendor is in the loop.

Below the paywall is the complete build, every step from an empty workflow to a working assistant you’ve tested and trust, plus the downloadable files ready to paste in.

Read more

Then the vendor shipped a new version.

And the thing that worked last quarter started returning garbage.

Last month, my friend, an operations leader named Priya, messaged me. Her team had settled on an AI model, built it into their support workflow, and shipped it. A few weeks later, she wrote again: ‘It started giving us garbage, but nobody touched the code. What do you think is going on here?’

She’d asked the questions everyone asks up front: Which model is best? ChatGPT or Claude? Which one’s cheaper? She hadn’t asked the question that decides whether a model keeps working: what happens when OpenAI or Anthropic releases a new version.

She started worrying three weeks in. You should start on day one.

In case you’re new here, here are some past TDL articles you may have missed:

• I Built an AI Agent That Sends Me My Numbers Every Monday Morning → A step-by-step n8n build that takes an agent from inventing your metrics to reading them from a live Google Sheet, remembering context, recovering from failed steps, and reporting on its own every Monday, all running free on a local model.

• Prompt Engineering.: Treating LLM Prompts as Software Assets → Why ad-hoc prompting breaks once three engineers touch the same string and a model update degrades your outputs; and, how versioning, structured evaluation, cost tracking, and drift monitoring turn prompt management into a boring, solved problem.

• n8n. local. → A 30-minute build that gets a private AI agent running free on your own laptop with n8n, Ollama, and Docker, no API keys and no model weights leaving your machine, ready to take on a recurring job your team already does.

Version churn is the breakage nobody prices in

When a vendor ships an update, the model starts behaving differently.

When the company that makes your model releases a new version, the same prompt and settings you tested can start returning answers in a different format, or skipping details it caught before. Operations leads and analysts have watched a support classifier that sorted tickets cleanly on one version start mislabelling them on the next. A model that read a 40-page contract end-to-end last quarter now skips the middle pages and summarises only what it saw at the beginning and the end.

You changed nothing in your code. The vendor changed the model, and your results changed with it.

So the question worth asking is how the model behaves when OpenAI or Anthropic updates it on their schedule.

That question rarely comes up before a team commits.

Subscribe now

Cost is the same trap wearing a different coat

Breakage has a financial twin: the bill.

Token billing means your spend scales with use, and use scales the moment the workflow works, and the team starts to depend on it. Operators report the bill arriving like a surprise, because the thing that made the tool valuable, everyone using it, is the same thing that made it costly.

Both fears come from one root:

You committed to a model without a way to judge what you were committing to.

How Experienced Operators Pick a Model They Can Trust for a Year.

Experienced operators care less about which model is cleverest and more about which one they can rely on month after month. They’ve learned that the model that scores highest on a benchmark today isn’t always the one that still sorts your support tickets correctly after the vendor updates it.

They choose durability over dazzle.

The model that tops the benchmark this week and the model still working in your stack a year from now are often two different models. You learn which one you’ve got by running it on your own work, watching what it costs as your team uses it more, and seeing how it behaves when the vendor updates it next.

Subscribe now

Your instinct is right. The framework is what’s missing.

So your hesitation looks like timidity. It’s good judgment, you just don’t have a way to act on it yet.

The teams that commit fastest are often the ones who get stranded, because they chose on capability alone and never asked what happens when the vendor updates the model. The teams that hesitate are right to fear getting locked into a model that breaks; they just have no structured way to test for it.

What you need is a way to test a model before you commit, one that weighs how it handles vendor updates, what it costs as your team uses it more, and how narrow the job is, rather than how impressive its answers look in the first demo.

So this week I’m walking through the choice live, in two parts.

Wednesday, June 10th, 8:30 AM EST, live: Pick an LLM You Won’t Regret. I’ll walk through a clear set of checks for choosing a model. How to read a version string so you know what you’re committing to, what a model costs as your team uses it more, and whether your task is narrow enough to catch a bad answer fast. You’ll leave with a way to choose instead of a guess.

On Thursday, we’ll go one level deeper, into the answer that takes the update schedules of OpenAI, Anthropic, and Google out of your hands for good: Fine-Tune and Deploy an LLM Without an ML Engineer. You decide when to update, instead of waking up to a vendor’s change you didn’t choose. Your weights, your control, start to finish.

Wednesday tells you which model to trust. Thursday hands you the build where you stop living by a vendor’s release calendar.

Choose the version after this one, not the demo in front of you.

Subscribe now

I showed this on my weekly live session yesterday morning (Every Wednesday at 8:30 AM EST). I built a small AI agent in n8n whose only job was to answer questions about my startup’s weekly metrics. I asked for last week’s churn rate. It gave me a number, a cancellation count, even a quarterly comparison. All of it was invented. It never once looked at Asaura’s user data.

An agent like that doesn’t crash or flag a problem. It hands you a wrong answer that looks just like a right one, and you don’t catch it until someone manually checks. The fix is a set of techniques that make an agent read from a live source, remember what it’s doing, recover on its own when a step breaks, and run on its own.

In case you’re new here, are some recent articles you may have missed:

Code w/ Claude: 5 Data Science Trends I’m Watching → Five shifts coming for the data scientist role by 2027, from treating model upgrades like dependency bumps to curating memory the way we curate feature stores.

Build Your Own AI Agent Before Google Ships You Theirs → Why Google’s five overlapping consumer agents don’t fit a small ops team, and how to put one working agent on one recurring job this week instead.

Build a RAG System with NotebookLM in Under an Hour → A hands-on build that gets you a private RAG running on your own documents, plus the ten engineering terms you’ll need to lead any AI conversation at work.

Build Your First AI Data Pipeline in Python: From Raw CSV to Predictions → A step-by-step scikit-learn tutorial that turns vehicle data into CO2 predictions and teaches you to read your model’s metrics honestly, even when the answer is that your model is useless.

Today’s build is the next one in this series.

This guide builds that agent from scratch in n8n, step by step. You’ll start with a simple agent running on a local model. Then you’ll connect it to your live metrics, give it memory, make it handle failures, and schedule it to report on its own every Monday (or whichever days you pull your numbers). It runs entirely free.

Read more

Whose model scores highest? Whose benchmark beat whose? Who topped the leaderboard this week?

Model. Model. Model.

But inside your company, model IQ isn’t the thing hurting you.

Your agents pile up. Forget what they were doing. Snap the second one step downstream fails.

I keep seeing the same fear surface, even in seasoned teams: ‘We shipped the agent, so why does it keep breaking??’ Because building one and running one are two different jobs.

To be clear, I’m not anti-agent. I build them. I run them.

The trouble starts when everyone treats the model as the finish line and forgets the pipes underneath.

Here are some recent TDL articles on AI agents and orchestration you may have missed:

• On the orchestration layer, and why it decides who gets leverage from cheap models: 'NVIDIA and AI Inference Economics in 2026.'

• On building your own agent instead of waiting for a vendor: 'Build Your Own AI Agent Before Google Ships You Theirs.'

• On the step-by-step build: 'n8n. local.' A private AI agent running on your own laptop in about 30 minutes, using n8n, Ollama, and Docker.

• On grounding, the thing that keeps an agent from making things up: 'Build a RAG System with NotebookLM in Under an Hour.'

• On reading a model honestly before you trust it: 'Build Your First AI Data Pipeline in Python.'

  ---

Why Reliability Beats Model IQ

So the contest is about reliability now.

When every vendor ships a frontier-class model, the model stops being worth fighting over. So the fight climbs one floor up. To the layer that decides which agent touches which system, gives each one an identity, logs what it did, and shuts it down when it misbehaves.

This is the control plane. The plumbing for a building full of agents.

Subscribe now

Microsoft and Google Build the Agent Control Plane

Watch the giants. They’ve stopped pretending it’s about the model.

Last November, Microsoft shipped Agent 365 and named it ‘the control plane for AI agents.’ Registry, identity, security, the works. A place to govern every agent, whoever built it.

Then, in April 2026, Google launched the Gemini Enterprise Agent Platform. Build, scale, govern, optimize. Agent Identity. Agent Registry. An Agent Gateway they call ‘air traffic control for your agent ecosystem.’

Read the two feature lists side by side.

Registry. Identity. Governance. Gateway.

Two rivals, working apart, are using the same vocabulary to describe their products.

When competitors employ identical marketing language, they’re telling you where they think the market is headed.

And the prize they’re naming is the plumbing.

Accenture argued that Agentic AI is becoming the interface across your platforms, orchestrating work in real time. The agent sits on top of finance, the CRM, and the supply chain, and runs across them.

Whoever owns that orchestration layer owns the customer.

Subscribe now

Reliability Problem Behind AI Agents

The first wave of agents is breaking in the field.

VentureBeat reported last month that teams are entering what one engineering leader calls a rebuild era. They rushed agents out, skipped the underlying plumbing, watched them crash, and went back to rebuild on a solid base.

Her words: ‘They had to move really fast, but they didn’t take care of the plumbing. Things crash and burn.’

Crash and burn.

Independent benchmarks back her up. Researchers found that for long-running tasks, the same agent can produce different results on each run. It finishes the job cleanly one day and falls apart the next.

In one benchmark, agents ran a small vending-machine business over many days. Some lost track of the job entirely and began sending angry, irrational emails to suppliers over a one-dollar fee.

So buyers care less about which model is smartest. They want to know one thing: Can I trust this to run, recover when it fails, and tell me what it did?

Subscribe now

What Agent Platform Wars Mean for Your Team

Maybe you govern ten thousand agents. Maybe you run three workflows that your team relies on every morning.

Same problem at either size. No orchestration. Context that drops halfway through. No way to recover when one step fails. Same lesson, your scale.

The takeaway: reliability comes from how you build, not how much you spend. The giants pay billions for it. You can build the same habits into one workflow on your own. Do that, and it keeps running when a step fails instead of crashing.

Ok, in closing.

The giants are spending billions to own their plumbing.

You can fix yours this week.

This Wednesday, June 3rd, 8:30 AM EST, I’m going live on Substack again: ‘Why AI Workflows Break (and How to Fix Yours Before It Costs You).‘ We’ll pull apart why these systems fail and what a steady one looks like.

You can read the follow-up to I Built an AI Agent That Sends Me My Numbers Every Monday Morning,’ is the system that fixes it, and it is walked through so you leave with one running.

A smarter model won’t save a workflow that keeps breaking. Build the system that keeps it running.

Subscribe now

Operations teams want one working agent on one recurring job this week that they own end-to-end. Google has options on both ends of the spectrum (consumer apps like Gemini Spark and enterprise platforms like Gemini Enterprise). Neither is built for a small ops team looking to operate a recurring task.

Today, we build that agent.

In the next 30 minutes, you’ll have a private AI agent running on your own laptop. It costs zero dollars. No model weights leave your machine. Once the basic loop runs, plugging in a tool turns the agent into something that handles jobs for your team, such as drafting replies in your support inbox, pulling a number from a spreadsheet on a schedule, and triaging incoming customer support requests.

Subscribe now

What you’ll find inside this post

• The full step-by-step setup

• A downloadable n8n workflow file.

• The setup errors you’re likely to hit and how to fix each one.

• Three ways to put the agent on a job your team already does.

• A video walkthrough of the finished agent

Read more