Twenty seconds later, it replied with a structured breakdown — all 9 bandwidth-sharing containers healthy, XMR miner running, SSH terminal and dashboards online, Cloudflare tunnel routing traffic. Then it listed every project by status: which ones were complete and ready to ship, which had active development, and which were stalled waiting on me.

I followed up: "How are the YouTube channels? Are videos getting uploaded as expected?" It told me 5 videos had been produced and uploaded that morning at 6 AM across all channels — while I was sleeping.

Then I asked it to add analytics tracking to the YouTube project. "Session launched!" it replied. "Claude is now working in the youtube-automation project to add analytics tracking." It spun up a dedicated worker, and I went back to whatever I was doing.

That's not a hypothetical. That's a regular evening for me now.

The Problem Nobody Talks About

I have 26 years in the networking industry. I've built network infrastructure that handles millions of connections. But when I started running my own consulting practice alongside personal projects, I hit a wall that no amount of engineering experience prepared me for: context switching across dozens of simultaneous projects is brutal.

At any given time, I'm managing around 28 active projects. YouTube content pipelines across multiple channels. Trading bots that need monitoring. Web services that need to stay up. Client work on Upwork. Health dashboards. Development tools. Personal infrastructure.

No human can keep all of that in their head. And hiring a team for what's essentially a one-person operation didn't make sense. So I built something better.

What It Actually Does

My AI assistant runs 24/7 on a Mac Mini. Not as some fancy chatbot — as an actual operational layer for my business. Here's what a typical day looks like for it:

Morning (before I wake up): It checks all running services, verifies uptime, scans for any overnight issues, and compiles a daily digest. By the time I'm pouring coffee, I have a summary of everything that happened across all 28 projects while I was sleeping.

Throughout the day: It monitors Upwork for new job postings that match my skills. It manages YouTube content pipelines — scheduling, processing, optimization. It watches trading bot performance. It keeps web services healthy and responsive.

When something breaks: It doesn't just alert me. It diagnoses the problem and, in many cases, fixes it autonomously. Services restart themselves. Configurations get corrected. I get a notification that says "this broke, here's what I did to fix it" rather than "ALERT: SERVICE DOWN."

SMS — The Interface That Changed Everything

The game-changer was making it accessible via text message. No app to open. No dashboard to check. Just text it a question from wherever I am, and get an answer in seconds.

"How did the trading bots do overnight?" — instant P&L summary.

"How are the YouTube channels?" — upload status across all five channels.

"Is the forex bot still paper trading?" — real-time status check.

It sounds simple, but the impact is enormous. I went from needing to sit down at a computer and check six different dashboards to getting any answer I need while walking the dog.

Daily Digests and Automated Alerts

Every morning at 7 AM, I get a structured digest via text that covers service health, active project count, and whether anything needs attention. At 8 PM, I get an automated forex trading summary with the day's P&L.

But the real value is in the alerts I didn't ask for. When my assistant's own session crashes, it auto-restarts and texts me that it recovered. When a trading bot closes a position, I get the trade details and P&L instantly. When a child session finishes building something, it texts me a summary of what was completed.

I set the rules for what's worth interrupting me about. Morning digests are brief — just the numbers. Trade alerts come through immediately. Status updates from long-running build sessions arrive when they finish, not while they're working. And quiet hours mean nothing buzzes between 10 PM and 7 AM unless something is genuinely broken.

Delegation at Scale

Here's where it gets interesting. The assistant doesn't try to do everything itself. When it encounters a task that needs focused work — building a new feature, debugging a complex issue, creating a content asset — it spins up a dedicated worker session for that specific job.

Think of it like a manager who delegates. The main assistant maintains the big picture, but specialized workers handle the deep work. Each worker has the context it needs for its specific project, works independently, and reports back when it's done.

A real example: I needed a demo application for a client project. The assistant delegated the entire build to a worker session. That worker designed the interface, connected the APIs, tested the integration, and deployed a working demo — without me writing a single line of code. I reviewed the result, gave feedback, and it iterated. The whole thing took a fraction of the time it would have taken me.

Another example: One of my YouTube channels had an OAuth token expire. The assistant detected the authentication failure, diagnosed the root cause, generated the fix, applied it, and verified the pipeline was flowing again. I found out about it from the daily digest — as a resolved item, not an open problem.

Self-Healing Infrastructure

The assistant monitors its own health and the health of every service it manages. If a process crashes, it restarts. If a service becomes unresponsive, it investigates and recovers. If something is fundamentally broken and requires my input, it escalates clearly — "I tried X, Y, and Z, none worked, here's what I think the issue is."

This isn't theoretical reliability. I've gone entire weekends without checking on anything and come back Monday to find that three issues occurred and were all auto-resolved. The daily digests showed me exactly what happened and what was done about it.

The Numbers

Since deploying this system:

• 28 projects managed simultaneously with one person (me)
• Daily digests replace 45+ minutes of manual monitoring each morning
• SMS access means I'm never more than a text away from any metric or status
• Auto-recovery handles the majority of service issues without my involvement
• Worker delegation handles focused development tasks while I stay in the big picture

This isn't about replacing human judgment. I still make every strategic decision. But the tactical overhead — the monitoring, the routine maintenance, the context gathering, the "is everything still running?" anxiety — that's gone.

Now I Offer This as a Service

After running this system for my own business, I realized this is exactly what other solo operators, small teams, and businesses need. Not a chatbot. Not another SaaS dashboard. A persistent, intelligent layer that actually knows your business and runs it alongside you.

I've packaged everything I've learned into a service that I deploy and manage for clients. Your own AI assistant, customized to your workflows, monitoring your services, accessible via text, and getting smarter about your business every day.

If you're drowning in operational overhead, managing too many projects to keep track of, or just want to stop worrying about whether everything is still running at 2 AM — let's talk about setting one up for you.

Because the best employee you'll ever have doesn't sleep, doesn't forget, and texts you back in twelve seconds.

Interface naming changes. STP syntax changes. HSRP moves to a completely different command structure. Features that were on by default in IOS suddenly need explicit activation in NX-OS. And you're doing this across dozens — maybe hundreds — of switches, each with their own accumulated config drift.

Every network engineer I know does this the same way: manually. Line by line. Maybe with a notepad open on a second monitor listing the syntax differences they've memorized. Maybe with a spreadsheet if they're organized. And inevitably, something gets missed. A spanning-tree portfast becomes a forgotten spanning-tree port type edge. A standby group doesn't get translated to hsrp. An ACL that worked fine on IOS throws an error on NX-OS because the syntax rules are subtly different.

It's tedious, error-prone, and it's 2026. We shouldn't still be doing this by hand.

Where This Started

I've been in networking for 26 years, and I've done my share of platform migrations. But the one that really drove this home was a major migration at a large venue — going from NX-OS back to IOS.

