Daniel sent us this prompt that feels like it's been brewing for a while. He's asking the bigger question: what does the full toolkit for asynchronous communication actually look like, when do you use which tool, and how do you manage the boundaries, especially when you're a contractor juggling multiple clients across time zones. He's got this observation that a lot of organizations treat every resource the same, remote or not, and just call whenever, which he's had to push back on to protect any kind of predictable flow. The kernel here is: what are the best practices for actually making async work, not just having the tools but using them well.
He mentioned something that really resonated with me. He said email is an async tool, and people forget that. It sounds obvious, but the way most people treat email, you'd think it was a real-time chat app with push notifications and anxiety baked in. The tool itself is asynchronous by design. The culture around it is what broke.
Before we dive into the toolkit, quick note. DeepSeek V four Pro is writing today's script. There, that's out of the way. So let's start with the foundation. Daniel's framing mentions deep work, knowledge work, and the need for predictable time management. That's the central tension of modern remote work. You've got tools that can be synchronous or asynchronous depending on how you configure them, and you've got organizational cultures that default to immediate response regardless of what the tool was designed for.
And there's actual research on this. GitLab, one of the largest all-remote companies with something like two thousand team members across more than sixty countries, published a comprehensive guide on asynchronous communication. Their core principle is that async is the default, synchronous is the exception. A meeting is a last resort, not a first response. They have a publicly available handbook, thousands of pages, designed to be read asynchronously. You don't need a meeting to understand how the company works.
Which sounds great in theory. But Daniel's point about clients calling at random times, that's the reality for a lot of people who don't work at GitLab. You're a contractor with five clients, each one thinks they're your only client. How do you actually enforce async boundaries when the power dynamic is you need their business?
That's the cultural layer, and it's harder than the tool layer. The starting point is having an explicit communication charter, even if it's just you unilaterally defining your norms. Basecamp published their internal communication guide years ago, and it's still one of the best documents on this. They talk about the difference between "now" communication and "later" communication. A phone call is now. Email is later. Chat sits in this awkward middle ground where it's technically later but culturally now.
Daniel mentioned something specific I want to pull on. He felt weird using Loom for purely sending a video message, as opposed to a screencast with his face in the corner showing a UI. There's an interesting taxonomy emerging. You've got text-based async: email and long-form documents. Short-form async video: Loom and its competitors. Async voice: the niche category he mentioned. And async collaboration platforms like Notion, Linear, GitHub issues, where the artifact is the communication and the discussion happens around it.
Each has different properties in terms of information density, searchability, and cognitive load on the recipient. That last one is what most tool discussions miss. The question isn't just "can I send this asynchronously," it's "what am I asking of the person on the other end." A ten-minute Loom is a ten-minute commitment. A two-thousand-word email might take five minutes to read or twenty, depending on complexity. A voice memo, even with AI transcription, still requires processing audio, which for a lot of knowledge workers is slower than reading text.
You just made the case against your own medium, Herman. We're doing a podcast. Voice is supposedly inefficient.
Context matters enormously. Podcasts are opt-in, background-friendly, and consumed during commutes or chores. A work status update is not a podcast. The recipient didn't choose to receive it, and they need to extract actionable information. That's why I'm skeptical of voice memos as a primary work tool, even with AI summarization. The AI summary helps, but now you've introduced a translation layer. The sender spoke for ten minutes, the AI summarized it into three bullet points, and the recipient is making decisions based on what the AI decided was important. There's a loss of fidelity that might matter.
That's fair. But Daniel specifically called out the scenario where you're unloading the dishwasher and listening to work updates. Not everyone processes information the same way. Some people retain audio better than text. And the AI transcription plus TTS pipeline he described, where an AI agent reads back summarized reports in a consistent synthetic voice, that's interesting. It decouples the sender's voice from the recipient's consumption experience.
I'll grant the consumption side is improving rapidly. But let's talk about the production side. One underappreciated benefit of writing is that it forces clarity. When you type out your thoughts, you naturally structure them, you edit, you remove redundancies. Voice is stream of consciousness for most people. You ramble, you repeat yourself. The AI summarization is cleaning up a mess that wouldn't exist if you'd just written it down.
Unless you're good at structured speaking. Some people think better out loud. You and I do this every episode. We don't script our actual conversations. The structure emerges from the dialogue. That's a skill that can be developed. The real issue isn't voice versus text, it's structured versus unstructured communication. A well-structured voice memo with clear sections and a summary up front is perfectly fine. A rambling stream of consciousness is terrible regardless of medium.
That connects to something Basecamp emphasizes: the importance of writing things down not just for the recipient, but for yourself. Writing is thinking. The act of composing a clear message forces you to clarify your own thoughts. That benefit exists whether the final output is text, voice, or video. The medium is secondary to the structure.
Let's build out the toolkit Daniel asked for. He mentioned email, video, voice, and the general Slack-and-CC culture. What's the actual decision framework?
I'd start with a two-axis framework. One axis is urgency: does this need a response in minutes, hours, or days? The other is complexity: is this a simple yes or no, or does it require deep discussion? Those two axes give you four quadrants, and different tools map to different quadrants.
Walk me through it.
Low urgency, low complexity: email or a quick Slack message. "Here's the updated link." No need for a call. Low urgency, high complexity: that's where long-form async shines. A detailed document, a Loom walkthrough, a Notion page with embedded context. The recipient needs time to process. High urgency, low complexity: a ping, a text message, maybe a quick call if truly time-sensitive. High urgency, high complexity: the one quadrant where synchronous communication is genuinely necessary. A crisis, a critical decision with multiple stakeholders, something where back-and-forth needs to happen in real time.
I like that framework. But urgency is subjective. Daniel's experience of clients calling at random times, that's a mismatch in urgency perception. The client thinks their question is high urgency. The contractor knows it can wait until the next scheduled check-in.
Which is why the framework must be paired with explicit norms. GitLab's approach is to document everything and make it discoverable, so the answer to most urgent questions already exists somewhere. They have a saying: "If it's not in the handbook, it doesn't exist." The more you invest in written, searchable documentation, the fewer interruptions you generate.
Let's talk about Loom specifically, since that's what kicked off this thread. Daniel used it for a pure video message and felt weird about it. I think that feeling comes from a mismatch between the tool's design and how he was using it. Loom is optimized for screencasting, the face-in-the-corner demo. But video messaging is broader than that. The weirdness Daniel felt might just be that Loom's interface primes you for a certain kind of content, and when you use it differently, it feels off.
There's also a generational and cultural component. For a lot of people in technical fields, video of yourself talking without a screen share feels uncomfortably personal. It's one thing to show a UI and narrate over it. It's another to just talk to the camera. That's a performance, and not everyone is comfortable performing. The screencast gives you something to hide behind.
That's astute. And it connects to what Daniel said about voice being unintrusive. Voice is lower bandwidth emotionally. You don't worry about how you look, your background, your facial expressions. For a lot of people, sending a voice memo feels less exposed than sending a video of themselves. But text feels even less exposed. There's a spectrum of vulnerability: text is the most guarded, then voice, then video. People gravitate toward the medium that matches their comfort level, not necessarily the medium most effective for the content.
Which brings us to one of the most interesting developments: the AI-mediated communication Daniel described. You send a voice memo, the AI transcribes and summarizes it, and the recipient gets a clean text summary. Or you send a long email, and the recipient has an AI agent read it in a pleasant synthetic voice. The sender and recipient don't have to agree on a medium anymore. The AI bridges the gap.
That's transformative. We're already seeing this. Slack has built-in AI summarization. Otter and Fireflies do meeting transcription. The next step is making this bidirectional and seamless, so everyone communicates in their preferred mode and the AI handles the translation.
There's a risk, though. When you insert AI between sender and recipient, you're adding a layer of interpretation. The AI might summarize incorrectly, miss nuance, flatten tone in a way that changes meaning. For status updates and factual information, that's probably fine. For sensitive feedback, performance reviews, anything with emotional weight, it's a terrible idea. You need the human voice, literally or figuratively, for the stuff that matters.
The AI layer is for information transfer, not for relationship building. And that's a useful way to think about the whole toolkit. Some communication is about transferring information. Some is about building and maintaining relationships. The tools and the sync versus async decision should be different for those two categories.
Most remote work advice collapses these together. They say "default to async" as if all communication is information transfer. But if you never have synchronous, face-to-face interaction with your team, the relationships atrophy. You become a transaction processor. For long-term collaboration, you need some synchronous time, even if it's just a monthly video call explicitly not about work.
Daniel mentioned he's done every permutation of remote work, from full-time to contracting. The relationship depth varies enormously. A full-time employee embedded in a team has different communication needs than a contractor brought in for a specific deliverable. The contractor can be almost entirely async because the relationship is transactional by design. The full-time employee needs more synchronous touchpoints because they're part of an ongoing collaborative organism.
That's a really important distinction. The communication strategy should match the relationship structure. A lot of companies get this wrong in both directions. They treat contractors like employees, expecting them at standups and all-hands. Or they treat employees like contractors, giving them nothing but tickets and deadlines with no human connection. Both are failures of organizational design.
Let's get practical. Daniel asked about baseline responsiveness for email when dealing with clients. What's your take?
Research on email responsiveness suggests the anxiety isn't about the actual response time, it's about the uncertainty. If I email you and have no idea when I'll hear back, I'm anxious. If I know you respond within twenty-four hours, I'm not anxious even though twenty-four hours is a long time. Predictability matters more than speed.
The move is to set expectations explicitly. In your contract, your onboarding, your email signature even. "I check email twice a day and respond within one business day." Then the client knows what to expect and can plan around it.
The corollary is you have to actually deliver on that promise. If you say twenty-four hours and consistently take forty-eight, you've broken trust. But if you say forty-eight and consistently deliver in twenty-four, you're a hero. Under-promise and over-deliver is cliché but it works.
There's also a tiering strategy. Different clients get different response SLAs based on the engagement. Retainer clients who pay monthly get faster responses than project-based clients who pay per deliverable. That's not unfair, it's reflecting the economic reality. The retainer client is paying for availability. The project client is paying for output.
That tiering should be transparent, baked into the service description. The retainer package includes priority email support with a four-hour response time during business hours. The project package includes email support with a twenty-four-hour response time. Now the client is choosing their experience, not being subjected to it arbitrarily.
Let's shift to the tool landscape. Daniel mentioned niche async voice platforms. Yac was one, it got acquired. Voxer had a moment. The challenge for dedicated async voice tools is they're solving a problem that can be solved by just sending a voice memo in WhatsApp or Signal. The dedicated tool has to offer something meaningfully better than the general-purpose messenger you already have.
The differentiator tends to be workflow integration. If the voice memo automatically gets transcribed, summarized, and attached to the relevant task in your project management tool, that's useful. If it's just a voice message floating in yet another app, it's not worth the switching cost. This is why I think the future of async voice isn't standalone apps, it's features inside the platforms people already use. Slack adding voice messages was a bigger deal than any dedicated voice app.
With AI improving, the integration gets more powerful. Imagine sending a voice message in Slack that automatically creates a task in Linear with the action items extracted, updates the relevant Notion page, and pings the people mentioned. That's a few API calls and a decent language model.
We're describing an AI executive assistant that sits on top of your communication channels and routes information to where it needs to go. The sender just talks. The system figures out what's actionable, what's informational, what's noise, and handles each appropriately. That fundamentally changes the async communication equation because the burden of structuring information shifts from the sender to the system.
Which is great for the sender but potentially terrible for the recipient if the system gets it wrong. We're back to the fidelity problem. But for a lot of routine work communication, the fidelity bar is actually pretty low. "The Johnson account is on track, the deliverable is eighty percent done, I'm blocked on the API access." If the AI can extract that reliably from a two-minute voice memo, that's a win.
The key is knowing which communications are routine enough to automate and which require the human touch. That judgment call is itself a skill remote workers need to develop. It's not just about which tool to use, it's about calibrating the level of human attention appropriate to the message.
There's another dimension Daniel hinted at: the time zone problem. When your team is spread across eight time zones, synchronous communication isn't just inconvenient, it's actively harmful. Someone is always taking a call at midnight or six in the morning. Async isn't a preference in that context, it's a requirement for basic fairness.
The time zone problem compounds. If you have team members in San Francisco, London, and Tel Aviv, there's essentially no overlap where everyone is working. The only way to function is to make almost everything asynchronous. GitLab has team members across every continent except Antarctica, and they've made this work by being ruthlessly async. Meetings are recorded and transcribed by default. Decisions are made in writing, not in calls. If you weren't in the meeting, you can read the notes and contribute asynchronously, and your input carries the same weight as if you'd been there live.
That last point is crucial. In most organizations, if you're not in the meeting, your opinion doesn't count. The decision gets made by whoever showed up. That's a structural bias toward synchronous participation, and it systematically disadvantages people in distant time zones, people with caregiving responsibilities, people who work part-time. Async-first cultures deliberately counteract that bias by making the written record the source of truth, not the live conversation.
There's a concept from open source software development that applies here. In open source, almost all communication is asynchronous and written. Mailing lists, issue trackers, pull request discussions. Someone in Brazil and someone in Germany can collaborate on code without ever being online at the same time. The artifact, the code itself, is the center of gravity. The conversations happen around it, and they're all archived and searchable. That model has produced some of the most important software in the world.
Daniel works in open source, so he knows this model intimately. I think that's partly what's behind his question. He's seen async collaboration work beautifully in open source, and he's wondering why it's so hard to replicate in corporate environments. The answer, I think, is that open source has a built-in incentive structure. People contribute because they want to. The communication norms emerge from voluntary participation. In a corporate environment, participation is mandatory, and the norms are imposed from above, often by people who've never worked remotely themselves.
That's a structural insight. The tools are the same, or similar. GitHub issues versus Jira tickets. Mailing lists versus Slack channels. But the social context is completely different. In open source, if you're annoying to communicate with, people just stop engaging with you. In a company, you can't opt out of communicating with your manager, even if their communication style is terrible. The power dynamics override the tool dynamics.
What do you do about that, practically? Daniel's a contractor, he can set boundaries. But a lot of people listening are employees in organizations with broken communication cultures. They can't unilaterally declare their inbox an async-only zone.
They can't, but they can influence the culture incrementally. One tactic that's surprisingly effective is modeling the behavior you want to see. Respond to emails thoughtfully but not instantly. When someone Slacks you with a non-urgent question, reply with "let me think about that and get back to you this afternoon" instead of dropping everything. Write good documentation and point people to it when they ask questions already answered. Over time, people adjust their expectations of you. And if you're consistent, some of them start adopting the same practices.
The documentation point is underrated. Nothing reduces interruptions like a well-maintained knowledge base. Every time you answer a question, ask yourself: could this answer be written down somewhere the next person would find it? If yes, spend the extra five minutes to document it. The ROI over a year is enormous.
Basecamp calls this "the harvest." Every question you answer is an opportunity to create a permanent artifact. Instead of just replying to the email, you write it up in the shared knowledge base and reply with a link. Now the answer is available to everyone, forever. Do that consistently for six months and you've built an institutional memory that reduces incoming question volume significantly.
Let's circle back to the specific tools. We've covered email, video, voice. What about the project management layer? Tools like Linear, Notion, Asana, Monday. These are async communication tools, not just task trackers. The comment thread on a task is a communication channel. The document is a communication channel.
The key distinction is structured versus unstructured communication. A Slack message is unstructured, a firehose of everything. A Linear issue is structured. It has a title, a description, a status, an assignee, a priority. The structure makes it easier to process asynchronously because you know what you're looking at and what's expected of you. A lot of remote teams would benefit from moving more communication into structured tools and out of unstructured chat.
The counterargument is that structured tools feel heavy. Opening Linear and creating an issue for "hey, what's the login for the staging server" feels like overkill. And it is overkill for that specific question. But if that question gets asked five times by five different people, the overkill was worth it because now the answer is in a searchable, structured place. The heaviness is a feature, not a bug, for anything with recurring value.
There's a concept from computer science called the "cost of coordination." Every time you need to align with another person, there's a tax. Async communication reduces that tax by letting each person pay it on their own schedule. Structured communication reduces it further by making information easier to find and process. The ideal remote workflow minimizes the coordination tax, and tool choice is a big lever for that.
Daniel also mentioned the contractor's dilemma specifically. When you're a contractor, you're not in the company's Slack. You're not in their Linear. You're communicating through email and maybe a shared document or two. The tool landscape is different because you're outside the organizational boundary. You have to be more deliberate because you don't have the ambient context that employees absorb through chat and meetings.
This is where the structured update really shines. As a contractor, sending a weekly status email or Loom that covers what you did, what you're doing next, and what you need from them, that's gold. It creates a rhythm. The client knows when to expect it, knows what it will contain, and can process it on their own time. It also creates a paper trail, which is valuable for both sides if there's ever a dispute about scope or timeline.
The format can be standardized. Same sections every week. Accomplishments, blockers, next steps, decisions needed. The client learns the format and can scan it quickly. If you're doing this as a Loom, same structure. Two minutes max. Anything longer and you're probably including detail that should be in a written document.
The two-minute rule for async video is a good heuristic. Engagement drops off sharply after about ninety seconds for unsolicited video messages. If you need more time, you should probably be writing a document instead. Video is for high-level updates and demonstrations. Text is for detail.
Let's talk about the synchronous side. Daniel acknowledged synchronous communication isn't inherently bad, and he gave the ambulance dispatch example. There are time-sensitive, high-stakes situations where async doesn't work. But there's another category of legitimate synchronous communication less about urgency and more about relationship and alignment. The team retreat. The one-on-one. The brainstorming session where the energy of real-time interaction produces better outcomes.
Brainstorming is an interesting case because the research on it is mixed. There's evidence that asynchronous brainstorming, where people generate ideas independently and then pool them, actually produces more and better ideas than real-time group brainstorming. The phenomenon is called "production blocking." In a group, you have to wait your turn to speak, and while you're waiting, you might forget your idea or talk yourself out of it. Asynchronously, everyone can generate ideas in parallel without blocking each other.
Even brainstorming, the canonical synchronous activity, might be better async in many cases. The synchronous version is more fun, more energizing, better for team bonding. But if the goal is idea quality, the research favors async. Some things are done synchronously because they're effective. Some are done synchronously because they're enjoyable and relationship-building. Both are valid. The mistake is confusing the two.
A lot of remote work advice throws the baby out with the bathwater. "Eliminate all meetings" sounds great until your team has no shared context and no interpersonal trust. The right approach is to be intentional about which meetings serve which purpose. The weekly team sync might be mostly for social connection, and that's fine, as long as you're honest about it and don't try to cram status updates into it that would be better handled asynchronously.
Daniel's prompt also touched on something worth naming explicitly: the emotional labor of async communication. Sending a Loom or writing a detailed email takes more effort than firing off a Slack message or hopping on a quick call. You have to structure your thoughts, record, maybe re-record, edit. The sender pays a higher upfront cost in async. The benefit goes to the recipient, who can process it on their own schedule. Over time, this asymmetry can lead to burnout if the sender is constantly doing the extra work while the recipients are coasting.
That's a real phenomenon, and it's why async culture has to be reciprocal. If one person is always writing detailed documents and everyone else is just reacting, that's not sustainable. The documentation burden needs to be shared. Everyone contributes to the knowledge base. When the culture is async-first, the load balances out because you're receiving well-structured async communication from others, not just producing it.
There's also a skill component. Writing a good async update is a skill. Recording a concise, clear Loom is a skill. These are teachable and learnable. Organizations that take async seriously invest in teaching these skills. They have style guides, templates, examples of good and bad async communication. They treat it as a core competency, not an afterthought.
GitLab has an entire section in their handbook on "how to write a good async update." They emphasize putting the conclusion first, using clear headings, linking to relevant context, and explicitly stating what kind of response you need and by when. These are simple techniques, but most people don't use them because nobody taught them. The default mode in most organizations is "write an email that looks like a stream-of-consciousness novel and hope the recipient figures out what you want.
The "what kind of response and by when" part is especially important. A lot of async communication fails because the recipient doesn't know what's expected of them. Are they supposed to just read and acknowledge? Make a decision? Provide feedback by Friday? If you don't specify, they'll default to the lowest-effort interpretation, which is usually "read it and do nothing.
There's a framework called "DACI" that some teams use. Driver, Approver, Contributors, Informed. Every async communication should make clear which role the recipient is in. If you're just being informed, say so. "No action needed, just keeping you in the loop." If you need approval, say so. "Please approve the budget by EOD Thursday or the timeline slips." Clarity is kindness in async communication.
Let's bring this back to Daniel's specific situation. He's a contractor in Israel, working with clients in different time zones, doing technical work that often requires demos and explanations. He's looking for a baseline of responsiveness that protects his deep work time while keeping clients happy. What's your practical recommendation?
Start with a written communication charter shared with every client at the beginning of the engagement. Something like: "I check email twice daily, at ten in the morning and four in the afternoon Israel time. You can expect a response within one business day. For urgent matters, Signal or WhatsApp with the word 'urgent' will get my attention faster. I send weekly status updates every Thursday covering progress, blockers, and next steps. Scheduled calls are available during my business hours, nine to five Israel time, Sunday through Thursday.
That's specific, clear, and reasonable. Most clients will accept it. The ones who won't are probably clients you don't want anyway. And Daniel's point about pushing back when clients call at random times gets easier when you have a written policy to point to. It's not personal. It's just how you work.
For tool selection, I'd recommend a tiered approach. Email for formal communication and deliverables. A project management tool, whatever the client uses, for task-level discussion. Loom or similar for demos and walkthroughs, kept under two minutes. And a messaging app for quick, informal coordination, with clear boundaries about response time. The key is consistency. Use the same tools the same way across clients so you're not context-switching between different communication norms.
The context-switching cost is real. If every client uses a different project management tool and messaging app and video platform, you're spending cognitive energy just navigating the tools. If you can standardize your side of the stack, even if the client uses something different on theirs, it helps. "I'll send updates via email, but I'm happy to join your Slack as a guest for urgent matters.
This is where AI tools are starting to help with the fragmentation problem. There are services now that aggregate your communications across Slack, email, Teams, and give you a unified inbox with AI-powered prioritization. It's not perfect yet, but the direction is promising. The dream is that you communicate however you want, and the AI handles the translation and routing across platforms.
We should acknowledge that a lot of this advice is for knowledge workers who have autonomy over their schedule. If you're a customer support agent working a shift, you don't get to decide when you're responsive. The async versus sync conversation is most relevant for people who have some control over their work design. Daniel has that as a contractor. A lot of our listeners probably have at least some of that. But it's not universal.
And even in more structured roles, there are usually opportunities to carve out async time. Blocking off two hours in the morning for deep work, with Slack closed and phone on do not disturb. Communicating to your team that you're unavailable during those hours except for genuine emergencies. Most managers will respect that if you frame it as a productivity practice rather than an avoidance tactic.
The deep work angle is important. Cal Newport's research on this is compelling. The ability to focus without interruption for extended periods is increasingly rare and increasingly valuable. Every unnecessary Slack notification, every "got a minute" tap on the shoulder, every email demanding an immediate response, these are taxes on your cognitive capacity. Async communication isn't just a preference. For knowledge workers, it's a competitive advantage.
The organizations that figure this out will outperform the ones that don't. There's a reason GitLab can compete with companies ten times their size. Their async culture lets them hire the best people anywhere in the world and lets those people do their best work without interruption. The coordination tax in a synchronous culture is enormous, and most companies don't even see it because it's just the water they swim in.
To synthesize: the async toolkit is email, structured documents, short-form video, voice with AI mediation, and project management platforms. The decision framework is urgency versus complexity. The cultural prerequisite is explicit norms and shared expectations. The personal practice is setting boundaries, communicating them clearly, and being consistent. And the frontier is AI-powered translation between mediums and platforms.
I'd add one more thing: the meta-skill here is intentionality. Most communication habits are defaults inherited from the organization or the industry. The remote workers who thrive are the ones who consciously design their communication practices rather than accepting the defaults. They think about which tool for which message, which medium for which audience, which cadence for which relationship. It takes more upfront effort, but the long-term payoff in focus, productivity, and sanity is enormous.
Sanity might be the most underrated benefit of all. Daniel mentioned the stress of clients calling at random times. That stress accumulates. Over months and years, it leads to burnout. Async communication, done well, isn't just about efficiency. It's about creating a sustainable working life where you control your attention instead of having it constantly hijacked by other people's urgencies.
That's a good place to land. The tools are important, but the mindset is what makes them work. Async isn't about being less responsive. It's about being more intentional about when and how you respond, so that when you do engage, you're bringing your full attention rather than a distracted fragment.
And now: Hilbert's daily fun fact.
Hilbert: The term "transient lunar phenomenon" was coined in eighteen sixty-eight by the astronomer John Birmingham after he observed a bright red glow in the lunar crater Aristarchus. Birmingham was an Irish amateur astronomer working from his observatory in Tuam, County Galway, and he published one of the first systematic catalogs of these mysterious lunar events, which had been reported for centuries but never collected in one place. The name stuck, and astronomers still argue about what causes them.
Red glow on the moon.
This has been My Weird Prompts. Thanks to Daniel for the prompt, thanks to Hilbert Flumingtop for producing, and thanks to all of you for listening. If you want to dig deeper into any of the tools or frameworks we talked about, you can find show notes and more at myweirdprompts.Until next time.
