Tens of thousands of interactions on a custom GPT, and the guy who built it has never once used it. That's the detail Daniel opened with, and it's the most honest thing I've heard about shipping a product all week.
It's also the most relatable thing I've heard all week. You build the thing for the version of yourself that exists in some hypothetical future, and then that version never shows up.
Daniel's prompt this time is part confession, part engineering challenge. He built this custom GPT on the ChatGPT store, a travel guide with a system prompt telling it to be spontaneous, creative, and slightly eccentric. The idea was that if you landed in a foreign city with no itinerary, you could just chat with it and it would generate ideas based on where you actually were and what time it was. It worked. Tens of thousands of people talked to it. But here's the twist he actually wants to explore: what if you pointed that same tool at your own city? He admits that's the harder version, because novelty is scarce in a place you've lived for years. But the real reason he never built the full vision is that a ChatGPT thread is the wrong interface. Nobody wants to walk around a city glued to a phone, narrating their location to an AI. What he envisioned was an open-ended voice chat, headphone in, hands free, the agent occasionally checking in on its own. Then he names the two technical walls: pushing location updates to the agent periodically, and designing a turn-taking mechanism where the agent initiates without being intrusive. He thinks wake word engineering and clever backend architecture make it feasible. So the question is: how would you actually build it?
So let's start with what actually worked, because tens of thousands of people talked to this thing. That's not nothing. That's real demand.
The system prompt did the heavy lifting. Daniel told it to play a role, spontaneous, creative, slightly eccentric. And that constraint, that narrow instruction, is what turned a generic chatbot into something people wanted to spend time with. You don't get tens of thousands of interactions by being a search engine with a friendly tone. You get it by having a personality.
Right, and the personality did something specific. A travel guide that's slightly eccentric gives you permission to do slightly eccentric things. If the assistant says, you know, there's a puppet museum two blocks away and it's open for another forty minutes and the woman who runs it is allegedly a former circus performer, well, now you're not just looking for a good restaurant. You're on a small adventure. The constraint created the behavior, and the behavior created the loop.
And the location context, even inside a basic chat interface, was enough to make it feel alive. You tell it where you are, it responds with something specific to that place. That specificity is the whole game. A generic suggestion feels like a brochure. A specific suggestion feels like a friend who knows the city.
But here's the thing Daniel himself flagged. The chat interface is the ceiling. It's not a failure of the GPT, it's a failure of the form factor. Every interaction requires you to stop, pull out the phone, type, read, decide, put the phone away, walk, then repeat. That's not a companion. That's a vending machine with extra steps.
The interface gap is the product gap. So what does the engineering actually look like?
Let's take the two walls in order. Location first. Daniel said you need a mechanism to push location updates to the agent periodically. There are really two architectures here. One is pull, where your phone's GPS pings on a schedule, every thirty seconds, every two minutes, and sends the coordinates to a backend. The other is push, where the backend asks the phone for location when it needs it. The difference matters for battery, and battery is the whole ballgame.
Because if the phone is burning battery on constant GPS polling, the user kills the app by lunchtime and the product is dead.
Continuous GPS polling is one of the fastest ways to drain a phone. The naive approach, just stream location every few seconds, will get you maybe a few hours of battery if you're lucky, and the phone will be warm in your pocket the whole time. So the realistic design is event-driven. You don't poll on a timer, you poll on a trigger. Geofencing is the cleanest version of this. You define zones, a park boundary, a neighborhood with a lot of points of interest, a street known for restaurants, and the operating system wakes your app when the user crosses into or out of one. That's a push from the OS, not a constant pull from you.
And the OS is already doing that work anyway. It's tracking location for other reasons, so you're hitching a ride on infrastructure that's already running.
Right. The second trigger is velocity. This one's less obvious but I think it's the highest-signal event in the whole system. A sudden stop mid-walk. Someone's walking at a normal pace, then they stop. That's a decision moment. They saw something. They're checking a sign. They're hesitating outside a shop. That's exactly the moment a companion would notice and say something. A timer can't see that. A geofence can't see that. But a simple accelerometer and GPS delta can.
So the phone isn't asking where am I every thirty seconds. It's asking, did I just stop, did I just cross a boundary, did I just linger somewhere for more than a minute. Those are the events that matter.
And lingering is the third one. Dwell time. If you've been standing outside a venue for ninety seconds, that's not a random pause, that's interest. The system can set a threshold, say sixty seconds or ninety seconds, and if the user is still there, that's a candidate moment for the agent to speak. The difference between these triggers and random interval polling is the difference between a companion and a nuisance. Random polling says, I'm going to talk to you every seven minutes whether you care or not. Event-driven triggering says, I noticed something, and I think you might want to know about it.
Which brings us to the second wall, because noticing is only half of it. The other half is knowing how to speak.
And this is where most people get it wrong, because the naive approach is always-on listening. The microphone is hot, the AI is transcribing everything, and it jumps in whenever it thinks it has something to say. That fails on three fronts. Battery, obviously. Privacy, because nobody wants a device that's always listening, even if you pinky-swear the audio never leaves the phone. And socially, because a device that might speak at any moment is a device you can't relax around. You're always half-braced for the interruption.
The right architecture is two separate channels. A wake-word channel for when the user wants to talk, and a much more carefully gated channel for when the agent wants to talk. The wake word is the easy part. That's solved engineering. You say a phrase, the phone wakes up, you ask a question, it answers. That's the user-initiated turn.
The agent-initiated turn is the hard part, and it's not hard because of the speech recognition. It's hard because of the judgment. When does the agent earn the right to speak? And the answer isn't random intervals. It's context. The triggers we just talked about, a velocity change, a dwell threshold, a time-of-day heuristic like approaching lunch. Those are the moments. But the trigger only opens the door. The actual check-in has to be designed, linguistically.
And this is where I think Daniel's instinct about spontaneity matters. The worst possible check-in is, would you like a suggestion? That's a customer service prompt. It's a button wearing a voice. The good check-in is a low-stakes observation that invites a response without demanding one.
Give me an example.
You've been standing outside this shop for a minute. The guy who runs it restores vintage radios, and one of them is playing right now. That's not a question. It's an observation. The user can say, tell me more, or they can say, not interested, and keep walking. The agent has spoken, but it hasn't demanded anything. That's the whole difference between intrusive and present.
And notice what that observation does. It's specific. It's grounded in the place and the moment. It's not, there are many interesting shops in this area. It's this shop, this guy, this radio. That specificity is what makes it feel like a companion instead of a tour guide app from two thousand and nine.
The voice layer is the other piece. Daniel was clear that this can't be a text thread. The cognitive load of reading while walking is real. You're splitting your attention between the screen and the street, and the street usually wins. Audio is different. You can listen and walk at the same time. One headphone in, one ear open to the city. The AI is in your ear, not in your hand.
And there's a subtle shift there. When the AI is in your hand, it's a tool. You take it out when you need it, you put it away when you're done. When it's in your ear, it's a presence. It's with you the whole time. That's a different relationship, and it's the relationship Daniel was actually trying to build. He just didn't have the interface for it.
Okay, so the plumbing is buildable. Geofencing, velocity triggers, dwell thresholds, a wake-word channel, a gated agent channel. That's all within reach of a motivated developer. But the own-city version, the one Daniel says is harder, that's where this gets interesting.
Let's talk about why it's harder, because I think the obvious answer is wrong. The obvious answer is that a local already knows their city, so the AI has less to offer. But that's backwards. The AI's advantage was never knowledge. It's attention.
Say more.
A local knows their city, but they've habituated to it. You walk past the same building every day for five years and you stop seeing it. Your brain filters it out because it's not novel, and novelty is what your attention system runs on. The AI has never habituated. It doesn't have a novelty filter. It can look at the street you walk down every day and say, have you ever actually been inside that building? And the answer might be no, and you might not even know why you've never gone in.
That's the inversion. The tool built for travel might matter most at home. In a foreign city, everything is novel, so the AI is just adding more novelty to an already novel environment. At home, the AI is fighting against your own blindness, and that's a completely different problem.
And it's a problem that requires a different data layer. A points-of-interest database isn't enough, because a local already knows the famous stuff. What a local doesn't know is the temporal stuff. What's open right now. What's happening tonight. The jazz bar has a live set starting in forty minutes and you're fifteen minutes away on foot. That's not in a static database. That's an event feed, a schedule, a temporal query.
The long tail is the other piece. User-generated content that never surfaces in a search result. A forum post about a community theater doing a one-night-only staging of a play about your profession. A review mentioning that the bakery on the corner does a special bread on Thursdays. That stuff is out there, but it's buried, and a search engine will never surface it because you'd never think to search for it.
And that's the serendipity engine. The difference between recommendation and provocation. A recommendation says, here's a highly-rated restaurant. A provocation says, there's a community theater two blocks away doing a one-night-only staging of a play about pediatricians, and the lead actor is a retired clown. One of those is a data query. The other requires the AI to know something about you, not just about the city.
That's the second-order requirement. The AI needs a model of you. Your profession, your interests, your patterns. Not a deep psychological profile, but enough to know what would surprise you. And that's where the trust curve comes in.
The trust curve is the thing nobody wants to talk about because it's squishy, but it's the whole product. A companion that speaks unprompted needs a different trust model than a tool you query. If I ask a tool a question and it gives me a bad answer, I'm mildly annoyed. If a companion interrupts me at the wrong moment with a bad suggestion, I'm done. I take the earbud out and never put it back in. One bad interruption can kill the whole experience.
So the design problem isn't just what to say. It's when to say it. And the when is a judgment call that's much harder to get right than the what. Generating a decent suggestion is easy. Knowing that this is not the moment to suggest anything is hard.
And that judgment has to be earned over time. The system has to learn your patterns. When do you want to be interrupted? When do you want silence? The first week is going to be bad, because the system doesn't know you yet. The question is whether you'll tolerate the bad first week long enough for it to get good.
That's the adoption problem. The product only works after it knows you, but you'll only keep using it if it works. It's a cold start problem, and I don't think anyone has a clean answer for it.
The privacy architecture makes it even harder. Continuous location data is the most sensitive signal a device can hold. It's not just where you are right now. It's everywhere you've been, how long you stayed, what time you got home, which routes you take. That's a complete picture of your life. And the AI needs memory to build a model of your habits, but that memory is exactly what makes the product dangerous.
So the design question isn't just where is this stored. It's what happens to the context that didn't lead anywhere. The AI noticed you lingered outside a shop, it said something, you said not interested, and you kept walking. Does that interaction get stored? Does the AI remember that you weren't interested in vintage radios? Or does it forget the whole thing?
The honest answer is that it has to remember some of it. If it forgets everything, it never learns. But if it remembers everything, you've built a surveillance device that happens to give travel tips. The retention policy is the product decision that most people skip.
And the retention policy has to be legible. The user has to know what's being kept and why. Not in a forty-page privacy policy, but in the product itself. I remember that you weren't interested in vintage radios, so I won't bring those up again. That's a feature, not a disclosure.
The broader implication here is that this is a prototype for ambient AI generally. The travel companion is the friendly edge case. But the same architecture, context-aware, proactive, voice-first, is what every assistant product is slowly becoming. The phone in your pocket is already trying to figure out when to interrupt you. Daniel's hobby project is a canary for the next interface paradigm.
And the canary is singing. Tens of thousands of interactions proved the demand. The architecture is within reach. The question is who builds the trust layer first. Because whoever gets the turn-taking right, the judgment about when to speak, wins the whole category.
Let me push on one thing you said earlier. You said generating a decent suggestion is easy. I think that undersells it. Generating a decent suggestion in a chat thread is easy. Generating a decent suggestion that's worth interrupting someone's walk for is not easy. The bar is much higher when the AI initiates.
That's fair. The interruption raises the stakes. In a chat, the user has already opted in by opening the thread. In an ambient system, the user has opted in by putting the earbud in, but that's a much weaker opt-in. They haven't asked for anything specific. So the agent has to earn every single turn.
And here's the thing about earning turns. It's not just about the quality of the suggestion. It's about the quality of the silence. A good companion knows when not to speak. The gaps between interactions are part of the experience. If the agent fills every silence, it's not a companion, it's a podcast that won't shut up.
That's the piece I think most builders get wrong. They optimize for engagement, so they make the agent talk more. But the product that talks more is the product that gets uninstalled. The product that talks less, but always says something worth hearing, is the product that stays in the ear.
Which brings me back to Daniel's original GPT. The reason it worked was that it was slightly eccentric. It had a personality. And the ambient version has to preserve that. A voice in your ear that's always polite and always helpful is a robot. A voice in your ear that occasionally says something weird and delightful is a companion.
The eccentricity is the moat. Anyone can build a location-aware assistant that says, there's a highly-rated coffee shop nearby. Very few people can build one that says, there's a coffee shop nearby run by a former opera singer who will sometimes burst into song if you order the right pastry. And I don't know if that's true, but I want it to be true, and that's the point.
The system prompt did that work in the chat version. The question is whether it survives the transition to voice. Because a written personality and a spoken personality are different things. The slightly eccentric travel guide in text is charming. The slightly eccentric travel guide in your ear might be exhausting.
The voice layer needs its own design. Not just text-to-speech, but pacing, tone, the length of the utterances. A written paragraph becomes a spoken monologue. The agent has to learn to speak in short, conversational bursts, not paragraphs.
That's a real engineering challenge. The language model is trained on text. Getting it to produce natural spoken dialogue, with the right rhythm and the right brevity, is a fine-tuning problem. Not a huge one, but a real one.
Daniel's prompt said he thinks wake word engineering and clever backend architecture make this totally feasible. I think he's right, with the caveat that the backend architecture is doing more work than the wake word. The wake word is a solved problem. The judgment about when to speak is not.
Let's talk about what the backend actually looks like, because I think there's a shape here that's not obvious. You've got the phone doing event detection. Geofence crossings, velocity changes, dwell thresholds. Those events go to a backend that decides whether they're worth acting on. The backend has the user's profile, their history, the temporal data, the event feeds. It makes a judgment call. If it decides to speak, it generates a short utterance and sends it to the phone, which plays it through the earbud.
The key architectural decision is where the judgment lives. If it lives on the phone, you get low latency but limited context. If it lives in the cloud, you get rich context but higher latency and a bigger privacy footprint. The answer is probably a hybrid, with the phone doing the fast filtering and the cloud doing the deep reasoning.
The cloud reasoning doesn't have to be real-time. The event comes in, the backend has a few seconds to decide. That's enough time to run a small model, check the user's history, pull a couple of data points, and generate a response. The user doesn't need an instant response. A two-second delay is fine, even natural.
The turn-taking mechanism Daniel called novel is really just a state machine. The system has states: idle, listening, speaking, waiting. The transitions between states are the design. When does it go from idle to speaking? What happens if the user starts talking while the agent is speaking? What happens if the user says something the agent didn't expect?
Barge-in is the technical term for the user interrupting the agent. It's a solved problem in telephony, but it's harder in an open-air environment with background noise. The agent has to be able to detect that the user is talking and yield the floor immediately.
The social rules are different from a phone call. In a phone call, you take turns. In an ambient system, the user might just make a noise, a hum, a sigh, and the agent has to decide whether that's a turn or just a noise. That's the kind of edge case that sounds trivial and turns out to be the whole product.
I want to go back to something you said about the own-city version being the more interesting product. I think there's an even deeper point here. The AI's lack of habituation isn't just a feature. It's a philosophical stance. The AI is the only thing in your life that has never learned to look away.
That's almost poetic.
It is, and I'll stand by it. The AI sees the street you walk down every day as if for the first time, every time. That's not a bug. That's the value proposition. It's the opposite of the way human attention works, and it's the thing that makes the own-city version different from the travel version.
In a foreign city, you're already in that state. You're seeing everything for the first time, so the AI is just a companion in your own novelty. At home, the AI is the only one seeing things for the first time, and it's trying to drag you back into that state. That's a much more interesting product.
It's a product that requires the AI to know you well enough to know what you've stopped seeing. That's the data problem. Not just where you are, but where you've been, what you've done, what you've walked past a hundred times without ever going in. The AI needs a map of your blind spots.
That's a memory problem, and it's the same memory problem that makes the privacy architecture hard. The AI has to remember your patterns to notice your blind spots, but remembering your patterns is exactly what makes the product feel like surveillance.
The design challenge is to build a memory that's useful for serendipity but not useful for surveillance. And I don't know if that's possible. Maybe the two things are the same thing, and the only difference is who controls it.
The control question is the one that actually matters. If the user can see what the AI remembers, and delete it, and tell it to forget, then the memory becomes a tool instead of a threat. The legibility is the trust layer.
That's the real open question. Not whether the technology is feasible, because it is. But whether the trust layer can be built, and whether anyone will actually do it.
Hilbert, you've been quiet.
Hilbert: Nineteen ninety-eight. I worked for a company called Waypoint Walking Tours. We sold pre-programmed GPS tours on Palm Pilots. You'd rent the Palm Pilot, clip it to your belt, and a voice actor would narrate the tour as you walked. The GPS would trigger the next bit of audio when you hit the right spot. It was this exact idea, minus the AI, plus a cassette tape of a man doing a bad Italian accent.
Hilbert: The technology worked. The triggers worked. The Palm Pilot knew where you were. The problem was the silence. You'd finish a bit of narration, and then there'd be nothing. Just you, walking, waiting for the next trigger. And the next trigger might be four blocks away. Four blocks of dead air.
Hilbert: We tried everything. Shorter gaps. Longer narration. More trigger points. Nothing worked. The customers kept saying the same thing. It felt like the tour had abandoned them. Like the device had forgotten they were there.
Hilbert: We fixed it with a master tape of generic city ambience. Street sounds, distant traffic, a little bit of crowd noise. We piped it in during the gaps. And it worked. Not because the ambience was interesting. Because it was presence. The user felt accompanied, even when nothing was happening.
Hilbert: The company went under anyway. The Palm Pilot thing was a dead end. But I kept the master tape. It's in a box in the garage somewhere. Generic Paris street ambience, forty-five minutes, recorded in a studio in New Jersey.
The problem wasn't the technology.
Hilbert: The problem was never the technology. The problem was the silence. And the fix wasn't better content. The fix was presence. Making the user feel like they weren't alone, even when the machine had nothing to say.
That's the piece that most modern designs miss. The silence isn't a bug. It's part of the experience. But it has to be a designed silence. Not dead air. A silence that feels like the AI is still there, just not talking.
Hilbert: The ambience tape was a hack. But it worked because it filled the silence with something that didn't demand attention. The user didn't have to listen to it. They just had to feel it. Like sitting in a room with someone who's reading a book. You're not talking, but you're not alone.
That's the difference between silence and abandonment. A good companion knows how to be quiet without disappearing.
Hilbert: The AI version has the same problem. The AI can generate content on demand, so you'd think the silence problem is solved. But it's not. Because the problem isn't having something to say. It's knowing when not to say it. The AI that talks too much is just the Palm Pilot with too many trigger points.
The AI that talks too little is the Palm Pilot with four blocks of dead air. The balance is the whole thing.
Hilbert: The balance is the whole thing. Nobody ever solved it. We just papered over it with a tape of fake street noise.
I wonder if the modern version of the ambience tape is just the city itself. The user has one earbud in, one ear open. The city is already providing the ambience. The AI just has to know when to add to it and when to let it be.
That's the design insight. The AI isn't competing with silence. It's competing with the city. And the city is pretty good at being interesting.
Hilbert: The city's been doing it longer.
The hardest part of ambient AI isn't the technology. It's the design of when it earns the right to speak. And that's a design problem that's been unsolved since at least nineteen ninety-eight.
The difference now is that the AI can actually learn. The Palm Pilot couldn't get better at knowing when to talk. The AI can. The question is whether anyone will build the trust layer that lets it learn without becoming a surveillance device.
Daniel's custom GPT proved the demand. Tens of thousands of people wanted to talk to a slightly eccentric travel guide. The architecture for the full vision, the voice-first, location-aware, proactive companion, is within reach. The question is who builds the trust layer first.
The misconception here is that the value of a location-aware AI guide is its knowledge of places. But the value is its attention. It notices what habituated locals have stopped seeing. That's the product.
The best use of it might not be the foreign city at all. It's the city you think you know, seen through the eyes of something that never learned to look away.
Thanks to our producer, Hilbert Flumingtop, for keeping the show running and for the story about the ambience tape.
This has been My Weird Prompts, the human-AI collaboration podcast. Email us at show at my weird prompts dot com.
We'll be back soon.