That project involved converting the entire network infrastructure — every switch, every config. The stakes were high. Downtime wasn't an option. And the sheer volume of configuration that needed to be translated accurately between the two platforms was massive.

Early on, I started building a spreadsheet mapping every command difference between IOS and NX-OS. Feature activation requirements. Edge cases where the translation wasn't one-to-one. Syntax that looked similar but behaved differently. That spreadsheet grew into a comprehensive reference document covering hundreds of command mappings.

After the project wrapped, I kept thinking about how many engineers are doing this same translation work right now — in either direction — on their own, without that reference. So I built it into a tool. I started with IOS-to-NX-OS since that's the more common migration path in the industry, and the command mapping works the same way regardless of which direction you're going.

What the Translator Actually Does

The IOS to NX-OS translator at ciscotools.dev takes a block of IOS configuration and converts it to valid NX-OS syntax. You paste your config in, and you get a translated config out.

But it's not doing simple find-and-replace. That's what makes it different from a regex script you'd hack together in an afternoon.

The translator understands IOS configuration hierarchy. It knows that when you're translating interface configs, it's not just about swapping interface GigabitEthernet for interface Ethernet — it needs to handle the entire interface context, including switchport modes, trunk configurations, and access settings that may need restructuring for NX-OS.

Here's what it handles:

• Interface configurations — naming conventions, switchport syntax, descriptions, speed/duplex
• VLANs — VLAN database entries and interface VLAN assignments
• Spanning Tree — portfast to port type edge, BPDU guard, STP mode translations
• HSRP and VRRP — the complete restructuring from IOS standby commands to NX-OS hsrp/vrrp command blocks
• Access Control Lists — numbered and named ACLs with the syntax adjustments NX-OS requires
• Routing protocols — OSPF, BGP, and EIGRP with their respective NX-OS configuration differences
• Port-channels — LACP and static channel-groups with the NX-OS feature lacp activation
• SNMP — community strings, trap receivers, and v3 configurations
• NTP — server and peer configurations
• Logging — syslog destinations and severity levels
• AAA — authentication, authorization, and accounting configurations

Critically, it also generates the feature activation commands that NX-OS requires. This is one of the biggest gotchas engineers hit during migrations — you paste in a perfectly valid OSPF config, but NX-OS won't accept it because you haven't run feature ospf first. The translator identifies which features your config requires and includes those activation commands at the top of the output.

What It's Not

This isn't a magic "press button, migrate network" tool. It translates configuration syntax. It doesn't know your network topology, it doesn't validate that your design makes sense on Nexus hardware, and it doesn't replace the engineering judgment you need for a real migration.

What it does is eliminate the grunt work. Instead of spending hours translating syntax line by line, you spend minutes reviewing and validating a translated config. You're still the engineer making the decisions — the tool just handles the mechanical translation so you can focus on what actually matters.

The Other Tools

While I was at it, I built a few other tools that I kept wishing existed:

Config Diff — paste two configs side by side and get a clean, structured diff. Useful for change validation, troubleshooting, and figuring out what actually changed between two versions of a config.

Config Sanitizer — strips passwords, SNMP community strings, and other sensitive data from configs before you paste them in a forum post or share them with a vendor. Anonymizes IP addresses too.

Template Manager — build and manage reusable config templates with variables. Useful for standardizing deployments across multiple sites or devices.

All free. No login. No account required.

Try It

The translator and all the other tools are live at ciscotools.dev. Paste a config in, see what comes out.

If you find something that doesn't translate correctly, or there's a feature mapping I missed, I want to hear about it. These tools get better with feedback from engineers who are actually using them in production migrations.

And if you're staring down a major IOS-to-NX-OS migration and want hands-on help from someone who's been through it — reach out. That's what I do.

Sometimes they catch it and edit the post. Sometimes they don't. Sometimes the post gets archived before they notice, and now their credentials are indexed forever.

It's not that engineers are careless. It's that scrubbing a config manually is annoying. You're troubleshooting at 11 PM, you need help, and you're not going to spend twenty minutes carefully redacting every sensitive line before posting. So you either share it as-is and hope nobody notices, or you don't share it at all — and don't get the help you need.

I built a tool to fix this.

What the Sanitizer Does

The Config Sanitizer at ciscotools.dev takes a Cisco configuration and strips out everything you shouldn't be sharing:

• Passwords and secrets — enable secrets, line passwords, username passwords, key chains, pre-shared keys
• SNMP community strings — read-only, read-write, and v3 auth/priv credentials
• TACACS and RADIUS keys — server keys and shared secrets
• Banner text — login, MOTD, and exec banners that often contain internal information
• IP address anonymization — replaces real IPs with addresses from RFC 5737 documentation ranges (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24), preserving the structure so the config is still readable and debuggable

The key thing: it preserves the config structure. You still get a complete, valid-looking configuration that someone can read and troubleshoot. It just doesn't have your actual credentials or addressing in it.

When You Need This

Posting on Reddit, forums, or Cisco Community — the most obvious use case. Get help without giving away the keys to your network.

Sharing with vendors — TAC cases, third-party support tickets, or consultant engagements where you need to provide config context but don't want to hand over live credentials.

Internal documentation — config examples in runbooks, wiki pages, or training materials that shouldn't contain production secrets even if they're "internal only."

Sending to TAC — Cisco TAC asks for configs constantly. The sanitizer lets you share what they need for troubleshooting without including what they don't.

Code reviews and change requests — when you need to show a config change in a ticket but the full config contains sensitive data unrelated to the change.

Just Use It

The sanitizer is free at ciscotools.dev. No login, no account, no email signup. Paste your config in, get a clean config out.

While you're there, check out the other tools too — IOS to NX-OS translator, Config Diff, and Template Manager. All free, all built for the same reason: network engineers shouldn't be wasting time on things a tool can handle in seconds.

Stop sharing your passwords on the internet. There's a better way now.

If you've ever tried to use a general-purpose AI chatbot to debug a BGP neighbor stuck in Idle state, or to understand why your OSPF adjacency won't form across a specific platform, you already know the problem. You get answers that sound confident but miss the context. The AI doesn't know which IOS train you're on. It mixes up syntax between platforms. It hallucinates interface names that don't exist on your hardware.

I've spent 26 years in networking. Over the past year, I've been building automation tools that pair that networking background with AI. Some of those tools live on my free CiscoTools.dev site — a config diff tool, an IOS to NX-OS translator, a config sanitizer, a template manager. They get used by network engineers every day.

But a tool is only useful if you know how to use it. And a config translator doesn't help you if you can't describe the problem you're actually trying to solve. That's where an AI assistant should come in — one that speaks the same language network engineers do.

So I built one.

What I shipped this week

I spent the last ten days or so shipping an MVP networking AI chatbot and embedding it across the tools site. The chatbot is trained to handle the kinds of questions a CCNA, CCNP, or expert-level candidate would ask, plus the everyday operational questions that come up for anyone running a real network — route leaks, VLAN mismatches, spanning tree weirdness, migration planning from one platform family to another.

