I joined Mateo Bervejillo on The Future of the Future for a conversation that started with how I got into technology and ended up touching almost every part of the work I am doing now at Bad Command AI: phone systems, AI voice agents, local AI, Mac software, and the product judgment you only really develop by building and operating systems while people are already depending on them.

Listening back, the useful thread is not the resume version of the story. It is not finance to engineering, Comcast to Take-Two, Vapor IO to founder, and then a clean startup arc. The better version is messier and more honest: I liked building things before I knew what kind of builder I was, then I had to learn the discipline of building things for other people, under real constraints, where reliability and usefulness mattered more than whether the work was technically interesting.

Tinkering Was the Start

In the interview I described the beginning as a love of building, tinkering, and learning. That started with BASIC, then Visual Basic, little tools, small automations, PC games, mods, and websites. At that age the goal was not noble. I wanted to get to the game faster, change the game, or make the machine do something that felt useful to me. That instinct never really left, but it had to mature.

The important shift happened when I stopped treating software as something I built because I could and started treating it as something that had to solve a problem for someone else. I said this pretty plainly in the episode: "you're building to solve a problem." That sounds obvious, but it is a real mindset change if your first love of software came from tinkering. You can build endlessly for yourself and still avoid the harder question of whether the thing is useful, understandable, durable, and worth someone else's time.

That is also why I talked about wanting to become a more disciplined programmer. I was coming from a business and finance background, learning through courses, certifications, and a lot of self-directed work because I wanted to earn the right to do the job properly. The credential was useful, but the deeper value was confidence: not fake confidence, but the kind that comes from learning patterns, best practices, and enough fundamentals that you can walk into the unknown without pretending it is simple.

Systems Teach Differently

The next part of the conversation moved into the work that shaped me most as an engineering leader. At Comcast, before reliability engineering was fully formalized in the way it is now, I worked around automation, change management, and systems that supported Xfinity Business and NBC Sports. Those were mission-critical environments, and the point was not to admire a dashboard. The point was to understand what changed, who needed to know, what signal mattered, and how quickly the right people could act when something degraded.

At Take-Two Interactive, the problem space changed, but the lesson stayed familiar. The work was about unifying mobile backends and supporting global games where player engagement had to happen in real time. At Vapor IO, the work moved again, this time toward AI data center infrastructure and low-level problem-solving around Nvidia GPUs. The common thread was scale, but scale is not only about traffic or machines. Scale means the system has enough surface area that unclear thinking becomes expensive very quickly.

That is the part of my background that matters most to Bad Command. I learned to respect systems by operating them, not by drawing idealized versions of them. When something is live, every simplification gets tested. Every handoff gets tested. Every hidden assumption eventually introduces itself.

When something is live, every simplification gets tested.

Telepath Started as a Routing Problem

The origin story for Telepath Voice AI Agents came from that same systems instinct. I had worked with SIP, RTP, VoIP, WebRTC gateways, and real-time voice systems earlier in my career, and then at Nvidia GTC I saw a lot of AI voice demos that sounded genuinely impressive. The agents sounded polished when everything happened from a computer, inside a controlled demo path. The question that bothered me was simpler: "what about phone calls?"

An AI voice agent is often described as speech-to-text, an LLM, and text-to-speech. That is true at the component level, but it misses the part that makes the product hard in the real world. Once you connect that pipeline to phone infrastructure, you inherit a messy, old, heavily iterated system designed for humans talking to humans. In the episode I called it a phone system that is "150 years old," and that is really the point. The hard part is not only making the model smart. The hard part is moving voice through unpredictable pathways with enough speed, fidelity, and observability that the experience still feels natural.

That was the original shape of Telepath: infrastructure that could bridge calls from SIP and RTP into AI voice agents, normalize the voice path, move packets quickly, and give businesses visibility into what actually happened across both legs of a call. Jitter, latency, mean opinion score, call legs, carrier behavior, provider behavior, handoffs between agents and humans; none of that is cosmetic. For voice AI, those details are the product.

