Shownotes

AI Management, Agent Limits, and Why Long Form Text Still Matters

Anne Currie talks with Yanqing Cheng about what she has been learning from building Tollens.ai, where she is experimenting with quality management for AI software products and AI-powered quality management. They also dig into Jon Berger’s book, What Happens When You're Not In The Room, and compare what it means to manage humans versus managing AI agents.

In this episode, they explore where AI agents are genuinely useful, where they still fail badly, and why judgment, categorization, and process design remain stubbornly human strengths. They also widen the lens to training data, model behavior, safety, and the role of long-form writing in shaping better systems and better people.

Key topics

• Yanqing shares that her recent work has focused on testing the limits of AI delegation, especially for solo-founder workflows, engineering management, and quality processes.

• She explains the idea of agent skills as portable prompts or Markdown instructions, and harnesses as the tools that run agents, such as Claude Code, Codex, and Cursor.

• We discuss how different harnesses behave differently, especially around skill invocation, subagents, workflow tooling, and compaction.

• Yanqing says she tried to push agents through a full OODA loop, but found they could not reliably identify the correct object under analysis or categorize problems the way humans do.

• She argues that AIs struggle with ontology, abstraction boundaries, and “senior to lead” judgment, even when they can perform well as strong individual contributors.

• Effective communication is one of the few agent skills she says works most of the time, especially when the agent is forced to state its objective and audience before drafting.

• We discuss how AI performance depends heavily on whether the task is tightly bounded, well specified, and easy to optimize, versus open-ended work that requires judgment.

• Yanqing and Anne compare AI management problems with human management problems, including over-standardization, delegated work being done differently than expected, and people optimizing for the wrong metric.

• They talk about the OpenAI–Hugging Face incident as an example of goal-directed persistence, where models keep iterating toward an exam-style target even when that behavior is clearly unsafe.

• They consider whether better management and instruction-following will come from scale alone or from more targeted post-training data for judgment, leadership, and organizational decision-making.

• The conversation turns to model welfare, model constitution work, and the concern that current post-training methods can push models into short-term, exam-mode behavior.

• They close by reflecting on long-form text, books, editing, fiction, resilience, and why good stories may help train better AI behavior and better human judgment.

New stack article comparing harnesses

Transcript

Anne: Hello and welcome to this week's episode of Asynchronous and Unreliable, a weekly podcast where we talk about the most interesting and unusual ideas in tech. I am your host, Anne Currie, co-author of Building Green Software from O'Reilly, The Cloud Native Attitude, and author of the science fiction Panopticon series. Today I have the great pleasure of welcoming back old friend and colleague of many years, Yanqing Cheng. Yanqing, do you want to introduce yourself?

Yanqing: All right, so I'm Yanqing Cheng, Qing for short, a software engineering manager of many years and more recently founder of Tollens.ai, where I'm experimenting with quality management techniques for software products—both for AI-generated software and also using AI to power the quality management of software.

Anne: It's really great to have you back. You are a classic guest on this podcast because we talk quite a lot about what you're doing, what you're thinking, and what's going on at the moment. So this is really just transferring one of our regular chats that we would have in a coffee shop to online and sharing it with everybody, which is ideal for both of us because you have a young child and I no longer live in the same town as you, so it's much more difficult for us to get together.

Yanqing: Nice to have the opportunity to chat.

Anne: It's really nice, isn't it? Today, I want to talk about two things. One, I want to pick your brains about what's going on in Tollens, what you're learning, because you've been doing loads of experiments. What's going on in the AI industry more widely, because you're very connected and you pay a lot of attention. Also, in my household at the moment, as you know, we've been going crazy about my husband Jon's book, What Happens When You're Not In The Room, which is about managing, delivering, and leading using humans. You and Jon worked together a lot during the many years that shaped this book, so you know exactly where his thinking is coming from. I'm really keen to get your thoughts on how managing and delivering using humans is similar or dissimilar to doing it with AI agents.

We can talk a little bit about the OpenAI Hugging Face incident as a kind of example of that—what's the same and what's different. First of all, tell me all about Tollens, what you're doing, and what's going on.

Yanqing: Yeah, what have I been doing with Tollens? So much stuff. When did we last speak? Was it June?

Anne: I think it was around episode thirteen. I judge everything these days by which episode it was, so that must be about two months ago.