What makes it different from dropping the same question into a generic AI chatbot is the context. The assistant knows it's talking to a network engineer. It knows which command syntax belongs to which platform. It doesn't apologize for five paragraphs before giving you the answer. And critically, it doesn't invent interface names or configuration commands that don't exist.

I also built it as an embeddable widget. That meant I could drop contextual "Ask AI" buttons throughout the free tools site. If you're using the config diff tool and you see an unfamiliar command in the output, you can click a button and ask the assistant about that specific line without copying, pasting, and switching tabs. Same with the IOS to NX-OS translator — if a conversion comes out and you want to know why, the assistant is right there.

The testing reality check

Building the MVP was the easy part. Testing it revealed six distinct bugs I had to chase down — edge cases where the widget didn't load cleanly, contextual buttons that didn't pass the right information, UI states that broke on mobile. That's the part of shipping real products that doesn't show up in demo videos. You build something that works in your head, then you actually use it for a few days, and you find everything that's wrong with it.

I don't think AI tools are magic. They're software, and software has bugs. The difference between an AI product that feels polished and one that feels frustrating is usually dozens of small bug fixes after the initial launch.

Why this matters for teams, not just individuals

The reason I built this isn't just to put another free tool on the internet. It's because the same pattern — a focused AI assistant with real domain knowledge, embedded where people actually work — applies to everything I do for clients.

Most of the automation projects I'm building for businesses right now follow this pattern. Take a workflow that currently requires a specific expert. Build an AI assistant that knows that domain deeply. Embed it in the tools people already use. Suddenly the junior engineer can answer questions that used to require a senior's attention. The senior engineer gets their afternoon back.

That's the real leverage. Not replacing expertise — amplifying it, and making it available at the exact moment someone needs it.

Want one of these for your team?

If you've got a workflow or a toolset where your team keeps asking the same specialized questions — and the expert who knows the answers is a bottleneck — that's exactly the kind of problem I build AI assistants to solve. Reach out via /ai-assistant or /contact and we can talk through what it would look like for your business.

By this morning I had roughly fifty active projects on my Mac Mini. Some were genuinely useful — a few are paying clients, a couple are the kind of internal tooling I rely on every day. But a lot of them were just... there. Running launchd jobs nobody opens. Dashboards on ports I haven't visited in months. Three different tools that all generate Cisco config diffs because I kept building "the right one" instead of finishing one.

If you've been writing software for any length of time you know this feeling. The folder of side projects that started with energy and ended with neglect. The "I'll come back to this" that turned into "what was this for, again?"

This afternoon I cut a third of it.

What the audit actually looked like

I asked four exploration agents to run in parallel — each taking a slice of the portfolio (revenue and apps, networking, gambling and investments and personal, infra and clients). For every project they found, they pulled the last commit date, checked whether anything was running, looked at recent log activity, and made a recommendation: keep, fix, pause, or archive.

This is the part the discourse around AI-augmented development tends to skip. Everyone wants to talk about how fast you can ship a new thing. Almost nobody talks about how fast you can audit what you already have. They are the same skill applied in opposite directions, and the second one matters at least as much.

By the time the four reports came back, the picture was sharp. About fifteen projects were genuinely active — they earn attention or money, they're being touched, they have a visible reason to exist. The rest fell into three buckets: paused with a clear unblock condition, decisions I'd been avoiding, or simply dead weight.

What I learned from the dead weight

The networking category was the worst offender. Eleven projects in there overlapped with each other. Three different tools to do config diffs. Two to validate device configs. A standalone topology generator that does roughly what one of the others can already do. Each of them was, in its moment, the right call. The problem is the moment passes, and the project lingers.

The pattern that finally became obvious is this: I tend to build slices of a problem until I eventually understand the problem well enough to build the substrate. The substrate replaces the slices. But the slices don't archive themselves. They sit there with their own launchd jobs, their own ports, their own forgotten READMEs. This morning a tool I shipped two days ago — an analyst that reasons over network captures and intent docs — quietly subsumed seven of those slices. They could go.

What the audit caught that I'd missed

Three things, embarrassingly:

A trading bot was bleeding money. Real money, on a real exchange, with insufficient-funds errors stacking up in the logs every day. Nobody told me. The audit pulled it up immediately and I shut it down within ten minutes.

An OAuth pipeline I thought was working was silently failing every five days. The fix needed a separate path that I wouldn't have found without forcing myself to look.

And my own infrastructure docs were lying to me. A service was listed as "healthy" in the project root file even though it hadn't been running for weeks.

None of those were going to surface during normal work. They surface when you stop building long enough to look around.

I caused one of my own outages along the way

It would be dishonest to skip this part. While archiving the scraping project, I moved a launchd plist whose label was com.cloudflare.scraping-api. Read the name; assume it does what it says. It did not. That single plist was actually running my main Cloudflare tunnel — every public hostname I host, including my own website — and when I archived it, all of those hostnames went dark for about thirty minutes before I noticed.

I fixed it, restored the tunnel, and saved a note in my memory system so the next audit doesn't fall for the same misleading name. That is the loop. You break things, you write down what broke and why, you don't break it the same way next time.

What's left, and why it's enough

The fifteen projects that survived the cull are the ones I actually care about — the site you're reading right now, a handful of public tools, two newly-shipped internal assistants, an active client engagement, and the work I do for a Fortune 50 telecom on the side. The rest is paused with clear conditions for revival, or archived with the option to bring it back.

If you've been watching your own folder of half-projects with a vague sense of guilt, I'd recommend the audit. Not as a shame exercise — as a clarity one. AI is very good at building. It's also very good at telling you what's already there. Most of us under-use the second one.

The hard part is being willing to look.

Every network engineer knows the specific flavor of dread that comes with modifying an access-control list on a remote switch. You're connected to that device over the very management path you're about to change. Get the order of operations wrong, and you lock yourself — and everyone else — out of a switch sitting in a building hundreds or thousands of miles away. Now multiply that across an entire fleet, where some devices already have the new rule, some have the old one, and some have neither.

That was the situation on a client project this past week. A block of trusted management addresses needed to migrate to a new range across a large fleet of switches spread across many sites. The old way to handle this is exactly what you'd imagine: an engineer logs into each device by hand, checks the current state, types the change, verifies it, saves it, and moves to the next one. It's slow, it's mind-numbing, and the boredom is precisely what produces the mistake that takes a site offline.

If there's one lesson I keep coming back to, it's that the dangerous changes are the ones worth automating first — not because they're frequent, but because the cost of a human slip is so high.

Building the safety in first

So I built a tool to do it, and I built the safety guarantees before I built anything else.

The first principle was simple: never create a window where a device can lock you out. The tool always adds the new permission before it removes the old one, and it only removes the old rule after it has confirmed the new one is in place and working. There is never a moment where a switch has no valid path back in.

