The Long Way Around
Five and a half years from network automation into AI — what worked, what cost me a year I'd like back, and the number I wish someone had handed me.
My first Disco Diffusion image generated on August 5th 2022
On May 13, 2025, I was at The Midway in San Francisco for Interrupt, LangChain’s first conference. Eight hundred people were here to talk about the new hotness, agents. Andrew Ng was keynoting — the same Andrew Ng whose courses I’d worked through two years earlier when I figured out I didn’t actually understand the thing I’d been talking about publicly for months.
I stepped out to take a call. My role at Juniper was gone.
Five weeks later, the DOJ settled with HPE. Two weeks after that, the acquisition closed. The runway I had been planning for was now active, and it was time to get to work.
I’ve been running on severance and then savings ever since. That ran out this month, with my Claude Max subscription bouncing, which signaled my run was over.
So I’m sharing my journey and the lessons learned.
Some of what follows worked. Some of it cost me time I’d like back. Overall I feel very fortunate to have been able to embark on this journey and to the good friends I have meet. Sorry about all the failed demos.
If you’re someone trying to work out whether to shift toward AI, or how — most of this is written for you. I’ve put the sharp edges I hit near the end separately, because those are the ones I’d want handed to me.
I’m not selling a course, and I don’t have a framework. I have five and a half years of receipts and some scar tissue.
I didn’t want to be there in the first place.
I joined Apstra in July 2017 as a Sr. Automation Solutions Architect. Apstra built intent-based networking that was explicitly multi-vendor — the whole pitch was closed-loop automation that worked regardless of whose hardware was underneath. Cumulus, Arista, Cisco, Juniper. That mattered to me. It’s why I went.
In December 2020, Juniper announced it was acquiring us. The deal closed in January 2021.
I want to be careful here, because a lot of people at Juniper did right by me and I’m not interested in trashing them. But I did not want a hardware vendor buying a vendor-agnostic product. That’s not a hunch I developed later — it was the obvious tension, and it was sitting right there in the announcement. Juniper’s own press release led with Apstra’s multi-vendor architecture as the thing they were buying.
I stayed. I ran CloudLabs through the acquisition, scaled the team, and spent a few years trying to make peace with it and find my place. I knew I needed to leave. I didn’t know how or when.
That’s the state I was in when AI showed up.
The Saturday morning
Late 2022, roughly two years into the acquisition. I was up early on a Saturday doing nothing in particular, and I ran into AI-generated artwork online. This moment in time did two things. First it peaked my interest in learning about what I just saw and two it started a creative fire in me and my art that has not slowed down.
Diffusion models, early days. I didn’t understand any of it, no idea what was happening under the hood, why it worked, what the architecture was. It was magic, and I knew it was magic, which is a specific kind of frustrating.
But it pulled me back into a mode I hadn’t been in since I was chasing the CCIE. Up at 6 AM on a Saturday after a full work week because I wanted to see what the new model could do. I finally had something I could sink my teeth into, and there was plenty of room to explore!
ChatGPT and the part where I embarrass myself
It’s worth remembering what “AI” meant to most working engineers before November 2022, because it explains why the ground moved so fast.
There were two genres. The first was the Twitter and LinkedIn post: I made an AI watch a thousand hours of car commercials and here’s the script it wrote. The second was the occasional FAANG data scientist announcing the thing was alive — Blake Lemoine went to the Washington Post in June 2022 saying Google’s LaMDA was sentient, got put on leave that month, and was fired on July 22, five months before ChatGPT shipped.
So the two available mental models were “AI is a joke generator” and “AI is Skynet’s alpha version.” Neither had anything to do with whether this was useful for infrastructure work. There was no version of the story where you asked it to do your job.
Then November 30, 2022. ChatGPT lands, and it does natural language processing (NLP) in a way you can use.
My head was already somewhere useful. I’d spent fifteen years in network automation watching us build abstraction layer on top of abstraction layer, and I’d been thinking about what a natural language interface would mean for our teams and work. ChatGPT was the first thing that made the question concrete.
I asked it to write a Python function that adds a VLAN to an interface. It did. I posted it on LinkedIn.
That went off harder than I expected — and here’s a thing I glossed over for a long time: it went off because people already knew who I was. I’d been on Packet Pushers and Datanauts. I’d been a Tech Field Day delegate since 2014 and a presenter since 2018. I had standing in the network automation community.
I don't say this to brag, but I wasted way too much time over the years trying to understand why some random engineer's project went viral, and mine did not. I only got the early attention because I had already built the connections. What I also did not realize was I only had credit in networking and infrastructure, so with AI and ML I was in deep waters without the tools I needed to survive
What followed was a few months of podcasts and panels where I talked about: Januaryary, February, March of 2023.
I want to be blunt about this: I didn’t know what I was talking about.
I found myself sitting across from PhDs in machine learning and 20 years of industry experience. I could describe what I’d done — here’s the function, here’s how it might slot into an automation workflow — but I couldn’t explain why any of it worked. I was pattern-matching from fifteen years of infrastructure experience onto a thing I fundamentally did not understand.
The internal version of this happened at the same time. That momentum put me in front of executives and eventually Juniper’s AI org, trying to help drive what AI meant for our industry.
At some point in that stretch I realized: if I keep doing this, I’m a guy with a platform and no foundation. That’s not a career. That’s a liability with good SEO.
So I stopped talking and went to school.
The year of fundamentals
AI For Everyone in February 2023. The Machine Learning Specialization in April. The Deep Learning Specialization in July. All Coursera, all Andrew Ng, all credentialed if you want to check.
Five months. Backpropagation, gradient descent, model architectures and where they came from, and in the deep learning track the NLP and recurrent network material I’d been gesturing at on podcasts without being able to name.
None of it made me an ML researcher. It made me competent enough to stop bluffing, which was the point.
Then I hit a wall that wasn’t my fault
Fundamentals in hand, I went looking for the next layer: how do you actually operate this stuff? AIOps, LLMOps, whatever we were calling it: deployment, evaluation, monitoring, the discipline of running these systems in production.
There was nothing there.
Every course I found was either genuinely bad or so basic it was a rebranded intro to DevOps with no operational depth, no failure modes, no war stories. I spent the better part of a year hunting for material that would take me from “I understand transformers” to “I can run this in production,” and I came up with nothing I could use.
The reason is obvious in retrospect: the only people who knew how to operate these systems were the people building the frontier models, and that knowledge hadn’t left the labs yet. There was no curriculum because there was no accumulated practice to write one from.
So that year produced no credential and no visible progress. I failed to build the skill I went looking for, and I want to say that plainly rather than pretend the path was continuous.
What it did produce was the conclusion that shaped everything after: if nobody has written it down, the only way to learn it is to build something and find out. Every project in the rest of this post exists because of that dead end.
What it looked like from outside
Four commits.
That’s my entire 2023 GitHub contribution graph. The lowest year on my account since 2012 — a fork of the Full Stack Deep Learning labs, random notebooks and a throwaway test app. From the outside I looked finished.
Half that year was coursework. The other half was searching for training that didn't exist, and arguing, which I’ll get to.
I mention it for anyone staring down a catch-up year and worried about the hole it’ll leave on their profile. Study time produces nothing you can show anyone. Be patient and keep focused. My commit count ran 70 in 2022, 4 in 2023, then 151, then 399, then 803 — and 2026 isn’t over. The quiet year is load-bearing.
The part that did work
The other half of that education was RAG, and I got it the hard way — in rooms with people building RAG products for real. Amr and Justin at Vectara took a lot of my early, bad questions about grounding and truth and how you give these systems a foundation. Those conversations were uncomfortable in the specific way that means you’re learning something.
And somewhere in there the thing clicked that reframed everything:
These were the same conversations I’d been having for fifteen years.
How do we trust it? Why did it fail here? How do we verify it did the right thing? How do we build confidence incrementally instead of all at once? Every question software and network engineers were asking about LLMs was one I’d already been answering about network automation.
Different domain. Same problem. That’s the whole insight, and it’s why infrastructure people are better positioned for this than they think.
The thing I’d learned the hard way
I spent a big chunk of my time at Juniper on RAG conversations. Should we use this? Can we trust it? What about hallucinations? How do we test it?
I’d had this exact year before, in network automation. And here’s what fifteen years taught me: you cannot change someone’s mind. They have to want to.
You can coach. You can show a new idea, tell a story, walk someone down a path. But the actual turn happens inside them, or it doesn’t happen. If someone has decided, arguing harder makes you the guy who argues.
I’d already burned years of my career trying to convince people that network automation was worth doing. I wasn’t going to spend the AI years the same way.
So I stopped evangelizing and went heads-down, and I only worked with people who were just as excited about AI as I was. That decision is what propelled me to work on some of the toughest problems we face in this AI boom.
A rule about learning hard things
Before the projects, the rule that shaped all of them. I’ve been pushing this for years, and I think it's the single most useful thing I know about skill acquisition:
When you’re learning something genuinely complex, do not learn it on top of the thing you're already experienced in. Find something in your personal life. Something outside the day job, something that excites you, ideally something you’re a little bad at.
The reason is diagnostic. If you learn a hard new skill inside your area of mastery, you can’t tell which thing is hurting. Is this concept difficult, or am I tripping over an edge case I only know about because I’ve been doing this for fifteen years? You lose the ability to isolate the variable, and you end up patching over gaps with expertise instead of actually closing them.
In network automation, this is acute. Network engineers are hands-on people who are excellent at the CLI. Nobody ever told them to be strong software engineers — that wasn’t the job. So when they sit down to learn APIs and programmatic integration against hardware running critical infrastructure, the complexity stacks faster than the fundamentals can land. Distributed systems and software development are hard enough on their own. Doing that on production infrastructure, where a mistake takes down a hospital or a trading floor, means you never get the room to be bad at it first.
So my advice has always been: get away from the network. Build something personal.
When I got serious about Python, I built a cryptocurrency market tracker—nothing to do with networking. Nobody was going to page me at 2 AM if it broke, and every problem I hit was a Python problem — not a Python-plus-BGP problem I could bluff my way past.
Both of the projects that taught me the most about AI follow that rule. They look like detours. They aren't
Artist Dashboard, and the constraint that taught me the most
2024 – 2025 · gpt-3.5-turbo → GPT-4 → Claude Code · 3 full rebuilds
A full Python/FastAPI SaaS for artists and creators, with real social platform integrations.
The rule I set: I write no code. Read-only. The only way I was allowed to work on it was through the prompt.
That was a stupid, useful constraint. It’s how I learn — put myself somewhere I can’t cheat and find out what breaks.
It also followed the rule. Artists and social platforms were a domain I knew nothing about, so nothing in my infrastructure background was available to bail me out. Every problem I hit was a working-with-AI problem, uncontaminated by fifteen years of knowing how networks fail.
What broke was everything, at first—this predated plan mode. Models would claim they'd done work they hadn’t. State drifted. The thing was unstable for the better part of a year.
Two things came out of it:
How you talk to these systems is the whole game. Not prompt tricks. Actual communication. The mental model that worked was talking to it like a senior engineer or a report — context, intent, room for back-and-forth, saying what “done” means. The soft skills that make you a decent lead are the same skills that make you effective here. That’s not a metaphor; it’s just true.
Refactoring is not optional; it’s structural. Full refactors at defined gates stabilized exploratory and PoC work. Which, of course. We already know this. Branching, separate repos, paying down debt from poorly defined requirements. We built those practices for a reason and then acted surprised when the reason still applied.
Three full rebuilds, three model generations. It started on gpt-3.5-turbo. When GPT-4 arrived, that was a rebuild event — not an upgrade, a rebuild. Same again moving to Claude Code.
That’s the part I’d underline. Every rebuild was forced by the tooling moving underneath me, not as much by bad code. A model swap changed what the system was capable of badly enough that patching around it cost more than starting over. Anyone who’s lived through a platform migration in infrastructure knows this shape exactly. It’s the same shape, running at roughly ten times the speed.
The product shut down. The methodology didn’t.
MCP, 24 days in
Dec 2024 (local) → Jan 2025 (public) · JavaScript · [MODEL?]
Anthropic announced the Model Context Protocol on November 25, 2024.
I had one running locally in December. My tox testing MCP — hook an agent into a Python codebase’s tox framework so it can run specific test workflows directly — went public January 19, 2025.
That’s the repo date. It’s checkable — that1guy15/tox-testing. It’s also, to this day, the most-starred thing I’ve published, which at five stars tells you something about how early it was and something else about how small the audience was.
For context on where that sits: there were over a thousand MCP servers in the wild by February 2025, and OpenAI didn’t adopt the protocol until March. I wasn’t first, but I was in before the room filled up.
Then MCP got messy, and this is the part worth reading if you’re standing where I was standing.
The protocol was genuinely great — it collapsed a pile of custom API-and-glue work into something standard. But nobody knew how to use it. People bolted MCPs onto everything. Enormous token spend for no benefit. Tox testing proved this. Servers wrapping servers. Context windows full of tool definitions nobody called.
I still spend time helping people build these properly, because the failure mode is consistent: teams treat MCP as an integration checkbox instead of a design decision about what an agent should be able to reach.
If you have been around long enough to remember the Cloud movement or unlucky enough to have to deal with an internal “private cloud” then you will understand when i say the single biggest failure out of Cloud was the inability for teams to build the proper user experience and tooling for the users who need it. MCP’s are repeating this same pattern.
MCP also introduced a problem we already knew and hadn’t braced for. The moment you have AI talking to AI through a middle layer, you have a distributed system — with all the failure modes, and none of the tooling.
Protocols, and the part I actually cared about
Google’s Agent2Agent protocol landed April 9, 202,5 and addressed the agent-to-agent gap directly.
Honestly, A2A itself didn’t grab me. Agents talking to agents seemed straightforward.
What grabbed me was AP2 — the Agent Payments Protocol — announced September 16, 2025 as an extension to A2A, with 60-plus partners. Agents negotiating and settling payments. Cryptographically verifiable proof that a user authorized a specific transaction.
That’s the piece that makes an agent economy an actual economy instead of a demo.
Sept 2025 – present · GPT-3.7 → GPT-4 → Claude Code , CodeX· 4 full rebuilds
Which is where Tokru came from. I took Presto — my AI-infused Kanban system for taking a project from PRD to development, built in the plan-mode era on Claude 3.7 with LangGraph, LangChain and LlamaIndex — plus some other pieces, and pointed them at a question: what does a marketplace look like when the participants are agents?
Not just a directory with a search box. I need a plumber, I need someone to build this software, I need my lawn mowed — and the agent either does the work or removes every obstacle between the person who can do the work and getting paid for it. Making the people involved look like a superhero is my true north.
Tokru today is a capability registry — it turns your actual work into a structured, machine-readable profile, published at your own handle and queryable by humans and agents over MCP and A2A.
abstractryan.ai, and the interface question
2025 portfolio + A2A experiments → 2026 current build · Astro / TypeScript / Cloudflare Workers + 100% FREE
The other half of the Tokru question was the interface, and that got its own testbed.
If we have natural language, why are we still filling out forms and dropdowns? Why is the UI something you fight through instead of something assembled for you on the spot? Every web app I’ve ever used assumes a human with a mouse, patiently narrowing options someone else decided on in advance.
So my portfolio became the lab. It’s built on a premise I actually believe: the next visitor probably isn’t a person scrolling. It’s an agent querying on someone’s behalf.
It runs in two modes. Humans get an ask-don’t-browse interface — no nav-and-hunt; tell it what you’re here for, and it assembles the relevant thing. Agents get a real endpoint: A2A over JSON-RPC, an ACP manifest, an agent card at /.well-known/agent-card.json. The site answers to machines directly rather than making them scrape a page built for eyeballs.
The piece I’m proudest of is the resume tailor. Paste a job description, and it produces a match report — which of my actual bullets are evidence for which of your requirements, and where I don’t line up. That second part is deliberate, and it's shown by default.
And it operates under one hard constraint: it never rewrites a bullet and never invents a metric. It reorders and selects from content I wrote and can defend in a room. The AI does retrieval and ranking. The claims stay mine.
That constraint is the whole thesis in miniature. The failure mode everyone worries about isn’t AI doing work — it’s AI generating claims nobody verified. Take generation off the table, leave selection on it, and you get something useful that can’t embarrass you.
The build logic from this site became the architecture for Tokru’s user onboarding. The portfolio was the prototype; the marketplace is the product.
OpenClaw, and the moment the bill came due
November 2025, Peter Steinberger shipped what eventually became OpenClaw. First real full harness I’d seen — proper agent setup, point it at something, send it off.
Up to then we’d all been assembling this ourselves. Load the context, plan, prep, launch, do something else. OpenClaw made it a product. GPT4 was the first model I could “Set it and forget it” but OpenClaw took this to the next level.
Everyone I know got hooked immediately. And then the bill arrived.
Here’s the mechanism, and I think it’s underappreciated: Claude Code burns tokens while you drive it. It stops when you stop. An always-on harness has no natural stopping point. It works while you sleep. That’s the entire pitch, and it’s also why the cost model flips from per-session to continuous.
I’d been in this for years without a serious budget conversation. The most aggressive people I know hadn’t hit one either. OpenClaw is where that ended — not because it was wasteful, but because it was good enough to leave running.
Tokens are still too expensive for this to make sense at the scale the tooling now assumes.
So when you hear me say I avoid Fable and the other top-tier models — that’s why. It isn’t a capability judgment. Those models are good, and for a lot of work they’re the right call.
One thing I learned from this experience is how to use the downtime after I have exhausted all my weeks tokens. I usually get about 2 workdays full of coding in before I use all my Max tokens. The rest of the week is for hands on testing and exploring the product. Its a good natural QA break.
Lisa, and the wall
v1: early 2026, OpenClaw + local models · v2: 2026, own harness · Ollama / vLLM · Nemotron, Gemini, Minmax, DeepSeek.
So: local models…
I’d been poking at Ollama and vLLM on a MacBook for a while, never seriously. I built a real machine and started Lisa from The Simpsons, because she’s the smart one and she’s the one actually doing the work.
Lisa v1 was OpenClaw pointed at local models. That died fast (2 weeks tops). OpenClaw was architected around frontier models; throw local weights at it and it tanks.
Lisa v2 was mine, top to bottom. My harness, my framework, agent management, context management, system context.
And here’s what I learned, expensively: the model is the easy part.
Every model had different capabilities and different failure modes. Work tuned for one wouldn’t transfer. Swapping models meant rewriting whole sections. And every convenience I’d taken for granted in Claude Code — memory management and sanitization, planning, context handling and tool calling, oh the tool calling missory, turned out to be a system somebody had built deliberately. I now had to build each one myself.
That’s the thing worth taking from this. When people say “the harness matters more than the model,” they’re not being clever. Everything that makes Claude Code feel reliable is engineering that exists on purpose, and you notice all of it the moment it’s gone.
Lisa got shelved. Not because she failed — she works — but because she wasn’t close enough to Claude Code to do my actual work, and I needed to do actual work.
Root Cause
2025 GDScript prototype → Feb 2026 Rust rewrite · Claude Code + Lisa · Rust / Bevy, Native RAG w/ MinMax
I almost left this out, which reflects how I evaluate my own work.
Root Cause is a datacenter simulation game. Power distribution, thermal management, CLOS networking, cascading failures, a local multi-agent AI narrator. 80+ integration tests. It’s on itch.io, free, playable right now — early access alpha, Windows and macOS. There’s a Discord and dev notes if you want the build log.
I prototyped it in Godot and GDScript in 2025, then threw that away and rewrote the whole thing in Rust and Bevy in early 2026 — a stack I had never touched. Prototyping in something familiar tells you whether the idea works. Rewriting in something foreign tells you whether the method works.
And this is the rule taken as far as I could.
I’ve gotten back into games as I’ve gotten older, so the subject was something I actually wanted. But look at what I stacked on top of it: an industry I know nothing about. A toolchain I know nothing about. A set of disciplines — simulation, rendering, game feel, narrative, art pipeline — that have to be married together and that I have no background in. A language and a framework I’d never written a line of.
There was no expertise available to hide behind. Not one piece of it.
Which made it the only honest way to ask the question I actually wanted answered: how do AI and I handle a project that neither of us knows anything about?
I architected it and directed it. alongside Claudes help. Claude Code and Lisa executed. The point was never the game, though the game is real — the point was answering one question honestly: what does agentic development actually produce when you run it as a discipline instead of a vibe?
Answer: it produces a working system in a language you don’t know, if — and only if — you hold the architecture and the verification. The moment you hand over judgment, you get a plausible-looking pile of dysfunction.
Root Cause is free on itch.io, and Im chipping away it in my spare time with the dream of releaseing it as a training tool. You can say I made it as far as you would expect for a first indie game from a guy nobody knows in a genre nobody asked for.
I mention it because I suspect a lot of people are quietly holding some version of that same fantasy right now — that AI will let them ship something good enough, fast enough, to get out from under whatever they’re under. I shipped something good, in a language I didn’t know, faster than I had any right to. It did not do that. Building the thing and selling the thing are two separate problems, and so far AI has only helped me with one of them.
If you want the single artifact that represents what I’ve learned, it’s this one, not the essays.
Milhouse
2026 – present · open sourced July 2026, Apache-2.0 ·
that1guy15/Milhouse-oss· [Opus 5, Fable 5, Claude Code, CodeX, Local Milhouse]
Lisa taught me the missing layer: you cannot see what your agents are doing.
Milhouse — named for the kid who spends the whole show orbiting Lisa — is local-first observability and a verified feedback loop for teams shipping with AI.
Agent traces, decisions, deployments, logs. Observability and security testing built in from day one, not bolted on, because that’s how any serious system gets built now.
The design principle I care most about: work isn’t complete because somebody said it’s done. It’s complete when the signal that caused the problem is observed to have changed. No operator override. If the metric that triggered the work hasn’t moved, the work isn't complete.
This subsequently closes the loop in both directions. Milhouse watches me and Claude Code work, then writes PR reviews and drops feedback into the project on how to do it better. It also sends me a report — how to interact with the agents more effectively, what phrasings cause problems.
In July, with most of my runway already gone, I started rebuilding Milhouse from scratch in the open — that1guy15/Milhouse-oss, Apache-2.0, Python.
It is not done. It’s pre-alpha. What exists is the architecture and the rebuild in progress, informed by everything the private version got wrong.
Most of the tokens I have left are going into finishing it. That’s the plan for whatever runway remains. The project board and the PRs are public — you can watch it happen, or argue with a decision, or take the thing in a direction I hadn’t thought of.
Why put my last resources into something I’m giving away? Partly because I’d rather it exist than own it. Mostly because the observability layer is the piece the whole industry is missing right now, and I’d rather it get built by people who’ve felt the problem than sold back to us by someone who hasn’t.
If any part of this post lands with you, that repo is the place to show up.
What this actually cost
Let me put a number on it, because I think this is the most useful thing in the post.
Terminated May 2025. Three months' severance. Then my own savings, until this month.
Roughly fifteen months of self-funded, full-time AI work.
In that window: Tokru, Root Cause, both versions of Lisa, Milhouse and its open-source rebuild, this portfolio.
It wasn’t enough. Not because the work failed — the work is real. It didn’t convert to income fast enough.
If you’re reading this while doing the math on your own transition, that’s your data point. Fifteen months of aggressive, focused, full-time effort by someone with twenty years of infrastructure background and a CCIE, and the runway ran out before the revenue started.
The sharp edges
If you’re a team lead or an engineer about to walk into this or finding yourself in the thick of it, these are the things that cost me the most. None of them are model problems. All of them are engineering and organizational problems wearing an AI costume.
Model migrations are rebuilds, not upgrades. Artist Dashboard was rebuilt from scratch three times, once per model generation. Not because the code was bad — because a capability shift changed what the system could be, and patching around the old assumptions cost more than starting clean. Budget for this. If your roadmap treats “move to the new model” as a version bump, your roadmap is wrong.
Decide what an agent can reach before you connect anything. The MCP era produced enormous waste — servers bolted onto everything, tool definitions crowding out context windows, token spend with no return. MCP is a design decision about the boundary of an agent’s reach. Treating it as an integration checkbox is how you end up paying for a hundred tools an agent never calls.
The moment agents talk to each other, you own a distributed system. All the familiar failure modes — partial failure, retry storms, inconsistent state, unclear ownership — and almost none of the tooling that took us twenty years to build for services. Infrastructure teams have an enormous advantage here and mostly don’t realize it, because they already know what these failures look like.
Evaluate the harness, not the model. Everything that makes a good agentic tool feel reliable — memory management, context handling, sanitization, planning — is deliberate engineering somebody did on purpose. I know because I rebuilt each piece myself, and it took months. When you’re comparing options, the model is the part everyone benchmarks, and the harness is the part that determines whether it works on Tuesday.
Your token economics change shape when agents go always-on. Interactive use costs per session and stops when you stop. An always-on agent has no natural stopping point — that’s the entire value proposition and also the whole problem. Model your spend for the second case before you adopt tooling that assumes it.
Local models are not a cost escape hatch yet. I built a full harness for local inference and shelved it. Capabilities vary enough between models that tuning doesn’t transfer, and a model swap means rewriting significant sections. There’s a real future here. It is not this quarter’s budget fix or next but its coming.
Observability has to come before scale, not after. You cannot debug what you cannot see, and agent decisions are invisible by default. The principle I built Milhouse around: work isn’t done because something reported it done — it’s done when the signal that caused the work is observed to have no operator override. If your team is scaling agent usage without decision traces, you’re accumulating a debt you'll pay during an incident.
Keep generation and verification separate. The failure everyone fears isn’t AI doing work; it’s AI producing claims nobody checked. On my own resume tool, I drew the line hard: AI selects and runs; it never writes a bullet or invents a number. Same principle scales. Let it retrieve, rank, draft, and propose. Keep the human on anything that becomes a claim your organization has to stand behind.
Communication is the actual skill. Not prompt tricks. The mental model that works is talking to it like a senior engineer or a direct report — context, intent, what “done” means, room to push back. The people on your team who are good at delegating to humans are the people who’ll be good at this.
Don’t spend a year convincing anyone. I did, and I’d like it back. Find the people who already want it, help them, and let the results do the arguing. Adoption follows demonstration; it does not follow persuasion.
The ask
My goal was never to make AI successful. It’s to make people work at a higher level with less carried weight — fewer things you have to hold in your head, fewer things quietly breaking. And to hand tools to people who couldn’t get past a barrier.
It’s why the language and translation work has always mattered to me. Someone shouldn’t be locked out of an industry or skill because of the language they grew up speaking or the education they were exposed to.
If you’re building agentic systems and hitting the walls, or running a team trying to separate real AI capability from theater, or you need someone who’s already made the expensive mistakes — talk to me.
And if you’re just here for the map: take it. Skip the parts where I wasted time. Build something better.
That’s worth something too.