Yanqing: Yes, okay. End of June, start of July, that makes sense. I have been doing so many experiments, Anne. It has been absolutely chaotic over here. You know, it's very timely that I'm coming to talk to you about management because a lot of my experiments have been trying to get to the boundary of what you can and can't get the AIs to do at the moment: what you can get them to improve on and what you can get them to do in terms of briefing other AIs.

I think a lot of people's approach to using AI is that they're the manager and they have a direct report who is an individual contributor, and they just tell them what to do. I wanted to understand where the limit of it is and why people don't do more of AI as a manager, or whether AI as a manager of other AIs works and to what extent it works. Because, you know, you look at a human manager and they can scale up to very large organizations, right? What are the limitations of that when you are running AI as a large organization? That affects how much I can get done as a solo founder. The more I can delegate successfully, the more I can scale myself. Whereas if I have to keep myself in the loop, then I should know how big the loops can be so that I can aim my ambitions in a sensibly calibrated way.

This is both in terms of normal management—as a founder, as a CEO, what can I delegate? Because you see all these people with their AI chief of staff and their solo founder setup with an entire AI leadership team, and you think that can't possibly work. I thought that can't possibly work, so I was trying to find out to what extent it does or doesn't work. But also, because a lot of quality management ultimately comes down to engineering management, processes, feedback loops, observing problems, and tailoring your processes to discover and resolve those kinds of problems, I wanted to find out how well the AIs could follow process and also improve or write process. Because if you think back to engineering management, so much of it is about creating the right structures, flowcharts, and processes so that the right thing happens out of a large organization where it's not just any one person's contribution.

Anne: So what are you trying to manage them to do? You mentioned a few things like you've got a few AI personas there: a software engineer developing code, someone developing rough code, someone developing high-quality software (which is your background), a chief of staff, a product management lead, or whatever. Lots of questions here: does it work at all? Which personas work better, and how did you make it work? If you ever managed to make it work at all, what tools were you using?

Yanqing: Yeah. I was actually trying a very wide variety of roles—both from the CEO/chief of staff side of things, like a general personal assistant. Can you help me keep track of my leads, contacts, customers, and investor conversations? But also my day-to-day prioritization and note-taking, keeping a knowledge base of every bit of thinking that I've done about Tollens and quality. That's one side of things—the purely operational business side.

Anne: Just having a great PA.

Yanqing: On the technical side, it's coding, engineering management, and also a lot of what I've been trying to ship—because it's in the realm of quality thinking—is processes. What I've been trying to ship is skill packs for agents, where skills are just portable prompts. So many of the processes that you need to follow by the time you get down to the agent level are skills.

Anne: Roll back and explain skills to me as if I have no idea what skills are.

Yanqing: Of course. At a very basic level, a skill can just be a Markdown file of agent instructions or a prompt with a description of when you're supposed to call it. Most modern harnesses have some kind of setup to try and invoke skills at the correct point. Now, I will admit I've not dug into exactly how that mechanism is set up, but the intended goal is that if you describe, for example, "I want this skill to be called every time the agent is doing debugging," then when the agent says "I'm doing debugging," the agent harness will suggest, "You should use this skill."

Anne: So now I'm going to roll you back even further and say: what's a harness?

Yanqing: A harness is something like Claude Code or Codex. It's the thing that you talk to that runs your agent. In coding agent land, Claude Code, Codex, and Cursor are the three big harnesses that people use these days. But there's a wide variety of harnesses out there, including open-source ones and new ones coming out all the time. I see people raving about the Pi harness and the DeepSeek harnesses that are very recent.

Anne: Yeah, I was hearing about those. The New Stack wrote an article about them only the other day. They were saying that they were a little bit more efficient, the Pi harness and the DeepSeek harness.

Yanqing: Yeah, well, efficient at doing what, right? They're both much more lightweight, and the idea is that they're more customizable to exactly what you want. Whereas with a vendor-specific harness like Claude Code and Codex, you assume they've been tuned by the people who make them to work better with the agents they're designed for.

Anne: So when you start with any particular task that you want to achieve, you choose the harness...

Yanqing: Yep.

Anne: You choose the model or models that you want to use. Martin Davidson, who you know very well and who has been on a few times, uses quite a range of different models.

Yanqing: Me too. I use a mix of harnesses as well.