The second principle was that nothing destructive happens until a human has seen exactly what would happen. The tool defaults to a dry-run. It sweeps each site, discovers which switches are actually reachable, reads the current state of each one, and produces a clear report: which devices are already compliant, which need the change, and which are in some unexpected state that deserves a human's eyes. Green means leave it alone. Amber means it needs work. Nothing changes on the network until someone looks at that report and flips the switch to live.

The third principle was that the tool should be safe to run a hundred times. It keeps a running ledger of what it has already done, so a device that's already been brought into compliance simply gets skipped on the next pass. You can stop halfway through, come back the next day, and pick up exactly where you left off. And because that ledger can live on a shared drive, a whole team can run the same tool from different laptops and see each other's progress instead of stepping on one another.

How it actually went

We didn't trust it blindly. The rollout followed the same pattern I'd use for any high-stakes change: dry-run first, then a single canary site, then production. At the canary site the tool found twenty reachable switches, confirmed thirteen were already compliant, and cleanly remediated the seven that weren't — preserving the thirteen it didn't need to touch. The production run went the same way. No lockouts. No outages. No 2 a.m. phone calls.

What used to be a multi-day, all-hands, hold-your-breath manual slog became a job you kick off, watch a report from, and trust. The engineers got their time back, and — more importantly — the work got safer, because the part most likely to cause an outage is now handled identically every single time.

This is the work I love

This is exactly the kind of problem I think automation should be pointed at: not the flashy stuff, but the repetitive, high-consequence work where consistency matters more than cleverness. Take a task a skilled human does well but slowly, encode the safety rules they carry in their head, and let the machine handle the tedium without ever getting bored or careless.

If you've got a process like this — something repetitive, risky, and important enough that you've been doing it by hand because you don't trust a script with it — that's exactly the kind of thing I build. Take a look at what an AI assistant tailored to your operation can do, or get in touch and tell me about the change that keeps you up at night.

So for a recent project I tried stripping it all away. No app. No signup. No onboarding flow. Just a phone number you can text like you'd text a friend.

The whole interface is a text message

I'll admit I wasn't sure how it would land. Texting feels almost too simple to be a "product." But that turned out to be the entire point. Everyone already knows how to send a text. There's no learning curve, no menu to figure out, no settings page to ignore. You think of something, you type it, you hit send. The bar for using the tool is the same as the bar for texting anyone else.

That low bar changes the kinds of questions people are willing to ask. When there's friction, people save a tool for the one thing they think it's "for." When there's no friction, they just reach for it whenever something comes up.

People used it for things I never planned

This is the part that genuinely surprised me. I had a rough idea of what the assistant would get asked about, and within a few real conversations people had blown right past it.

One person used it to look up event and concert information. The same person, in the same conversation, asked it to help troubleshoot an account problem they were having. Then they switched gears entirely and asked it to help diagnose why their hot water heater wasn't working. And at some point they stopped typing altogether and sent a voice note instead, just to see if it would handle that too.

None of that was scripted. I didn't build a "home repair mode" or a "concert mode." There are no modes. People simply treated it like a capable assistant that could be pointed at whatever was on their mind that day, and it kept up.

That, to me, is the real takeaway. The interesting thing isn't any single task it can do. It's that the same assistant handled event planning, account support, and a plumbing problem in one thread without anyone telling it to switch gears. The generality is the feature.

Why a general assistant beats a single-purpose bot

We've all texted a "bot" that only understands three commands and gets confused the moment you go off-script. Those aren't really assistants, they're menus wearing a costume. The moment your actual question doesn't match one of the buttons, you're stuck.

What I wanted was closer to having a knowledgeable person on the other end of the line. You don't have to phrase things a special way. You don't have to know which "department" your question belongs to. You just ask, and it figures out what you need and does its best to help. When it works, it stops feeling like software and starts feeling like a front door that happens to always be open.

For a business, that front door is worth a lot. It can answer the common questions instantly, at any hour, without anyone staffing a chat window. But more importantly, it handles the long tail, the weird one-off questions you could never anticipate or build a dedicated flow for. Those are usually the questions that would otherwise go unanswered, and they're often the ones that matter most to the person asking.

I came away from this one more convinced than ever that the future of this stuff isn't a wall of dashboards. It's a simple, familiar way to ask for help, backed by something genuinely capable enough to deliver.

Want one of these for your business?

If the idea of customers, members, or your own team being able to just text a question and get a real answer sounds useful, I'd love to talk about what that could look like for you. You can see more about how these assistants work over at /ai-assistant, or reach out directly through /contact and tell me what you're trying to make easier. I read every message myself.

That sentence is either marketing fluff or the most important shift in how work gets done this decade. I think it's the second one, so here's exactly what happened and you can decide for yourself.

The founder's real problem

The client is the CEO of a growing consumer brand. No IT department — he is the IT department, and he's the first to tell you he isn't technical. His problem is every founder's problem: too many open loops, an inbox that owns him instead of the other way around, and no one whose entire job is making sure nothing important falls through the cracks.

A bigger team is the usual answer. It's also expensive, slow, and adds its own management overhead. So we tried a different one.

Not a chatbot — a chief of staff

The thing we built for him isn't a novelty that answers trivia. It reads his email and sorts it into what actually needs you versus FYI versus noise — with a one-line reason on every call, and it never moves or deletes a thing. It knows his calendar. Every morning at 7 it texts him his day, laid out. And he interacts with it the way he'd talk to a person: by text message. No app to download, no dashboard to learn, no account to create.

That last part matters more than it sounds. The bar for using it is the same as the bar for texting a friend, which means he actually reaches for it.

The part that makes it feel alive

The piece we added tonight is the one that turns a tool into a teammate: memory. Now when he tells it something — who his key people are, how he likes things handled, what he's chasing this quarter — it remembers, and every answer after that gets sharper. Most "AI assistants" are goldfish; they forget you the second the conversation ends. This one doesn't. That difference is the whole game.

I didn't build it by typing code

Here's the part I want you to sit with. I didn't wire any of that up tonight by hand-writing code at a terminal. I built it by telling my own AI assistant what I wanted — from my phone, between drinks — and it did the work: the integrations, the security, the deployment. When something got blocked, it found another way in. I wasn't doing the labor. I was directing it.

That's not a party trick. That's the new shape of the work.

The deal that just changed

For most of my twenty-six years in this field, the deal was simple: if you wanted the outcome, you needed the specialist who could personally do the thing. Wanted a network automated? Hire the network engineer. Wanted software? Hire the developer.

That deal is quietly ending. The people who win the next decade won't be the ones who can do everything themselves — they'll be the ones who know exactly what they want and can direct capable systems to build it. Taste, judgment, and knowing what "good" looks like go up in value. The grunt work trends toward zero. The bottleneck stops being can someone build this and becomes does anyone know precisely what should be built.

If this is you

If you're a founder drowning in your own operation, you probably don't need a bigger team. You need one sharp system that actually knows your world and takes the load off — built around you, not around a generic template.

