I did not learn to think about systems from architecture diagrams, which probably would have frustrated me anyway. I learned from building and operating systems while people were already depending on them, which is a different kind of education. Systems look cleaner before they are real. On a whiteboard, every boundary is obvious, data moves in the right direction, services fail in ways you planned for, and ownership is clear. Then the system goes live, telemetry is incomplete, failures are partial, the thing that broke is not always the thing that is alerting, and someone is already waiting on the other side.
At Comcast, working around Xfinity Business Internet and NBC Sports, reliability was mission critical. The systems were large, operationally messy, and tied to things people expected to work without thinking about them. When something degraded, it rarely showed up as a clean single-cause failure, but instead manifested as obscure signals across networks, applications, data pipelines, vendor boundaries, and operational handoffs, usually while someone was already asking whether the issue was fixed yet.
That period changed how I thought about observability, and my main takeaway was that it was not so much about the visuals in a dashboard or the number of charts you could fit onto a wall-mounted monitor, but rather the way a team learned to see the system clearly enough to make a good decision under pressure.
I spent a lot of time building event-driven observability systems with Kafka, RabbitMQ, Redis, and Splunk. The tools you use do not matter as much as whether the system is designed to work with signals:
- collect
- interpret
- route
- act
- verify
Without this loop, telemetry becomes noise with better formatting, and everyone is just reacting to symptoms with more confidence than they should have.
When I moved into voice infrastructure at TelTech, working on systems behind Robokiller, the same lessons became even more obvious because voice has almost no patience for ambiguity. A web request can retry, a video can buffer, and a batch job can run again, but a phone call is already happening while you are trying to understand it. One-way audio, jitter, codec mismatches, carrier routing issues, and a few hundred milliseconds of delay are not abstract backend problems to the person on the call. They are the product feeling broken.
The part that stayed with me from voice was that the user experiences the whole system as one thing, even when the engineering work is split across spam detection, routing, SIP integration, carrier behavior, call state, media, and whatever else happens between two phones. Debugging those systems teaches you to respect edges, especially the edge between signaling and media, the edge between carriers, and the edge between what your system believes is happening and what the network is actually doing. A lot of engineering maturity is just learning not to confuse your internal model of the system with the real system.
At Take-Two and Zynga, the domain changed, but the underlying shape of the problem was familiar. Games have their own version of real time, and while the failure mode is different from voice, the user still feels latency immediately. When a player taps, the system has to respond. When an engagement event fires, it has to arrive while it still means something. I worked on backend platform systems for mobile games, including work connected to Garden Tails on Apple Arcade and Webby Award-winning titles like Two Dots, and I kept coming back to the same idea that systems are only useful if they can observe, react, and adapt quickly enough for the product they support.
Later at Vapor IO, the systems became more physical. Edge data centers are not abstract cloud regions where the hardware disappears into someone else's operating model. They are constrained environments with power, cooling, networking, sensors, and hardware behavior that you have to understand if you want the software to be honest. Synse, the telemetry platform I worked with there, helped monitor infrastructure across edge deployments, and that work eventually connected into AI infrastructure using NVIDIA GH200 Grace Hopper systems. When the hardware is expensive, power constrained, thermally constrained, and sitting closer to the edge of the network, observability stops being a nice operational layer and becomes one of the ways you keep the system alive.
What all of that taught me is that reliability, latency, observability, and hardware are not separate concerns. They are usually different views of the same system. Comcast made me take reliability seriously. Voice made latency impossible to ignore. Games made feedback loops feel like product mechanics. Edge infrastructure made the hardware visible again. I did not understand it this cleanly while I was doing it, because nobody does, but looking back the pattern is pretty obvious.
I talked through some of this recently on The Future of the Future, in an episode called "From Phone Carriers to AI Voice Agents And Back." The conversation covered the path from engineering into founding, the systems work behind Comcast, Take-Two, and Vapor IO, and the origin story of Telepath. You can listen on Spotify or Apple Podcasts.
That is how Bad Command AI ended up focused on native Mac software and local AI, even though on paper that might look like a strange turn after years of backend systems and infrastructure. With Telescopo Markdown Studio, I wanted to get better at building tools for macOS that were powerful, useful, and also fun to use. I had spent years caring about the parts of systems most users never see, but Telescopo forced me to care about the parts they feel immediately: how fast a file opens, how smooth a document scrolls, how a theme transition behaves, how local AI summarization fits into a reading workflow, and whether a tool can be technical without feeling dead.
A document viewer has latency too, just not the kind people usually put in an infrastructure postmortem. Opening a large PDF, rendering Markdown, drawing diagrams, switching themes, summarizing content, and scrolling through technical documents all teach the user whether the software respects their time. Telescopo became a way for me to take the same instincts and apply them to user experience, where the feedback loop is not an alert firing in Splunk but the feeling that the app either belongs on the Mac or it does not.
Telepath brings me back to voice, but through everything I have learned since. AI voice agents are real-time systems with product expectations, infrastructure constraints, and user trust problems all stacked together. The work is not only generating a response. It is live call state, SIP connections, local model performance, transcripts, deterministic workflow paths, tool calls, and enough visibility that the operator can understand what happened after the call ends. The reason Telepath makes sense to me is because it sits directly at the intersection of voice infrastructure, latency, local AI, and Apple Silicon.
What comes next for Bad Command AI is a more focused version of what I have been learning for fifteen years. Build systems close enough to the work that people can understand them. Take latency seriously because users feel it even when they do not describe it that way. Treat observability as part of the product, not just an internal engineering tool. Use the Mac as a capable machine in its own right, not just a thin client for someone else's runtime. And make the software powerful enough for real work without making it miserable to use.
That is the part I still care about. A good system should not be quiet because nobody knows what it is doing. It should be quiet because it was designed well enough that people can trust it.