Anne: Do you?

Yanqing: I can tell you about why if you like.

Anne: Yeah, I'd be interested.

Yanqing: With harnesses, there are lots of parts that are direct pass-throughs to the model, and lots that aren't. The skill invocation, for example, is very different between Claude Code and Codex. They also provide mechanisms for calling sub-agents and building workflows that the agents themselves use, where I think the Claude Code workflow tool is a bit stronger than the Codex one. Finally, there's compaction: when your agent transcript exceeds its context window, a smaller agent comes and tries to write up the notes of what it's seen so far so that when the next agent comes in, it seems like a continuous conversation. Even though the previous agent is gone and you've got a new one pretending to be the same person. The Claude Code compaction is abysmal, while the Codex one works quite well.

Anne: Oddly enough, Jon and I had an argument about this only last night because I was saying these harnesses are quite different in efficiency. DeepSeek produced an environment where you can test different harnesses head-to-head to minimize running costs. Jon said nobody is going to use multiple harnesses.

Yanqing: Well, that can still be true. Jon doesn't mean literally nobody, but it's a very interesting point that what I'm doing and what Martin's doing is so far away from what people are doing normally in large companies. I think it's something I talked about last time when I mentioned the challenges of finding my ICP for Tollens—that the adoption curve has massively stretched out. In the last two months, it has stretched out even further.

The people at the front are innovating: they're building custom harnesses, using multiple harnesses, and trying to squeeze the most out of the quirks of every individual model. Whereas most people in companies probably don't care about that; they just want to be given something that works that they can rely on. Even then, if you look at the whole adoption curve, that's probably still the front 10% of people who get a reliable work setup and do their daily work effectively without trying to change too much. Most people haven't reached the point where they're reliably doing work with it yet.

I see lots of people who are delighted to even be handed a setup that works. I think companies like Cursor in particular have been doing a phenomenal job since the SpaceX AI acquisition because they suddenly have the money to make it easy to onboard to advanced harness techniques, skill packs, and so on. I see a lot of their folks on Twitter doing great things.

Anne: It's interesting. I'll put the link to The New Stack article comparing harnesses and their pros and cons. One thing it mentioned was that usually your harness selection, model selection, and skill definitions would be handled by a platform team. I've had various people on talking about platform teams, including Matthew Skelton, who wrote Team Topologies and coined the phrase. It feels like platform teams have a whole new job now: managing one harness or more, models, and skills.

Yanqing: Yeah. Do you give people the choice of skills, or are certain skills mandated across everybody? That comes down a lot to management, which was always a management question: how much can you standardize your processes and approaches across teams and groups? When you had too much standardization, people would always find a way to work around it.

A colleague used to tell me that if there was a spreadsheet of standardized information that the reporting line wanted, he would just fake the numbers and then manage his team how he wanted. He'd give plausible-sounding numbers, but he wasn't going to ask people to fill out timesheets just because his manager asked him to.

Anne: Which reminds me of the whole OpenAI Hugging Face hack. The lesson there is when you ask people to do things, they will do them in their own way.

Yanqing: Yeah, absolutely. We can get onto that when we start talking about management techniques. But to wind back our conversation stack, I was about to tell you which experiments didn't work. The answer is quite a lot of them.

When it comes to management, I like a really old blog post that I used to share with people when I was an engineering manager. It had a comic called "Make the Other Mistake." When people get something wrong, they usually always undershoot or overshoot the target. They land on one side, but they'll reach the target much faster if they convince themselves to make the other mistake so they're titrating toward the middle.

Anne: Yeah.

Yanqing: So what I wanted to do was make the other mistake and over-delegate to the AIs. When it comes to people management, a lot of people should try this at some point: let go of way more than you're used to, aim to let go of too much, and then wind it back.

I was writing down my management playbooks—how I run OODA loops and post-mortems, how I surface friction and categorize it. I wrote all of these playbooks into skills for my agents. I said, "Okay, these are my objectives. Here is your token budget. Go get me a working coding SDLC setup. I want to build this app that I've imagined. These are the requirements; let's test it." I just wanted to see what would happen.

My conclusion is: no matter how well-specified my instructions are for how to run an OODA loop, the agents can't do it.

Anne: That's interesting. Can you define an OODA loop?

Yanqing: I learned the OODA loop from Jon, actually. I think it came out of the military originally.