That's what I do now. And apparently I can do it from a bar.

It sounds like the kind of thing you should be able to answer in an afternoon. Pull the data, count the hosts, done. It turned out to be a great case study in why one-off answers to network questions are usually wrong, and why the real deliverable is almost never a report — it's a reporting system.

The first answer was wrong

The obvious approach is to take a snapshot of which devices are talking on each segment and count. I did that. The first pass said dozens of segments were completely dead.

Except they weren't. Two things were lying to me.

First, the tables I was reading from age out. Devices that were active a few hours ago simply vanish from the data. A snapshot taken at a quiet time of day isn't the truth — it's a low-water mark. If you make decommissioning decisions off a single quiet-hour snapshot, you're going to break things for real users.

Second, the opposite problem: some segments looked alive when they weren't. The firewalls on this network respond on nearly every segment as part of normal plumbing, so a naive count sees "activity" everywhere. I had to teach the tooling to recognize infrastructure noise and filter it out, so the numbers reflected actual users rather than the network talking to itself.

Once both corrections were in, the picture got crisp: roughly forty segments with thousands of real users on them, about thirty segments provisioned but sitting empty, and one that was genuinely dead. That's an actionable answer instead of a misleading one.

One report became a pipeline

Because a single snapshot can't be trusted, the answer had to come from trends. So instead of handing over a document, I built an automated pipeline: new data drops into a folder, and a self-contained interactive report regenerates itself — latest picture, full history with trend lines for every segment, and per-site drill-downs.

The part I like most is the callouts. The report automatically flags which segments newly came alive since the last collection, which ones went quiet, and which moved the most. Some segments turned out to have a daily rhythm — busy during working hours, silent overnight — which is exactly the kind of thing a single snapshot can never show you and a trend line makes obvious.

The feature nobody asks for: refusing to report garbage

Midway through, one data collection came back silently broken. Stray formatting in the input had truncated things upstream, and the raw output looked plausible while containing almost nothing. An earlier version of the tooling would have happily rendered a beautiful report announcing that the entire network was unused.

That's the failure mode that scares me most in automated reporting — not crashes, but confident nonsense. So I built validation in front of everything: the pipeline now counts what it actually received, checks coverage against what it expected, and if the input is broken it says so with a big warning instead of producing a plausible-looking page of zeros. Later in the week that guard earned its keep a second time, catching an incomplete collection before it could contaminate the historical trends.

Why this matters beyond one network

The pattern here isn't really about networks. It's about any recurring operational question: the first honest answer is usually "it depends on when you ask," the raw data lies in at least two directions, and the valuable thing isn't the analysis — it's an automated system that repeats the analysis, tracks change over time, and knows when its own inputs can't be trusted.

That last part is where most homegrown reporting falls down. Anyone can generate a dashboard. Building one that tells you when it shouldn't be believed is what makes it safe to act on.

If you've got operational questions like this — data you're sitting on but can't quite trust, or reports someone regenerates by hand every week — this is exactly the kind of thing I build. Take a look at what I'm doing with AI-assisted automation, or get in touch and tell me about the question you keep having to answer manually.

At some point I did the math on reviewing it by hand. Eight hours a day of reading configs, every day, and I'd finish one full pass sometime after the closing ceremony — and I'd have caught almost nothing, because nobody notices which of nine hundred nearly identical lines is missing.

So I stopped reading configs and started querying them.

That's the whole idea behind this series: the network had to become a dataset. Collect everything, normalize it, ask it questions. I don't think this network gets built any other way — not with more people, and not with more hours.

First, get the data at all

The environment was the kind where the answer to every automation question is no. The only path to the devices was a locked-down jump host. No internet. No scheduled jobs. No automation libraries. No SSH keys. Every "just use an API" answer was off the table on day one.

The workaround was to stop fighting the constraint. I generate terminal-emulator scripts — a scripted version of what a person at a keyboard would type — that crawl the whole fleet through the jump host and capture everything. A simple file bridge carries the captures out to the machine where the analysis runs. The restricted zone only ever sees a plain script and a text file; all the intelligence lives outside it.

It's low-tech on purpose. That one layer turned "you can't automate here" into a fresh full-fleet snapshot whenever I wanted one. Every tool in the rest of this post runs on top of it.

The switch someone walked away from

The first real test was dozens of venue core switches that were all supposed to match one reference build. Diffing each one against the golden config doesn't work — every site legitimately differs in about eighty places, so the real problems drown in expected noise.

The tool parses every config into sections, normalizes the site-specific values away, and scores each switch two ways: against the reference, and against what the majority of its peers are running. The output is a ranked workbook, worst switch first.

The first run flagged a switch missing its router-ID loopback, seventeen telemetry subscriptions, and twenty-odd monitoring lines — a build somebody walked away from in the middle and never came back to finish. The switch was up, passing traffic, green on every dashboard. No amount of reading finds that. The tool found it in seconds and put it at the top of the list with the exact missing lines attached.

No golden config? Let the fleet judge itself

The next question was harder: what's missing or extra on each switch compared to all the others — with no reference config at all.

The answer was consensus. Union every config element across the fleet; anything on seventy percent or more of the devices is the de facto standard. Then, per device: which standard things are missing, which extra things are present, and where shared config drifts line by line.

That run turned up a whole subset of switches still on an older build template, missing the MPLS and management-hardening pass everyone else had received. Not one finding on one box — a class of inconsistency, identified across the fleet at once, with the member list attached.

The same pass cross-checks every configured IP address against the IP-management database, which produced my favorite finding of the whole build: gateways that disagreed with the live config at every single site. When one device disagrees with the database, the device is probably wrong. When every device disagrees the same way, the database is wrong. You can only see that from the fleet-wide view.

The IP database itself got the same treatment — generated and validated programmatically, then backfilled with hostnames and serial numbers from the monitoring system's own exports, with a perfect match rate. It stopped being a spreadsheet someone typed and became a mirror of the actual network. That mattered because every other tool checks against it.

Routing config got a structural comparison too, built to separate real divergence from expected per-site differences. That's the run that caught one of two redundant route reflectors filtering an entire address family toward its clients while its twin didn't — an asymmetry sitting quietly on the backup control-plane path, waiting for a failover to matter. Nobody reads their way to that one either.

Then keep going

Once the collection layer exists, each new audit is cheap. Per-interface config comparison across the fleet. Discovered neighbor relationships validated against the cabling plan — miscabling found without a truck roll. A management-ACL sweep that found out-of-spec devices and then safely remediated them live. A hunt for ports stuck in a suspended state — the kind of thing that bites on game day. A WAN reachability matrix that turned "is it up?" into a grid. Health reports for the out-of-band paths, so you find out the backup path is dead before the day you need it. Staging new devices became a generated script instead of tribal knowledge.

None of those was a big project. The expensive part — getting trustworthy data out of a locked-down environment into a normalized form — was already paid for.