The product has sharpened since that conversation. The hosted infrastructure idea was a necessary starting point because it exposed the real problem, but the more interesting direction became adapting the key pieces so Telepath could run from a Mac when the required parts are available locally. Apple Silicon changed the floor. A Mac already has capable local compute, the Apple Neural Engine, enough baseline memory to do useful work, and a platform that rewards tight native software. Telepath, as a macOS product, is still shaped by the routing problem, but the goal is now more direct: make AI voice agents practical, inspectable, and affordable without forcing every workflow through rented infrastructure forever.

That is also where the leadership answer in the episode matters. Curiosity and adaptability are easy words to make sound soft, but in a product like this they are operational requirements. If you say you want to support carriers, SIP providers, AI voice providers, agent handoffs, human transfers, and tools without making customers configure a science project, you have to keep asking whether there is a simpler path. That is what pushed the work toward standards, clearer interfaces, and the keep-it-easy principle that still shapes Telepath.

Shipping Changed Telescopo

The most personal part of the interview was not actually Telepath. It was the story about building the first version of what became Telescopo Markdown Studio. I built it for myself because I worked in Markdown, used Mermaid diagrams, wanted to learn Swift, and wanted a Mac app that fit the way I worked. It started as a thing I liked using, which is a dangerous place for a builder because your own taste can protect you from feedback for a long time.

Then I put it on Reddit, made it free, and heard from real users. The feedback was basically: "it's interesting, but it kind of sucks." That hurt because I liked the app, but the painful part was that they were right. It was janky in places. It needed more iteration. It needed to become less like a private tool that happened to be public and more like a real Mac app that other people could trust with their documents.

That feedback loop changed Telescopo. Nights, weekends, support tickets, feature requests, bug reports, and users who cared enough to be direct all pushed the app into better shape. Telescopo today is not only a Markdown viewer. It has grown into a native Markdown studio with split editing, rendered previews, Mermaid diagrams, LaTeX, document navigation, themes, local document intelligence, and a level of visual polish that came from taking the work seriously after it left my machine.

The Bad Command Thread

That is the real connection between Telescopo, Telepath, and Telefoto Headshots. They do not look like the same product category, but they come from the same operating pressure. Telescopo turns technical documents into a Mac-native reading and writing experience that feels good enough to live in. Telepath turns voice AI from an expensive cloud pipeline into something closer, more observable, and more practical on Apple Silicon. Telefoto for iPhone takes a complicated AI image workflow and makes it understandable for people who need professional headshots without learning the machinery underneath it.

The common idea is not that every product needs AI. The common idea is that software should hide the right complexity and expose the right controls.

In practice, that shows up differently in each product. Sometimes it means packet-level observability. Sometimes it means a better Markdown toolbar. Sometimes it means giving someone enough guidance to generate a profile photo they can actually use. The implementation changes, but the product responsibility does not.

Near the end of the episode, I gave the advice I wish I had followed earlier: do not be afraid to put the MVP or V1 into the world. I do not mean ship carelessly. I mean stop using perfection as a private excuse to avoid feedback. The real product starts when someone else uses it, misunderstands it, breaks it, complains about it, asks for something better, and gives you the chance to decide whether you actually care enough to improve it.

That is the part I want Bad Command AI to keep carrying forward. Build fast, but not cheaply. Be fearless, but not sloppy. Use Apple Silicon for real work, not marketing copy. Make local AI useful enough that normal people and small businesses can benefit from it. Ship Mac software with enough craft that speed, privacy, accessibility, and polish are treated as part of the same product conversation.

Listen to the Episode

The cleanest places to listen are the primary podcast platforms:

The show is also indexed on Listen Notes. I would treat that as a secondary directory listing rather than the main link, but it is still useful corroboration that the show exists across the broader podcast ecosystem.

For more context on the same operating philosophy, I wrote about the systems path behind Bad Command in Fifteen Years Where Latency Is the Product, and about the product direction behind Telepath in Why I'm Building Telepath.