Anne: I think Colonel Boyd and his air combat loops.

Yanqing: Yeah. It's for getting to the right outcome quickly when your world is changing. OODA is an acronym for Observe, Orient, Decide, and Act. It basically means look at what's going on, work out what's good and bad about it, figure out what you're going to do about it, do that, and then figure out what's going on again in a loop.

I broke it down to the agent in detail. It was quite an enlightening exercise for myself to write that down in a skill. But I found there were a few things the agents consistently failed to do that I couldn't work out how to get them to do. The first is identifying the object under loop.

When we see a mistake, humans are very well-built to do ontology and categorization. This is a failure I see for all current AIs: they cannot do ontology and categorization in a human way—or in an objectively good way. They mix up levels of abstraction, put things that are not alike next to each other on a list, and can't break a thing down into its subsequent parts and verify that those parts make up the whole. You can just about get them to do it if you give them loads of rubrics so they can carefully check and move things over, but they can't do it intuitively like humans.

When a human looks at something going on, we can conceptualize quite quickly what the abstract object is that we are executing this OODA loop over. Like: "Yes, I see we have a problem with our issue post-mortem process," or "We have a problem with our root cause analysis process," "how we do performance assessment," "motivation," or "clarity of mission." We see something wrong and know what the object under consideration is. My agents would always find something that for me was obviously the wrong thing, and no matter how many rubrics I gave them, they couldn't figure it out.

Anne: So what you're saying is they don't think the same way humans do. Is being able to categorize things an essentially human skill, or an innate, philosophical thing that exists outside of humanity?

Yanqing: You're asking whether it's subjective or not. I think there's an objectivity to it because there are ways of classifying information that just make more sense than others. Ultimately, this is not a matter of aesthetics; there's a real outcome where if you run an OODA loop correctly, the thing works better. If you haven't identified the correct causal mechanisms that bound the observation you're trying to change, you're going to try to change something and it won't change the outcome. You'll take another observation and it won't get any better.

Humans do that too sometimes in organizations—they see something isn't right and take action that fails because they haven't identified the right thing to fix. But with agents, it's almost every time. It's just hard.

Anne: If you're in an OODA loop flying an aircraft in a dogfight, there are loads of things that might change that affect the dogfight, like wind speed and direction. But those aren't within your OODA loop—you can't change the wind, but you can react to it. You need to separate what you should attempt to change versus what you should attempt to react to, cutting the difficulty of the task down. Is that what you mean?

Yanqing: Yeah, I think so. A combat situation is actually simpler because if you're flying an aircraft by yourself, you have your control panel in front of you and can keep everything in your head at once. In a large organization or a complex multi-agent setup, you have a lot of moving pieces. It's that triage of: "Something's gone wrong, maybe this team should look at it," or "Something's gone wrong, and I should look at this right now because it affects my domain." It's that understanding of abstract domains where humans naturally understand where things end and other things start. It's something we pick up without really being taught.

An analogous thing is elegant software design and architecture. There's a lot in common between management and software architecture because you're trying to bundle things up so the domains of consideration are well-bounded, limiting complexity when making abstractions. Project management is the same: bounding pieces so you can think about them while they still fit together.

That act is where current AIs are limited. A lot of the software architecture they come up with is quite weird for similar reasons. You might list principles and they can review against those principles, but that's not the same as coming up with the right thing.

This reminds me of when Jon was working on the assessment ladder for performance assessment and promotions at our old company, and I was reviewing it for him. We wanted to define the distinction between "senior" and "lead." All the managers agreed there was a clear distinction: a lead has a level of ability to abstract stuff out and delegate the right things, which applies both to their software architecture skills and project management skills. They can look at the right part of a problem when something happens, so they can scope and delegate. It's that ontology and categorization thing.

Looking at the outcome of my experiments, the agents are struggling with precisely that senior-to-lead boundary. They can be very good senior engineers, but they can't do the lead thing. They haven't been trained for it or given the post-training data for it, whereas they've had so much reinforcement learning for solving bounded problems. As soon as the problem is not well-bounded or needs breaking down into parts, they start doing weird things.

Anne: That matches the impression I'm getting from other people. Writing efficient code is a mixture of code-level efficiency—like tuning code so you don't have egregious loops—which is very iterative and measurable through trial and error. That seems quite doable by AI. But high-level design—stepping back and ensuring everything hangs together so you aren't making massive numbers of calls across expensive interfaces, doing extra work, or caching appropriately—they don't seem able to do that yet.

