Field notes on connecting systems, mapping data, and getting integrations live without the six-month "big reveal."
"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