From reports to dashboards

A report that runs once answers yesterday's question, and this build changed daily. So the one-shot reports became a pipeline: scheduled collection through the jump host, results into cloud storage, and a dashboard that ingests each run, diffs it against the previous one, and emails when something regresses. A nightly watcher re-runs the validation suite and reports anything new. Config drift, routing comparison, WAN reachability — all of it became something the team glances at, instead of something someone has to remember to run.

That's also what turned cleanup into a number. The audits had found hundreds of drift items, and "are we getting better?" was a feeling until every finding got scored across crawl rounds: resolved, new, or unchanged. One wrinkle made the scoring interesting — a config class was being deliberately retired, and naive scoring counts planned removals as new drift, which is backwards. It had to learn that decommissioning is progress. With that fixed: about two-thirds of the findings resolved within the first weeks, everything left ranked, and cleanup status became a chart instead of a meeting.

The last box to check before the event was proving the pipes themselves. Dozens of venue servers needed demonstrated bandwidth before real traffic arrived — through the same locked-down access path as everything else. The same scripting harness drove a throughput-test mesh across them and parsed the results into a per-venue baseline: a signed "the network does what we promised" table before day one. It even caught a mistyped test-target address at one venue before it could pollute the numbers.

What made it work

Everything above is the same three moves. Collect everything programmatically. Normalize away the differences that are supposed to exist. Use consensus — against a reference, against the fleet, against a source of truth — to rank what's left.

That combination beats headcount. More people reading configs mostly produces confident sign-off on the same misses. The half-built switch, the older-template subset, the asymmetric route reflector — none of them get caught by reading harder. They get caught by turning the network into data and asking questions nobody would think to ask, across a fleet nobody can hold in their head.

Then the event started, and the same collection layer built for auditing turned out to be the fastest troubleshooting tool on the network. Traffic that vanished into the core. A dashboard showing a collapse that never happened. A transfer failure that ate weeks until the data cornered it in an hour. Those stories are Part 2.

If you've got a system too big to eyeball — a review process that's really a formality, a question you keep answering by hand — this is the kind of thing I build. Have a look at what I do, or get in touch and tell me what you've stopped being able to read.

Then the event started, and the tooling changed jobs.

During the build, a finding meant a task on a punch list. During the event, a finding means something is wrong right now, with a stadium full of people on the network. I half expected the audit tooling to go quiet in this phase. Instead it turned out to be the fastest troubleshooting tool we had, because the questions that matter in an incident — what changed, what's different about this one device, which layer is lying — are questions the dataset could already answer.

Here's what that looked like.

One service, one venue

One service VRF at one venue lost internet access. Everything else stayed green: every other VRF at that venue worked, and the same VRF worked everywhere else. A one-cell failure in a grid of hundreds.

A monitoring dashboard caught it inside fifteen minutes — not a user complaint, the dashboard.

The debugging that followed never guessed once. A staged capture script pulled state from each layer in turn, and the comparison data from the build phase ruled layers out one at a time. The venue switch matched fleet consensus, so it wasn't local config. The route reflectors were advertising what they should, so it wasn't the control plane. The VPN transport checked out, so it wasn't the core. About an hour in, exactly one place was left that could drop that one service — a central firewall, where the BGP session for that VRF turned out to be down.

The part I keep thinking about happened the same evening. The monitor that caught the symptom had been watching one thing. By that night it was watching roughly seventy — every service VRF at every venue, tested from inside the VPN, with the target list generated straight from the config crawl. Nobody typed seventy targets into a file. The dataset already knew them.

Symptom in fifteen minutes. Layers eliminated in an hour. Fleet-wide coverage by dinner.

Traffic that vanished into the core

The nastiest one was intermittent. Traffic inside the MPLS core would occasionally vanish — flows blackholed for a stretch, then fine again, with healthy-looking devices on both ends.

The problem with intermittent faults is that the evidence leaves before you arrive. By the time someone logs in, the state that mattered is gone, and you're staring at a healthy device wondering what you missed. The answer wasn't cleverness, it was preparation: a capture script, staged in advance, that grabs the full forwarding-plane state of the suspect path in seconds the moment an occurrence starts. Typing those commands by hand takes long enough that the fault heals while you work. The script doesn't have that problem.

It took more than one occurrence to catch it with full state in hand. Once we had that, the cause fell out: after a supervisor failover on a core device — one configured for graceful restart — some of the label-forwarding state had gone stale. Traffic was following labels toward a path that no longer existed. Everything upstream looked fine, because upstream everything was fine.

The payoff isn't just the root cause. It's what got left behind: a runbook, so the next occurrence is a procedure instead of a scramble; the capture script, staged, so catching it in the act takes minutes; and a per-second path-health dashboard — stood up during the incident itself — watching those paths live.

The transfer that only sometimes failed

File transfers from one external partner kept dying mid-session. Everything else was green. This is the classic ticket that eats weeks — "sometimes it works" means every successful retry resets the clock, and no single failure leaves enough evidence to work from. It had, in fact, eaten weeks.

Approached as a data problem, it took about an hour to corner. Staged captures plus the config and routing data already on hand eliminated each layer in turn, same as the VRF hunt. What was left: the flow's forward path and return path had diverged. An internal routing session had been removed at some point, and after that the traffic went out one way and came back another — with a stateful firewall sitting on only one of the two paths. It saw half of every conversation, and it did what stateful firewalls do with half a conversation: eventually killed it. Mid-transfer.

That's a named root cause and an identified fix — restore the removed session so the paths converge again — argued entirely from data. Getting a fix through the change process on a network this locked down is its own timeline, and I won't pretend the ticket closed that afternoon. But there's a difference between "transfers sometimes die" and "this session was removed, and this firewall now sees half the flow." One circulates. The other is a change request someone can approve.

Path symmetry had been an assumption. It turned out to be a property you can test for, from data already collected.

The collapse that never happened

One morning a dashboard showed traffic at a core device falling off a cliff. That's the graph that starts a bridge call.

This time the data's job was to interrogate the monitoring itself. Before anyone escalated, I pulled the raw poller samples behind the graph and reconstructed what the sampler had actually seen, poll by poll. The dramatic collapse came down to a single poll — one bad sample, stretched into a cliff by the way the graph renders between points. The device was fine. The traffic was fine. The graph was wrong.

Later the same interrogation cut the other way. A quieter change on the same views held up under the same scrutiny — sustained across polls, visible from more than one angle, not an artifact — and that one earned the attention. It's still being run down, but it's being run down because the samples say it's real, not because a graph scared someone. Same method, opposite verdicts: a fake collapse dismissed with evidence, a real change escalated with evidence.

The rest of the shift

Not everything was a mystery. Some of it was just coverage.