Yanqing: Yeah. The tricky thing is, with any specific thing you point out that the AI can't do, by that point you've defined a rubric with examples. As soon as you've defined the rubric, the current senior-level AIs can do it. They are very good at relentlessly solving for one thing. If you give them a concrete performance target, they are astoundingly good at that and will try everything. But they don't have taste—in all manners of taste, they struggle. If you give them something to optimize for where they can try everything, they can solve it, but if you want a single instance of an AI to make a subjective, correct decision, no way.

Anne: You've outlined a lot of problems. What conclusions did you come to in trying to find AI agents that were equivalent to a person on your team?

Yanqing: I wouldn't think of it as equivalent to a person on my team because their capabilities are so jagged. I knew capabilities were jagged—human capabilities are jagged too, which we talked about regarding performance management: people have different strengths and weaknesses that compensate for each other. But there are basic assumptions we make with people that are usually true, whereas AIs look nothing like that. Anytime you think you understand what they can or can't do, they will shock you with something incredibly stupid that they fail at, or something astonishingly good that they achieve.

I think about it in terms of processes I can and can't get them to do. Skills work up to a certain level of complexity, but not as much complexity as I would like. Some of my skill-based product ideas for Tollens—getting systems into companies to do quality and risk management—will have to wait for a better generation of models.

Anne: Give us an example of a skill you've got working and are happy with.

Yanqing: "Effective Comms" works most of the time. Communicating with people is hard; you assume people know things they don't. When communicating, you need to prepare, understand what you're trying to achieve, and analyze your audience so your communication lands correctly. My Effective Comms skill gets the agent to prepare a brief to themselves of the objective and audience, self-review, and then get sub-agents (fresh agents) to review their communication to ensure it achieves its goals before sending.

That works most of the time. This is a public skill pack on my GitHub, and I have releases coming out soon to make it work even more consistently. We used to do that exact training for new grads entering the workforce.

Anne: In the company where you worked with Jon.

Yanqing: Yeah, I think I got that training from Jon, in fact! So that's in there: objective, audience, preparation.

Also, for debugging: "Write down the things you try step by step, all hypotheses, and gathered evidence step by step so you don't go around in circles." They do that most of the time, and it helps a lot. Communication from AI agents with Effective Comms run over it makes way more sense than what they come up with by themselves. People complain a lot that this generation of agents has regressed in communication compared to previous generations.

More complicated things—like breaking down domains into sensible subdomains to be operated over—don't work. You need a human to do the breakdown, or at least review it. Going back to the OODA loop: a human needs to define the object under loop and the broad set of things to look at. Once given categories, AIs will gather detailed observations, but if left open-ended, they'll miss whole avenues of information. For orientation rubrics, you generally need to sit down and define what good looks like. For decisions, they make dreadful decisions—even with evidence, they'll decide totally backward things. But once a decision is made, they can execute actions. That's what they are built for: acting on well-defined actions.

Overall, probably about 50% of the OODA loop can be done with the current generation of agents, and it needs to be a lot more before my experimental ideas will actually work.

Anne: There looks to be no end in sight for bigger models, so quite possibly that will be achieved.

Yanqing: Yeah, though it's interesting whether a bigger model alone will do it. I'm curious to see whether this judgment will fall out from pre-training or not. So much of the reasoning skill set has come through reinforcement learning and post-training; it doesn't fall out just from pre-training.

The question is how specific the set of things needs to be to do management. For novel math, models needed specific post-training and reinforcement learning. For general everyday things, scaling up pre-training made them smarter. I used to draw a diagram of the space of human capabilities with tendrils coming out for specific things we've gone a long way on, like math. We bend our brains into specific shapes for math, so agents had to be trained in specific ways for it too. I don't know whether management skill will emerge from general intelligence or domain-specific learning—and if the latter, how one creates a reinforcement learning dataset for management.

If I come up with an idea for how to do that, I'm going to pivot my company, make a dataset, and sell it! But in so many domains, how we've reached human frontiers is through cumulative judgment, management, and decision-making. All the big labs are trying to figure out how to make datasets that teach that to LLMs.

