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 shift for me 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.

What Operating Real Systems Taught Me

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. What connected those jobs for me was not just traffic or the number of machines. The systems had enough surface area that unclear thinking became 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, because once something is live, the simplifications, handoffs, and hidden assumptions eventually introduce themselves.

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.

In the episode I also talked about curiosity and adaptability as leadership qualities. Those words can sound vague, but Telepath has made them practical for me. If I want to support carriers, SIP providers, AI voice providers, agent handoffs, human transfers, and tools without asking customers to configure a science project, I have to keep looking for the simpler path. That pressure pushed the product 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.

How the Products Connect

On paper, Telescopo, Telepath, and Telefoto Headshots do not belong to the same product category. What connects them for me is the work of taking something technically complicated and deciding what the user should actually have to see. Telescopo turns technical documents into a Mac-native reading and writing experience that feels good enough to live in. Telepath makes voice AI more observable and practical on Apple Silicon. Telefoto for iPhone gives people a way to create professional headshots without learning the machinery behind an AI image workflow.

Across all three products, I keep trying to hide the complexity people should not have to manage without hiding the controls they actually need.

In Telepath, that can mean packet-level observability when a call fails. In Telescopo, it can mean putting the right Markdown controls where someone naturally reaches for them. In Telefoto, it means giving someone enough guidance to generate a profile photo they can actually use. The implementation is different each time, but I am still deciding which complexity belongs to the product and which complexity should stay out of the user's way.

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.

I want Bad Command AI to keep working this way. I want to move quickly without confusing speed with carelessness, use Apple Silicon where it makes the product meaningfully better, and make local AI useful to people and small businesses that should not need a data center or an enterprise contract to benefit from it. I also want to keep shipping Mac software where speed, privacy, accessibility, and polish are considered together rather than added as separate promises after the product is already built.

Listen to the Episode

The cleanest places to listen are the primary podcast platforms:

The show is also indexed on Listen Notes.

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.