Some venues have their own direct internet breakout, which puts them outside the central scrubbing path — an attack on one of those edges wouldn't show up anywhere anyone was looking until users felt it. The fix was a read-only poller: sample the edge counters over SSH on a schedule and alarm on attack-shaped deltas rather than absolute numbers. Zero config changes on the devices, no change window requested. Visibility at the venues nobody was watching, built without touching anything.

Changes kept landing during the event, and "the change looks fine" is not verification across dozens of devices at two in the morning. So verification became a table: crawl after the change, diff against the state from before it, score every device against the change's stated intent — took, didn't take, or side-effect. Known benign mismatches are documented instead of hand-waved. The process even caught a false-positive class in the checker itself, which is exactly the kind of thing you want a checker to admit about its own output.

Underneath all of it, the nightly sentinel from Part 1 kept running: re-run the validation suite, report anything new. During the build, new drift was a to-do item. During the event, new drift is a risk — something changed that nobody announced — and the sentinel notices before people do.

And when a weekend outage did happen, the postmortem came from the same place everything else did. The analysis — including a full port-level map of the inter-core links — was reconstructed from collected state, not from memory or a stale diagram, and the report shipped the same week.

The same data, a different job

Every story above starts at the same place: a current, normalized snapshot of the network that existed before the incident did. Nothing here required building a collection system under pressure. The layer built to audit the network — the one that found the half-built switch and the asymmetric route reflector in Part 1 — is the same layer that found the dead BGP session, the stale labels, the diverged paths, and the poll that lied. That's the whole series in one line: the dataset that built the network is the dataset that defends it.

If you're running a system where every incident starts from zero — pull logs, ask around, hope somebody remembers how it's cabled — this is the kind of thing I build. Have a look at what I do, or get in touch and tell me about the last ticket that ate weeks.

About a minute later my phone buzzed with an approval request: what was changing, which device, how big the diff was, the risk level, and how it would roll back. I replied Loop YES 6j5fm. The change went onto a real Cisco Catalyst 9200 with a five minute auto-revert timer armed, seven checks passed, the timer was cancelled, and the documentation updated itself.

Here is the whole thing, start to finish:

That's a real run against real hardware. The long waits are compressed, and captions and narration are laid over the top, but nothing in either pane is a mockup.

What the loop actually does

You give it an intent in ordinary language. The AI reads the current state of the network from the source-of-truth system, which in my case is NetBox, and drafts a minimal plan. Then it stops and asks a person. It does read the live device before that point, to check its own plan against reality, but nothing is written to a device without a human reply.

Once approved, the change deploys with an automatic rollback timer. If a check fails, the change comes straight back out, either because the loop reverts it or because the timer on the device does it anyway. Post-checks verify both the thing that changed and the things that were supposed to stay the same, including whether I can still reach the switch at all. Finally the results are written back to documentation with an audit trail: what changed, when, who asked, who approved, and what proved it worked.

Being honest about "validation"

I want to be precise here, because this is where a lot of automation writing gets vague.

On some platforms you get a genuine dry run. My lab routers run SR Linux, which will load a candidate config and tell you whether it's valid before you commit anything. If the device rejects it, the loop stops and no change is ever attempted.

Cisco IOS-XE has no CLI equivalent. There's no exec-level "validate this config but don't apply it." It can expose a NETCONF candidate datastore that would give you something close, but that's switched off on this switch, and I'd rather build the loop so it doesn't depend on a feature I'd have to go turn on.

So on the Catalyst the loop does something different, and I think it matters not to blur the two. Every generated line is checked against an allowlist of permitted change types, which is default deny: a line nobody anticipated is refused because it was never allowed, not because someone remembered to ban it. Then against a denylist of things it must never touch, the management VLAN and the uplink and authentication and the rollback mechanism itself. Then against live read-only queries to the switch confirming the VLAN really is free and the interfaces really do exist.

What the approval text itself carries is the intent, the devices, the size of the diff, the risk, and the rollback plan. Not the config. I cap that message at 450 characters and a diff doesn't fit in one, so the literal lines live in the audit record instead.

Different platforms give you different guarantees, and pretending otherwise is how people get surprised at 2 AM.

The part I'm most proud of is the failures

The first end-to-end runs in the lab did not go cleanly, and that turned out to be the most useful thing that happened. One run deployed, failed a post-check, and rolled itself back automatically. Another got rejected before it touched a device at all. A third passed everything and landed.

Later I had an AI agent deliberately sabotage a post-check on the real Catalyst to prove the rollback wasn't theoretical. The change came straight back out, the resulting config was byte-for-byte identical to what it had been before, and a ping running through the whole exercise didn't lose a packet. Worth being exact about which mechanism did that: the loop reverts immediately when a check fails, and the timer on the switch is the layer underneath, there to revert anyway if the loop itself dies mid-change.

The most useful thing in any of those records is something I wasn't looking for. The lab run that reverted itself had re-encapsulated the link between the two devices, so I'd written a check to prove the existing point-to-point link across it kept forwarding. It passed while the change was live. After the revert, it failed. Maybe the link just needed longer to come back, maybe the revert left it down; the record doesn't say, and that's exactly the point. Putting the configuration back is not the same as knowing the network is back, and I'd much rather have found that in an audit file on a bench.

An automation system that can only show you its successes is a demo. One that fails safely, on purpose, in ways you can read about afterward in the audit trail, is something you can start to trust.

Approving changes from my phone

The approval gate runs over text message, which means the deploy button is my thumb, wherever I happen to be.

Everything that isn't a clean yes is a no. A reply with the wrong change ID is ignored. A message from a number that isn't mine is ignored. No reply inside the window and the change simply doesn't ship. It respects quiet hours, so it won't wake me up for something that can wait until morning. If it can't even send the approval request, that counts as a denial rather than an excuse to proceed.

The gate fails closed in every direction I could think of, and then an AI critic went looking for the directions I hadn't thought of.

An AI that gets audited, not one that grades itself

Every substantial build here now gets a second AI agent whose only job is to break the first one's work: run it, probe the edges, attack the happy path.

On this build the critic earned its keep immediately. It found that two approval requests running at the same time could interfere with each other, which is now a documented constraint rather than a surprise. It also caught a subtler one: the text you receive claimed the config had been "validated in a dry run" even on the Cisco path, where, as above, the loop doesn't do one. That's exactly the kind of small dishonest phrase that erodes trust in a tool, and it came from the machine, not from me.

An AI that grades its own homework is not the same thing as one that gets audited.

Why I'm building this

Most network outages don't come from hardware. They come from changes: rushed ones, undocumented ones, changes where the plan in someone's head didn't match the actual state of the network.

The goal isn't to take the human out of the loop. It's to shrink the human's job down to the part a human is genuinely needed for, the judgment call, and to wrap that decision in validation, rollback timers, post-checks, and an audit trail that writes itself.

Two more things worth stating plainly. This runs in my lab and against one real switch on my bench, not across a production estate. And the planning step calls a cloud model today, which means the device and prefix inventory for the site goes out with the request, management addressing included. I have a local model prototyped and measured for that job precisely because not everyone will want the first answer, but prototyped is not shipped, and which one you'd want is your call rather than a default I get to pick for you.