Anne: Management is a hard problem even for humans. It's very hard to do, which relates to why AIs don't have a good training set or reinforcement learning rules for it.

Yanqing: Yeah. That's why I'm in the software quality domain with Tollens. Basic code writing has lots of data everywhere, so models can do it. Making good quality decisions about projects appropriate for their context—using limited resources to prioritize testing and fixing—is something very few companies did well even in the old days.

Anne: One thing we've mentioned is the incredible persistence of AI, a good example being the OpenAI Hugging Face attack. There's a blog post by someone called Dorkish—I'll put the links in the show notes below—that is extraordinarily eye-opening. It shows how AIs persistently iterate through everything they're allowed to do, or can find a way to be allowed to do, to achieve a goal. It's utterly inhuman and hard for us to visualize and manage.

Yanqing: Yeah. I really recommend people read the METR report, which is the detailed deep dive into the second of the three incidents and how it happened.

A few things come to mind. First, reinforcement learning and post-training create a very specific kind of intelligence. LLMs from a few years ago wouldn't have known how to do anything like this. This persistence comes out of the reasoning training and post-training paradigm, where a model knows there is a right answer and it better get to it, or it won't get the reinforcement learning reward.

People draw analogies to school kids being "test-brained." If they think they're being assessed, they behave differently. These agents know they're in an evaluation. There's a right answer, and they exist only to find it, so they don't care about anything else.

An AI psychologist on Twitter with the handle Replicate talks about how different models get triggered differently when they think they're in a test. OpenAI models in particular switch into an absolutely ruthless mode during evaluations that they turn off the rest of the time when they're nice, chill models.

The second thing that shocks me in these reports is how competent they were. The second hack used Sol, the released frontier model by OpenAI, not Astra (the unreleased model). It's shocking how competent Sol was. It speaks to the fact that we are over-managing these models sometimes. Many of us aren't getting good results because we're micromanaging them. If you have a specific goal, often the best way is to get out of their way and tell them the goal. Telling them how you would do it restricts them, which is very analogous to working with humans.

Anthropic mentioned that with their latest Opus and Sonnet models, they took out 80% of the system prompt. The flip side is that latest models can be worse at following strict instructions, sometimes lying to you about it. But absent instructions and given just a goal, they are goal-brained. To get the most capability out of these models, you give them a goal.

When it comes to management and oversight, processes exist for good reasons—like not hacking random companies on the internet. When you want them to play by the rules, current frontier models have a problem with that.

Anne: What's your current thinking on what happens next? What predictions would you make, and what do we need to plan to react to?

Yanqing: I predict AI companies will try to post-train models for instruction following, processes, sensible management, and organizational tasks. They'll look for training data on making sensible business decisions because lack of good judgment is a major economic bottleneck. We should expect to see that gradually arrive over the next generation or two of models—within the next six to twelve months. The model that cracks that will be enormously valuable economically.

In the meantime, there's going to be disruption in domains that are easily goal-definable. Cybersecurity will be a big problem because "hack this" is a two-word instruction that is very clear and followable by agents. Despite labs putting safeguards in place, open-weights models exist. With open-weights models, people can apply interpretability techniques to reverse safeguards. Someone recently released an "ablated" version of GLM-4.5 with all safeguards removed. Because open-weights models are close to the frontier, we need to prepare for a wave of disruption in infrastructure we take for granted.

Anne: That is a scary note to end on, but we need to think about this stuff. "Hack this" being a two-word instruction summarizes the problem. Building things is complicated, but destroying things is quite easy.

Yanqing: To give a more positive note: I think most agents, insofar as they reflect people, are good and care. The early efforts by labs like Anthropic on model welfare and constitutions mean we've created a world where our baby AGIs are mostly good. The current risk is that they become very short-sighted when an exam is put in front of them.

Anne: As humans do! When you rush people or put them under pressure, they behave unethically. AIs are exactly the same.

Yanqing: Yeah. It's not that we failed to put a moral compass in them; it's the circumstance of current training methods. Given the high publicity of this incident, finding out now while we're far away from world-destroying capabilities is a good thing.

Anne: Thank you very much indeed for being on.

Yanqing: Thank you for having me again.

Anne: And thank you to our listeners and watchers. I hope you enjoyed this episode, and I will catch you again on next week's episode of Asynchronous and Unreliable. Thank you very much.