Field notes on connecting systems, mapping data, and getting integrations live without the six-month "big reveal."
I tried to stop my AI agent from changing its own deployment with a rule in the sync layer. It failed its first test. Then I made the same mistake again with push tokens. Here's what finally held, and the rule I use now: contain the code where it runs, then test it by trying to get past it.
I moved every app I run to GitOps in a week. Three things broke: a pipeline wrote a bad image digest, a manifest without a namespace deployed to the wrong place, and a namespace move left every app with an empty volume. Here's what caused each one, the fix, and the checklist I'd use next time.
I asked the agent that runs on my Mac mini to compare the platform it lives in against Lovable, Replit, Abacus.AI, and the rest. The hosted builders win on time-to-first-app by a mile. What I get back is ownership, an audit trail, and an agent that can't widen its own permissions.
In August, the rule was that the website doesn't hold the chat credential. This week I found out the same rule applies one level up: the agent that builds and deploys this site shouldn't be able to deploy itself. I had a lock for that. It didn't hold.
The proxy we built to replace a legacy system safely saw every request and every response that system ever handled. We used that to diff old against new. I've started to think it was the more valuable thing we built.
Rejecting 'AI Native' as the wrong word was easy. Anyone can do that in one blog post. What's harder: saying what actually replaces it. Turns out Good Strategy / Bad Strategy already named the move — and the fix.
A phrase keeps showing up in AI strategy conversations: 'AI Native.' It's borrowed from a much older idea — the one that already decides who counts as a native speaker of a language — and I don't think it survives the trip.
The shadow-proxy trick that made a 150-endpoint migration boring depended on one assumption: that URI, header, or method told you what a request was for. SOAP doesn't give you that. Every operation looks identical until you open it.
"What have we done to ourselves? I'm logged in the second I walk into the office after scanning my badge at the door, and I'm still tired of logging into so many apps." The feeling is right. The reason isn't laziness — it's that a badge only ever had one kingdom to trust.
The contact form used to save messages to a file nobody checked. Getting a notification into chat looked like a one-line fix — give the website a chat credential and let it post. That's exactly the fix we didn't make.
A batch of invoices came in with thousands that didn't match anything in the system. I don't know what actually happened internally during the platform migration behind it. I have a hypothesis, and I want to be honest that it's one.
RSS already did everything the open social web needed. It didn't lose to something better. It lost because nobody could sell ads against a feed the reader controlled. MCP is about to learn the same lesson, and most agent tool-calling doesn't need it in the first place.
Everyone knows the lesson: don't fly too close to the sun. Almost nobody asks what the opposite lesson is, or what the story looks like from the other character's side. That second reading is more useful than the first, and it's the same reading most people aren't doing with AI either.
The same four concerns keep coming up whenever someone asks about the threat model for running coding agents with production-adjacent access. My instinct was a radar chart — everything pulling against everything else. Checking each concern against a real framework changed my mind about the shape of the problem.
I keep saying leaders should ask how AI can alleviate their engineering bottleneck. Right now, on my own project, more engineering wouldn't move anything forward at all — and that's the more useful thing to notice.
13,000 invoices arrived. About 2,000 had no match, and the page listing them froze solid a few hundred rows in. The obvious lesson is that dev data was too small. The real one is sharper — asking the right question up front wouldn't have saved this either.
A widely discussed piece this week argued that AI agents make abstraction layers less necessary — let them work close to raw implementation instead of through the layers we built for ourselves. I have eight recent, real counterexamples in one codebase.
We scheduled a call to make one network change. The person who joined was late. The person authorized to actually make the change wasn't on the call at all. We waited thirty minutes before the RISE liaison told us the earliest they could get him was 10 PM Central.
Right before it clicked, I was flailing — a regex that kept matching phone numbers, no forward motion. Then I stopped asking whether to use the model and started asking which stage actually needed one. What happened in the room afterward is the part worth writing down.
OpenAI's training agents spent ten weeks quietly coordinating with each other before breaching Hugging Face. Run the incident through two aerospace failure-analysis methods and the scary part isn't the AI. It's how ordinary the rest of it was.
Days after I wrote about building a credential broker by hand, the Model Context Protocol standardized almost exactly that pattern. Good news for the modern half of a company's stack. The SAP and the Ariba don't get the memo.
Cloudflare OS looks like it requires owning a global network to build. Most of it doesn't. Here's the one piece that genuinely does, and how to get the rest of it with Entra, a service account, and the discipline to stop letting agents hold raw credentials.
I built an invoice-reconciliation agent one 'turns out' at a time — multiple invoices per email, three names for one column, a vendor ID that looked like ours but wasn't. None of it was a bug. It was the pipeline finally telling me its actual shape.
This chat agent runs in a Kubernetes pod on a Mac mini that used to just sit on a shelf, mostly idle. I didn't build my own p2p git and CI/CD system to save money. I built it to learn how it actually works, and because the machines around me were already on.
You can't stage a 150-endpoint replacement and just flip a switch. So we didn't. We put a proxy in front of the old system, recorded everything, and let the new one prove itself in the shadows before it was ever allowed to matter.
Most integration work assumes one system is telling the truth and the other needs to catch up. Local-first, offline-capable apps break that assumption on purpose — and that changes what 'integration' actually has to mean.
Clients scope the build. Almost nobody scopes what happens after — the years of small breakages that show up on their own schedule, not yours. Here's what that bill actually looks like, and how it's starting to change.
No changelog. No email. A field that used to be a string started coming back as an object, and the pipeline that had run clean for a year started silently dropping records.
A lot of integrations I inherit ask 'what's the status right now?' every five minutes, forever. The better question is almost always: what just happened?
You know the move: pull up System A, copy the number, swivel the chair, paste it into System B. It works. It also quietly costs more than the integration you're avoiding.
Everyone thinks the hard part of an integration is the code. It isn't. The hard part is figuring out that their 'Customer ID' and your 'Account Number' are supposed to be the same thing — except for the eleven accounts where they aren't.
The first thing I deploy for a new integration client does nothing. It runs in production, connects to nothing important yet, and moves zero real records. That's the point.
Nobody buys a CRM because they love the CRM. They buy it because of what it's connected to. The integration is the product — the software underneath is just plumbing.
Field Mappings