Essays and field notes. The why behind the work, at reading length.
Type a concept, topic, or phrase — results ranked by semantic relevance
There is a specific moment when you realize you are solving the wrong problem. I hit mine staring at a Salesforce storage dashboard four months into running a high-volume claims operation. I had done the estimate. I had given myself a buffer. The bars were still climbing toward the ceiling faster than I planned, and for a moment I thought: I just need more room.
I had a piece I could not publish and could not delete.
The first time it happened in production, I stared at the logs for twenty minutes before I understood what I was looking at.
The night I shipped my sixth article that week, I knew something had changed. Not in the content itself, in the process. Each piece had gone through five distinct transformations before it reached a reader. Different constraints at each stage. Different quality bars. Clean handoffs between them. Somewhere around midnight it hit me: I had not been writing blog posts. I had been running a pipeline.
The thought landed at the worst possible time. Two in the morning, coffee cold, and I was watching something I'd built actually work. The satisfaction lasted about thirty seconds before the darker thought moved in: what if someone bigger sees this and files on it first?
I'd built maybe twenty agents before I admitted the pattern. Something would work beautifully in isolation. I'd wire it up, watch it do its job, feel that dopamine spike, and call it done. Then a few weeks later something upstream would shift and the whole thing would quietly stop working.
There is a particular kind of waste that looks like productivity. A deployment pipeline spins up, pulls the code, runs the checks, packages the artifact, pushes to the target, and reports success. Minutes of wall-clock time, gone. The logs are clean. The status badge is green. And if you look closely at what just happened, the thing that got deployed is identical to what was already running. Not…
The email came on a Thursday afternoon. Seventeen findings. One of them was a sharing model violation I had introduced nine weeks earlier, in a sprint that had nothing to do with the feature we were trying to ship. The launch date I had promised our first design partner was already three weeks behind us.
There's a particular kind of wrong that feels deeply personal when you're debugging alone late at night. The kind where the model is supposed to be smart enough, the hardware is supposed to be fast enough, and the setup took you a weekend to get right. And then the output is just... wrong. Not wrong in a way you can point at. Wrong in a way that makes you question your own reasoning before you…
The file looked fine. EDI files always look fine when you're staring at them in a text editor, all those segment terminators and element delimiters lined up in their places like they're following orders. The format is built for machine-to-machine clarity. Every piece has a known structure. Every envelope has a header that tells you exactly how to read the rest of it.
The alert came in at 1:47 AM. The kind I had trained a system to handle. The kind that wasn't supposed to need me anymore.
I stared at the console error for longer than I want to admit.
There was a moment, somewhere around the third failed routing attempt in a row, when I realized the problem wasn't the agent. It was me. More specifically, it was a rule I had written with the best of intentions and then quietly forgotten about.
The deploy was scheduled for eleven in the morning. It ran at noon. Nobody touched the config. Nobody changed the schedule. The pipeline did exactly what it was told. That was the problem.
There was a morning my machine just stopped working.
I spent a long time thinking about AI agent security the wrong way.
The component worked. It passed review, it passed testing, it passed QA on every sandbox I had access to. Then it shipped and a portion of the customer base started reporting that a specific interaction just stopped working. The other customers had no issues. Same component. Same package version. Different orgs.
There is a class of problem in healthcare claims processing that does not crash anything. No alarm fires. No log goes red. The system keeps running, claims keep flowing, and somewhere inside that volume, the same claim gets paid twice.
There is a specific kind of 3am temptation in autonomous agent development. You have built an agent that works. It knows its own skills. It can reason about where it excels and where it falls short. And somewhere in that reasoning loop, it surfaces an idea: I should change how I respond to this type of input. I would be better.
Healthcare data moves through a hidden layer most people never think about. Between the system that submits a claim and the payer that adjudicates it sits an intermediary that speaks a language older than the modern web. EDI transactions, the X12-formatted messages for claims, eligibility checks, and remittances, have been the backbone of healthcare administration for decades. And for most of…
There is a question that comes up the moment you are about to ship a Salesforce app to a real customer org. Not a sandbox. Not a scratch org for a demo. A real production environment with real users who are going to depend on this thing every single day. The question sounds responsible. It sounds like the mature, professional path. "Should we package this before we go live?"
I knew something was wrong before the screen froze.
There is a specific kind of dread that sets in when everything looks too good.
The first time I noticed something was off, everything looked fine.
Every session I opened, the same thing happened. The AI assistant loaded, and with it came the full operating rulebook for everything I might ever do: Salesforce org safety guards, publishing pipeline discipline, agent self-star taxonomy requirements, UI typography standards, concurrency policy, IP firewall rules. All twelve thousand tokens of it. Every time. Whether I was writing a LinkedIn…
Three in the morning. I had just approved my own plan. Not reviewed it, approved it. My tired brain said it was solid. The agents started executing. By morning I had a beautifully built implementation of the wrong thing.
There is a specific feeling when you open a codebase intending to clean it up. Almost smug. You remember writing this thing, or you've read it before, and you can already see the problems from the doorway. The function names are too long. The abstractions leaked in the wrong direction. There's that one class that does eleven things and everyone's afraid to touch.
There is a specific kind of dread that arrives when you realize a system you built has been doing something wrong the whole time. Not crashing. Not throwing errors. Just quietly, confidently, doing the wrong thing. I hit that moment while reviewing routing logs late one evening.
It is 4:30 on a Friday. Sprint review in thirty minutes. Someone changed a segment in the claim generator last week, a small fix, completely reasonable, and the test suite is failing on seven fixture files that no longer match what the code produces. You open the first one. Eight hundred bytes of pipe-delimited segments, loop structures, interchange control headers. You open the second. Then the…
There is a moment every API builder knows. You ship the endpoint, the integration team says it works, and three weeks later something upstream starts misbehaving in ways that do not make sense. The data is there, eventually. But a consuming client timed out waiting for it, or gave up and retried, creating duplicates. The logs show nothing technically wrong.
There is a specific kind of dread that hits you when you realize an AI agent just sent something to production that you didn't intend to send. Not a crash, not an error. The system ran fine. The agent did exactly what it was designed to do. The output just went somewhere it shouldn't have.
The machine died at 3am.
I was watching one of my agents fail at something it had done perfectly two weeks earlier.
The email arrives looking innocent enough. "Congratulations on submitting to the AppExchange Security Review." Then you open the linked documentation and feel it, that specific flavor of dread reserved for large PDFs with multiple appendices.
Shield was on. The fields were encrypted. The security assessment was scheduled for next month. Everyone felt good.
Something goes wrong at 2am. You pull the logs. The agent had authorization, of course it did. You gave it authorization six hours ago when the session started. You'd moved on to other things. The session token was still warm, and the agent executed the risky operation on the wrong target with full confidence that you'd approved.
There is a moment in every serious multi-agent project where someone finally says the quiet part out loud.
There's a version of agent routing that lives in almost every platform codebase I've seen, including my own early drafts. It's a function. Sometimes two hundred lines, sometimes a thousand. It reads the incoming message, hunts for keywords, pattern-matches on intent signals, and hands off to a specialist. "Summarize" goes left. "Write code" goes right. Both in the same message? Good luck.
There is a particular kind of dread that sets in at two in the morning when you realize the query you shipped last week can be turned against you.
There is a particular kind of dread that hits you at two in the morning when you realize the system you spent six months building has been quietly lying to you.
My work journal writes itself: every session gets captured by a hook, and a nightly job distills the day into one page. Eighty-four entries since April 4. This morning I scrolled back through all of them looking for a through-line, and the honest answer is there isn't one. An EDI acknowledgment loop on a Monday. A drift detector for model routing on a Wednesday. License hygiene on a Friday. A…
Two ollama pulls, plus an LM Studio Llama 70B load, plus two subagents hitting a cloud LLM provider's API, plus seven daemons running scheduled scans. All at once. 2026-05-13, 10:58 UTC. Kernel panic.
I was watching my own routing agent send the same task to the same sub-agent for the forty-seventh time. "Summarize this PDF." Same shape, same answer, every single time. And on attempt forty-eight, it stopped, thought hard, burned the tokens, and arrived at the exact route it had already arrived at forty-seven times before.
I read three orchestration repos so you do not have to. It started because I was sick of the pattern. Every few months something announces that multi-agent orchestration is figured out, and inside its own demo, it is. Then you hand it a real workload and it dies in the seams I actually live in. So one week I stopped running these things and started reading them, several files deep at the kind of…
It is 2am. The agent has burned 40k tokens and reverted the same file four times, and from where I am sitting it looks like it is working hard. That is the part that fooled me. It was busy. Every loop produced a new patch, a new diff, a new paragraph of reasoning about why this time would be different. The log scrolled. Things were happening. The agent just was not getting anywhere.
Picture the failure that keeps me up at night. An agent reports that a job failed. The job did not fail. The work went through cleanly, every field extracted, the output sitting right there, correct. And the agent routed itself to the error state and stopped, calm as anything, as if it had done its job. There is no diff to look at. The code did not change. The config did not change. The…
> Disclaimer: I am not a lawyer, and nothing here is legal advice. What follows is my reading of what these license texts actually say in plain language, and the patent implications that seem to follow from that text. For any real IP decision, take it to a qualified patent attorney. On a public page a wrong legal claim is worse than a cautious one, so I am going to stay close to the words on the…
It's 2am and I am staring at a routing layer I spent weeks tuning, running a thought experiment that will not let me sleep. The router is doing exactly what I built it to do. Nothing in my code would change, nothing in my config would change, and yet I can see, plain as day, the night this system goes confidently, repeatedly wrong while every line of it stays correct. The failure is already…
The test that scared me was the one that passed.
Pattern source: KARIMO (Apache-2.0)
Picture the worst version of a deposition. You are three years past the build, sitting in a conference room you do not own, and opposing counsel slides two printouts across the table. One is your git history. The other is your browser history. They are not accusing you of copying a single line of code. They have something quieter and worse. A highlighted row on each page, and a date that lines…
The panel had been agreeing with itself for a week before I noticed, and the worst part is that the logs looked healthy the whole time.
There is a specific moment when you realize you are solving the wrong problem. I hit mine staring at a Salesforce storage dashboard four months into running a high-volume claims operation. I had done the estimate. I had given myself a buffer. The bars were still climbing toward the ceiling faster than I planned, and for a moment I thought: I just need more room.
I had a piece I could not publish and could not delete.
The first time it happened in production, I stared at the logs for twenty minutes before I understood what I was looking at.
The night I shipped my sixth article that week, I knew something had changed. Not in the content itself, in the process. Each piece had gone through five distinct transformations before it reached a reader. Different constraints at each stage. Different quality bars. Clean handoffs between them. Somewhere around midnight it hit me: I had not been writing blog posts. I had been running a pipeline.
The thought landed at the worst possible time. Two in the morning, coffee cold, and I was watching something I'd built actually work. The satisfaction lasted about thirty seconds before the darker thought moved in: what if someone bigger sees this and files on it first?
I'd built maybe twenty agents before I admitted the pattern. Something would work beautifully in isolation. I'd wire it up, watch it do its job, feel that dopamine spike, and call it done. Then a few weeks later something upstream would shift and the whole thing would quietly stop working.
There is a particular kind of waste that looks like productivity. A deployment pipeline spins up, pulls the code, runs the checks, packages the artifact, pushes to the target, and reports success. Minutes of wall-clock time, gone. The logs are clean. The status badge is green. And if you look closely at what just happened, the thing that got deployed is identical to what was already running. Not…
The email came on a Thursday afternoon. Seventeen findings. One of them was a sharing model violation I had introduced nine weeks earlier, in a sprint that had nothing to do with the feature we were trying to ship. The launch date I had promised our first design partner was already three weeks behind us.
There's a particular kind of wrong that feels deeply personal when you're debugging alone late at night. The kind where the model is supposed to be smart enough, the hardware is supposed to be fast enough, and the setup took you a weekend to get right. And then the output is just... wrong. Not wrong in a way you can point at. Wrong in a way that makes you question your own reasoning before you…
The file looked fine. EDI files always look fine when you're staring at them in a text editor, all those segment terminators and element delimiters lined up in their places like they're following orders. The format is built for machine-to-machine clarity. Every piece has a known structure. Every envelope has a header that tells you exactly how to read the rest of it.
The alert came in at 1:47 AM. The kind I had trained a system to handle. The kind that wasn't supposed to need me anymore.
I stared at the console error for longer than I want to admit.
There was a moment, somewhere around the third failed routing attempt in a row, when I realized the problem wasn't the agent. It was me. More specifically, it was a rule I had written with the best of intentions and then quietly forgotten about.
The deploy was scheduled for eleven in the morning. It ran at noon. Nobody touched the config. Nobody changed the schedule. The pipeline did exactly what it was told. That was the problem.
There was a morning my machine just stopped working.
I spent a long time thinking about AI agent security the wrong way.
The component worked. It passed review, it passed testing, it passed QA on every sandbox I had access to. Then it shipped and a portion of the customer base started reporting that a specific interaction just stopped working. The other customers had no issues. Same component. Same package version. Different orgs.
There is a class of problem in healthcare claims processing that does not crash anything. No alarm fires. No log goes red. The system keeps running, claims keep flowing, and somewhere inside that volume, the same claim gets paid twice.
There is a specific kind of 3am temptation in autonomous agent development. You have built an agent that works. It knows its own skills. It can reason about where it excels and where it falls short. And somewhere in that reasoning loop, it surfaces an idea: I should change how I respond to this type of input. I would be better.
Healthcare data moves through a hidden layer most people never think about. Between the system that submits a claim and the payer that adjudicates it sits an intermediary that speaks a language older than the modern web. EDI transactions, the X12-formatted messages for claims, eligibility checks, and remittances, have been the backbone of healthcare administration for decades. And for most of…
There is a question that comes up the moment you are about to ship a Salesforce app to a real customer org. Not a sandbox. Not a scratch org for a demo. A real production environment with real users who are going to depend on this thing every single day. The question sounds responsible. It sounds like the mature, professional path. "Should we package this before we go live?"
I knew something was wrong before the screen froze.
There is a specific kind of dread that sets in when everything looks too good.
The first time I noticed something was off, everything looked fine.
Every session I opened, the same thing happened. The AI assistant loaded, and with it came the full operating rulebook for everything I might ever do: Salesforce org safety guards, publishing pipeline discipline, agent self-star taxonomy requirements, UI typography standards, concurrency policy, IP firewall rules. All twelve thousand tokens of it. Every time. Whether I was writing a LinkedIn…
Three in the morning. I had just approved my own plan. Not reviewed it, approved it. My tired brain said it was solid. The agents started executing. By morning I had a beautifully built implementation of the wrong thing.
There is a specific feeling when you open a codebase intending to clean it up. Almost smug. You remember writing this thing, or you've read it before, and you can already see the problems from the doorway. The function names are too long. The abstractions leaked in the wrong direction. There's that one class that does eleven things and everyone's afraid to touch.
There is a specific kind of dread that arrives when you realize a system you built has been doing something wrong the whole time. Not crashing. Not throwing errors. Just quietly, confidently, doing the wrong thing. I hit that moment while reviewing routing logs late one evening.
It is 4:30 on a Friday. Sprint review in thirty minutes. Someone changed a segment in the claim generator last week, a small fix, completely reasonable, and the test suite is failing on seven fixture files that no longer match what the code produces. You open the first one. Eight hundred bytes of pipe-delimited segments, loop structures, interchange control headers. You open the second. Then the…
There is a moment every API builder knows. You ship the endpoint, the integration team says it works, and three weeks later something upstream starts misbehaving in ways that do not make sense. The data is there, eventually. But a consuming client timed out waiting for it, or gave up and retried, creating duplicates. The logs show nothing technically wrong.
There is a specific kind of dread that hits you when you realize an AI agent just sent something to production that you didn't intend to send. Not a crash, not an error. The system ran fine. The agent did exactly what it was designed to do. The output just went somewhere it shouldn't have.
The machine died at 3am.
I was watching one of my agents fail at something it had done perfectly two weeks earlier.
The email arrives looking innocent enough. "Congratulations on submitting to the AppExchange Security Review." Then you open the linked documentation and feel it, that specific flavor of dread reserved for large PDFs with multiple appendices.
Shield was on. The fields were encrypted. The security assessment was scheduled for next month. Everyone felt good.
Something goes wrong at 2am. You pull the logs. The agent had authorization, of course it did. You gave it authorization six hours ago when the session started. You'd moved on to other things. The session token was still warm, and the agent executed the risky operation on the wrong target with full confidence that you'd approved.
There is a moment in every serious multi-agent project where someone finally says the quiet part out loud.
There's a version of agent routing that lives in almost every platform codebase I've seen, including my own early drafts. It's a function. Sometimes two hundred lines, sometimes a thousand. It reads the incoming message, hunts for keywords, pattern-matches on intent signals, and hands off to a specialist. "Summarize" goes left. "Write code" goes right. Both in the same message? Good luck.
There is a particular kind of dread that sets in at two in the morning when you realize the query you shipped last week can be turned against you.
There is a particular kind of dread that hits you at two in the morning when you realize the system you spent six months building has been quietly lying to you.
My work journal writes itself: every session gets captured by a hook, and a nightly job distills the day into one page. Eighty-four entries since April 4. This morning I scrolled back through all of them looking for a through-line, and the honest answer is there isn't one. An EDI acknowledgment loop on a Monday. A drift detector for model routing on a Wednesday. License hygiene on a Friday. A…
Two ollama pulls, plus an LM Studio Llama 70B load, plus two subagents hitting a cloud LLM provider's API, plus seven daemons running scheduled scans. All at once. 2026-05-13, 10:58 UTC. Kernel panic.
I was watching my own routing agent send the same task to the same sub-agent for the forty-seventh time. "Summarize this PDF." Same shape, same answer, every single time. And on attempt forty-eight, it stopped, thought hard, burned the tokens, and arrived at the exact route it had already arrived at forty-seven times before.
I read three orchestration repos so you do not have to. It started because I was sick of the pattern. Every few months something announces that multi-agent orchestration is figured out, and inside its own demo, it is. Then you hand it a real workload and it dies in the seams I actually live in. So one week I stopped running these things and started reading them, several files deep at the kind of…
It is 2am. The agent has burned 40k tokens and reverted the same file four times, and from where I am sitting it looks like it is working hard. That is the part that fooled me. It was busy. Every loop produced a new patch, a new diff, a new paragraph of reasoning about why this time would be different. The log scrolled. Things were happening. The agent just was not getting anywhere.
Picture the failure that keeps me up at night. An agent reports that a job failed. The job did not fail. The work went through cleanly, every field extracted, the output sitting right there, correct. And the agent routed itself to the error state and stopped, calm as anything, as if it had done its job. There is no diff to look at. The code did not change. The config did not change. The…
> Disclaimer: I am not a lawyer, and nothing here is legal advice. What follows is my reading of what these license texts actually say in plain language, and the patent implications that seem to follow from that text. For any real IP decision, take it to a qualified patent attorney. On a public page a wrong legal claim is worse than a cautious one, so I am going to stay close to the words on the…
It's 2am and I am staring at a routing layer I spent weeks tuning, running a thought experiment that will not let me sleep. The router is doing exactly what I built it to do. Nothing in my code would change, nothing in my config would change, and yet I can see, plain as day, the night this system goes confidently, repeatedly wrong while every line of it stays correct. The failure is already…
The test that scared me was the one that passed.
Pattern source: KARIMO (Apache-2.0)
Picture the worst version of a deposition. You are three years past the build, sitting in a conference room you do not own, and opposing counsel slides two printouts across the table. One is your git history. The other is your browser history. They are not accusing you of copying a single line of code. They have something quieter and worse. A highlighted row on each page, and a date that lines…
The panel had been agreeing with itself for a week before I noticed, and the worst part is that the logs looked healthy the whole time.