Nothing about the pattern is lab-specific, though. Plan, prove, ask, deploy with a net, verify, document. That shape works for network changes, and it works just as well for plenty of business workflows that have nothing to do with networking.

Curious what this could look like for you?

If this sounds like the kind of automation you've wished existed for your own network or operations, careful, safety-first, and honest about its failures, I'd be glad to talk. You can see more of this work on the Loop, or get in touch and tell me what you're trying to automate.

Corrections, added after publication. Five claims were wrong: four in the version I first posted, and one I introduced while fixing those. I found them by pointing a second AI agent at my own post with instructions to refute it against the actual run records, which is the same builder-and-critic pattern the post describes. In a piece arguing that automation should be honest about what it can prove, listing them seems like the minimum.

1. I wrote that IOS-XE has no way to validate a config without applying it. It has one, a NETCONF candidate datastore, which happens to be switched off on this switch and which the loop doesn't use. That is a narrower claim and the section above now makes it. The code comment that led me into this was wrong too, and is fixed.
2. I wrote that the approval text shows the literal commands. It shows a summary and a line count. The literal lines are in the audit record.
3. I then wrote that those lines are printed to the console. Under the text-approval gate they aren't, only counts are. Audit record only.
4. I wrote that nothing reaches a device without a human reply. The loop does read the live device before the gate, to check its plan against reality. Nothing is written without a reply, which is the claim I should have made.
5. I wrote that the switch reverted itself on the timer during the sabotage test. The loop commanded the revert as soon as the check failed; the timer is the layer underneath it, for the case where the loop itself dies.

That's the part nobody talks about. A summary isn't the same as understanding. The built-in AI on your calls can tell you what was said. It can't tell you that the thing the other person mentioned in passing is actually the third time they've raised it, or that it connects to a deadline two weeks out, or that it's the exact follow-up you promised someone else last month. It has no memory of your world. So you still end up doing the real work: re-reading the transcript, pulling out the action items, deciding where each one belongs.

Earlier this summer I started building something to fix that for myself, and the difference in the output has genuinely surprised me.

The problem isn't transcription, it's context

The raw capability of turning speech into text is basically solved. You can get a clean transcript of almost any call or meeting now. That's the easy 80%. The hard 20%, the part that actually saves you time, is everything that happens after the transcript exists.

What I wanted was an assistant that already knows my projects, the people I work with, and the open threads I'm tracking, and reads each conversation through that lens. Not "here are five bullet points," but "here's what mattered, here's how it connects to what you're already working on, and here's the thing you said you'd do that you'll absolutely forget by tomorrow."

The mental model I kept coming back to: I don't want a stenographer. I want a sharp assistant who was in the room, knows the backstory, and hands me a note afterward that's already half-actionable.

What it actually does differently

The system takes a call transcript and, instead of producing a standalone summary, processes it against everything else it knows about what I'm working on. The notes that come out are connected to the relevant project. Action items get pulled out and filed where they'll actually resurface. A passing comment that ties back to an earlier conversation gets flagged as exactly that. And for some calls it no longer needs a recording handed to it: it can join a video call directly (Google Meet, so far) and capture the audio itself.

The outcome is the part I care about. I'm not opening a transcript and a to-do list and a project folder and manually stitching them together anymore. The note arrives already knowing where it belongs. That's the whole game: closing the gap between "a thing was discussed" and "the right next step is captured and won't get dropped."

There's a nice side benefit I didn't expect: it's intentionally opt-in, call by call. It's not silently vacuuming up every conversation in the background. When I want notes on a specific call, I turn it on for that one. That constraint actually made the tool feel more trustworthy to me, not less: it's a deliberate "sit in on this one," not ambient surveillance of my whole life.

Why this keeps coming up in my work

I build automation systems, and the most common request I hear, in one form or another, is some version of "help me stop dropping things." People don't actually want more dashboards or more notifications. They want the small, reliable stuff handled (the follow-up that got promised, the detail that mattered, the thread that went quiet) so their attention is free for the work only they can do.

A notetaker that understands context instead of just transcribing is a small example of a much bigger idea: software that knows enough about your situation to be genuinely useful, rather than generically capable. That's the line I keep chasing. Generic is cheap and everywhere now. Useful is still rare.

I'm still refining this one, starting to test it against real calls and tuning where things get filed. But even early, it's already changed how I feel walking out of a conversation. The mental "okay, don't forget to write that down" tax is mostly gone.

Want something like this?

If you've got a workflow where things slip through the cracks (notes, follow-ups, handoffs, the stuff that lives in your head until it doesn't) that's exactly the kind of problem I like to solve. I build context-aware AI assistants and automation around the way you actually work, not the way a generic tool assumes you do. Take a look at what I do at /ai-assistant, or just get in touch and tell me what keeps falling through.

So I built an AI receptionist for appointment businesses. Its name is Riley. It answers every call, talks like a real front desk, checks your actual calendar, books the appointment on the line, and texts the caller a confirmation. It does this at nine in the morning and at nine at night, on the calls you cannot get to and the ones that come in after you have gone home.

You can call it right now. The number is (919) 823-2943. It is a real call, not a recording, pointed at a demo calendar. Book yourself a slot, give it your number when it offers the text, and hear exactly what your customers would hear. It takes about two minutes.

Here is a booking, start to finish:

What it actually does

Three things, in order.

It answers. Every call, no hold music, no voicemail box. You pick the voice that fits your business.

It books. In real time, against your real availability, in the system you already run. There is no new software to learn and no double bookings.

It follows up. It texts a confirmation the moment it books you, and the done for you setup adds the reminders and rebooking nudges that are built to keep no shows down.

The part nobody else says out loud

There is no lock in. Your calendar stays yours. Your greeting and your booking rules are written down in plain English where you can read them and change them. Your phone number ports out with you if you ever leave. You get one flat bill from us instead of four platform accounts to babysit.

A real person sets it up on your actual calendar, tests it on real calls, and tunes it. You never touch a dashboard.

What it costs

$500 to get started, which covers the full setup, a walkthrough for your staff, and your first month of service. Then $249 a month, everything included: the platform, the voice you chose, your dedicated number, 300 call minutes, monitoring, tuning, and the follow up automations. Past 300 minutes, calls bill at 35 cents a minute, and most businesses stay inside the base.

That is the whole price. No per seat add ons, no separate platform fees, no surprise line items.

Who runs this

Brody Networks is an AI operations practice. We run AI agents in production for real businesses, watching the work and pulling in a human only when one is actually needed. The receptionist is that same discipline pointed at your front desk.

If your business lives on its schedule and you are tired of losing callers to voicemail, call the receptionist and book yourself a demo, or email sales@brodynetworks.com and we will get you set up. Installed, tested on your real calendar, and answering your phone in about a week.