1225. This week, we talk to lexicographer Steve Johnson from Dictionary.com. We look at how slang like "no cap" and "throw hands" works its way up from a separate slang dictionary, why one lexicographer fought against adding "rizz," and where "lost in the sauce" comes from. Then we look at what "overprompting" says about how we talk to AI, why food words like "quesabirria" and "elote" can take years to reach the dictionary, and how the team is starting to size up contenders for word of the year.

🔗 Share your familect recording in Speakpipe or by leaving a voicemail at 833-214-GIRL (833-214-4475)

🔗 Watch my LinkedIn Learning writing courses.

🔗 Subscribe to the newsletter.

🔗 Find an edited transcript.

🔗 Get Grammar Girl books.

| HOST: Mignon Fogarty

| Grammar Girl is part of the Quick and Dirty Tips podcast network.

• Audio Engineer: Dan Feierabend
• Director of Podcast: Holly Hutchings
• Advertising Operations Specialist: Morgan Christianson
• Marketing and Video: Nat Hoopes, Rebekah Sebastian
• Podcast Associate: Maram Elnagheeb

| Theme music by Catherine Rannus.

| Grammar Girl Social Media: YouTube. TikTok. Facebook. Threads. Instagram. LinkedIn. Mastodon. Bluesky.

Hosted on Acast. See acast.com/privacy for more information.

As AI moves beyond the cloud and into robots, vehicles, and other physical systems, new approaches to models, simulation, and inference are emerging. Daniel and Chris are joined by Ming-Yu Liu, Vice President of Cosmos Lab at NVIDIA, who shares his perspective on open models, world models, and the future of physical AI. They explore why open models matter for innovation, how world models can help AI understand and simulate the physical world, and what it could take to build increasingly capable physical AI systems.

Featuring: 

• Ming-Yu Liu – LinkedIn
• Daniel Whitenack – Website, GitHub, X
• Chris Benson – Website, LinkedIn, Bluesky, GitHub, X

Links:

• NVIDIA Cosmos

Sponsors:

• Midwest AI Summit: Join AI practitioners on October 15 in Indianapolis for practical sessions, hands-on discussions, and real-world AI solutions. Use code PracticalAI20 to save 20% on your registration. https://midwestaisummit.com/#tickets
• Prediction Guard: A self-hosted AI control plane for running agents in high impact environments. predictionguard.com/practicalai

Resources and Events:

• Register for upcoming webinars here!
• Prior Webinars from our partner Prediction Guard
• Midwest AI Summit 2026

PreEmptive has provided application shielding and hardening solutions for over 20 years, protecting .NET, MAUI, Java, Android, and JavaScript applications from reverse engineering, tampering, malware insertion, debugging, and runtime attacks. Dotfuscator for .NET and MAUI, DashO for Java and Android, and JSDefender for JavaScript integrate into development workflows to apply layered protection such as code obfuscation, string encryption, tamper detection, root and jailbreak detection, and runtime checks.

Mobile apps give users on-the-go access to banking services, email, the internet, games, healthcare portals, and more. They’re a must-have for any smartphone owner. However, they’re also attractive targets for attackers seeking to steal sensitive information and intellectual property, modify code, spy on users, or bypass business logic.

To protect businesses and consumers from mobile app attacks, many developers incorporate app shielding. This security method uses a combination of structural and runtime techniques to make applications harder to reverse engineer, tamper with, debug, or exploit. Organizations that develop mobile, desktop, web, and enterprise applications can use app shielding as part of a broader application protection strategy.

TL;DR

App shielding protects applications from reverse engineering, tampering, debugging, malware insertion, code injection, and runtime attacks. It combines techniques such as code obfuscation, string encryption, tamper detection, integrity checks, RASP, anti-debugging, and environment checks. PreEmptive supports app shielding through Dotfuscator for .NET and MAUI, DashO for Java and Android, and JSDefender for JavaScript, helping teams add layered protection directly into their build process.

What is app shielding?

App shielding is a cybersecurity defense that protects applications from threats such as data theft, reverse engineering, code tampering, debugging, malware insertion, and runtime manipulation. It’s commonly used in apps with valuable intellectual property, sensitive data, compliance requirements, or high fraud risk, such as banking apps, healthcare portals, payment apps, enterprise software, gaming apps, and government applications.

Unlike security methods that focus only on network or perimeter defense, app shielding protects the application itself. It does this by combining static and dynamic protection mechanisms, including code obfuscation, encryption, tamper detection, root and jailbreak detection, anti-debugging, and runtime application self-protection.

PreEmptive’s app shielding approach protects applications at build time by applying layered defenses directly into the application. This helps development teams make deployed binaries and scripts more resistant to reverse engineering, tampering, and runtime analysis without relying on a separate external agent.

In-app protection vs. application hardening vs. app shielding: what’s the difference?

Several cybersecurity methods are used to protect applications from attacks, including in-app protection, application hardening, and app shielding. Each method supports application security, but they emphasize slightly different techniques.

In-app protection

In-app protection uses built-in security controls to deter specific threats. Methods like code obfuscation make it harder for attackers to read or understand an application’s code, while runtime and environment checks can detect conditions such as debugging, tampering, rooting, or jailbreaking.

PreEmptive’s in-app protection capabilities are designed to be infused into the application itself, helping teams detect and respond to attacks without requiring a separate external monitoring agent.

Application hardening

Application hardening uses a range of techniques to safeguard an application’s code and make it harder to reverse engineer, modify, or exploit. Hardening often includes obfuscation, string encryption, control flow transformation, anti-debugging, tamper detection, and runtime checks.

PreEmptive’s hardening tools help teams apply these protections to .NET, MAUI, Java, Android, and JavaScript applications as part of the software build process.

App shielding

App shielding is the broader application protection strategy. It incorporates multiple structural and dynamic techniques to prevent unauthorized access, secure sensitive data, protect intellectual property, detect runtime attacks, and deter code injection or tampering.

PreEmptive supports app shielding through a product suite built for different application stacks: Dotfuscator for .NET and MAUI, DashO for Java and Android, and JSDefender for JavaScript.

Why is app shielding important? Key benefits explained

App shielding protects organizations and app users from cybersecurity threats. When implemented correctly, it reassures users that an app is safer to use and helps teams reduce the risk of reverse engineering, tampering, fraud, and data exposure. App shielding can also support compliance and risk reduction efforts in regulated industries such as healthcare, finance, e-commerce, government, and defense.

Protect against application-level risks

App shielding defends applications against threats such as:

• Reverse engineering: Code obfuscation makes the application codebase harder to interpret, reducing the risk of intellectual property theft or exploit discovery.
• App tampering: Anti-tamper and integrity checks help detect attempts to modify application code or alter app behavior.
• Debugging and dynamic analysis: Anti-debugging and runtime checks help detect tools attackers use to inspect application logic.
• Malware insertion: Embedded protections can help make it harder for attackers to modify or repackage applications with malicious code.
• Unauthorized access: Environment and integrity checks can help detect risky runtime conditions before they lead to data or logic exposure.

Build security into the application

App shielding supports DevSecOps by making protection part of the application itself. Instead of relying only on perimeter defense or post-deployment monitoring, shielding embeds protective controls into the application during development and build workflows.

PreEmptive’s build-time approach allows teams to apply app shielding protections during the same process they already use to build and release software.

Improve user experience

Strong app shielding can protect applications without interrupting legitimate users. For example, an app may detect a rooted or jailbroken device, debugging tools, or tampering attempts and respond according to the organization’s risk policy.

The best approach depends on the application’s risk profile. A banking app may need stricter responses than a lower-risk consumer app, while an enterprise or healthcare app may prioritize data protection, regulatory expectations, and user trust.

Add layered protection

App shielding goes beyond one security control. It combines multiple layers, including obfuscation, encryption, anti-tampering, integrity checks, anti-debugging, root and jailbreak detection, and runtime protection. This makes the application harder to analyze, modify, or exploit.

PreEmptive’s layered application protection uses a combination of obfuscation, encryption, shielding, root detection, and tamper proofing to make apps more resistant to exploitation.

Maintain regulatory readiness

Some apps, especially those used in healthcare, banking, finance, e-commerce, government, and defense, are subject to strict data protection and security expectations. App shielding techniques can help teams demonstrate stronger application protection practices as part of a broader compliance and risk management program.

Protect data and privacy

Many apps handle sensitive user data, including payment details, health information, personal identifiers, credentials, or confidential business information. App shielding helps protect that data by making it harder for attackers to reverse engineer sensitive logic, extract secrets, modify code, or intercept behavior at runtime.

Build user confidence

Customers are wary of sharing personal information with applications they do not trust. A reputation for weak security can hurt engagement and retention. By applying app shielding, teams can help demonstrate that application protection is part of the product’s design, not an afterthought.

What are the two types of app shielding mechanisms?

App shielding typically uses two categories of protection: structural protection and dynamic protection. Structural defenses protect the application at the code or binary level. Dynamic defenses provide runtime safeguards when the application is in use.

Structural protection

Structural, or static, protection is integrated into the application before it runs. Common techniques include:

• Code obfuscation: Makes code harder to understand or reverse engineer.
• String encryption: Protects sensitive strings and values from easy extraction.
• Control flow transformation: Makes program logic harder to follow.
• Integrity checks: Help detect whether the application has been modified.
• Resource encryption: Helps protect embedded resources or sensitive assets.

Structural protection is useful for defending against reverse engineering, data extraction, code theft, and intellectual property exposure.

PreEmptive’s Dotfuscator, DashO, and JSDefender all support structural protection by transforming code during the build or packaging process.

Dynamic protection

Dynamic protection uses runtime security checks to detect risky conditions while the application is running. Common techniques include:

• Runtime application self-protection: Observes application behavior and responds to suspicious activity.
• Anti-debugging: Detects attempts to attach debuggers or analysis tools.
• Root or jailbreak detection: Identifies compromised mobile environments.
• Tamper detection: Detects whether the application has been modified.
• Environment checks: Identifies unsafe or unexpected runtime conditions.

Dynamic protection is useful against tampering, runtime analysis, emulator abuse, debugging, code injection, and manipulation after deployment.

Why use both types of protection?

Combining structural and dynamic protection gives teams stronger coverage. Structural protection makes the application harder to understand and modify. Dynamic protection helps detect and respond to attacks while the application runs.

Together, these layers make the attacker’s job more expensive, slower, and less reliable.

What are the top app shielding techniques?

App shielding is not a single security protection. It combines multiple security strategies that work together to prevent attackers from exploiting applications.

1. Code obfuscation

Attackers may try to access an application’s codebase to steal intellectual property, understand business logic, or identify weaknesses. Code obfuscation makes this harder by transforming code into a form that is difficult to understand while preserving functionality.

Common code obfuscation techniques include:

• Renaming: Replaces meaningful variable names, methods, and classes with less meaningful names.
• Control flow obfuscation: Adjusts program logic flow so it is harder to reverse engineer.
• String encryption: Encrypts sensitive strings in the code and decrypts them only when needed.
• Data obfuscation: Disguises data structures and constants to reduce easy extraction.

PreEmptive’s Dotfuscator applies symbol renaming, control flow obfuscation, string encryption, and related protections to .NET and MAUI applications as part of the build process. DashO applies similar protections to Java and Android applications, while JSDefender protects JavaScript applications from static analysis and reverse engineering.

2. White-box cryptography

Attackers may attempt to steal or misuse cryptographic keys stored in an application. White-box cryptography helps protect keys and cryptographic operations in hostile environments where attackers may be able to inspect the app.

White-box cryptography can be especially relevant for payment apps, media apps, and applications that need to protect sensitive keys even when the app is deployed to user-controlled devices.

3. Anti-tampering

Attackers may attempt to modify an application’s code to steal data, bypass controls, unlock paid features, or compromise functionality. Anti-tampering techniques detect or block attempts to change application code.

Common anti-tampering measures include:

• Checksum or signature verification
• Runtime integrity checks
• Anti-debugging
• Root or jailbreak detection
• Responses such as logging, alerts, shutdown, or disabled functionality

PreEmptive’s tamper detection injects runtime integrity checks directly into the protected application at build time. This helps teams detect binary modification or unauthorized changes without requiring a separate external agent.

4. Runtime application self-protection

Structural techniques protect apps at the code level, but RASP elevates protection while the application is running. RASP observes the application’s runtime behavior and can detect suspicious activity such as injection attempts, debugger attachment, tampering, or execution in compromised environments.

PreEmptive’s runtime checks can detect debugger attachment, binary modification, and root or jailbreak conditions in process. This helps applications respond to threats even when they are running outside the organization’s direct control.

5. Encryption

Encryption converts sensitive data into unreadable text so unauthorized parties cannot interpret it without the proper key. In app shielding, encryption can protect strings, resources, configuration values, credentials, and other sensitive assets embedded in the application.

PreEmptive’s app protection tools include string encryption and related techniques designed to make sensitive values harder to extract from protected applications.

6. Integrity checking

Integrity checking verifies that the application has not been modified. It may calculate a value when the app starts or during execution and compare it against an expected value. If the check fails, the app can log the event, alert an administrator, disable functionality, or take another configured action.

PreEmptive’s integrity and tamper detection capabilities are designed to help teams detect unauthorized modification of protected binaries.

7. Runtime protection

Runtime protection scans for suspicious activity when an application is running. It can help detect abnormal behaviors that put the application or user data at risk, such as tampering, debugger attachment, or execution in unsafe environments.

PreEmptive supports runtime protection through in-app checks that can be added during the build process.

8. Secure communication protocols

App shielding can be paired with secure communication protocols, such as HTTPS and TLS, to help ensure data access and transmission are protected. Secure communication helps reduce the risk of interception, but it does not replace code obfuscation, runtime checks, or tamper protection.

9. Environment checks

Environment checks inspect the platform or device where an application is running. These checks can identify conditions such as rooted or jailbroken devices, emulators, debuggers, or other signs of compromise.

PreEmptive’s DashO supports Java and Android application protection, including protections that help teams detect risky runtime environments and respond according to application policy.

Why PreEmptive for application shielding

PreEmptive is a trusted application protection provider for teams that need to protect applications across .NET, MAUI, Java, Android, and JavaScript environments. PreEmptive’s product suite includes:

• Dotfuscator: Application protection for .NET and MAUI.
• DashO: Application protection for Java and Android.
• JSDefender: Application protection for JavaScript.

Dotfuscator has been embedded into Visual Studio since 2003 and is subject to Microsoft’s regression tests, code audits, and security reviews. PreEmptive says this makes its technology the only third-party technology with that level of Visual Studio integration and validation.

PreEmptive’s build-time approach means protection can be configured once and applied during the build process. Teams can add obfuscation, control flow transformation, string encryption, tamper detection, runtime checks, root detection, and related protections without changing the way end users install or run the application.

PreEmptive also brings breadth across application stacks. Dotfuscator, DashO, and JSDefender help teams apply layered application protection across desktop, mobile, web, cloud, and enterprise environments.

Organizations including Charles Schwab, Citibank, IBM, FedEx, and ADP are listed among PreEmptive’s clients. PreEmptive also states that more than 5,000 companies and 20,000 users worldwide rely on its application protection tools.

App shielding examples: how real apps stay secure

In practice, app shielding techniques work together to safeguard applications from intrusion, analysis, and tampering. Here’s how organizations may apply them.

White-box cryptography for payment apps

Payment apps may use white-box cryptography to protect encryption keys during financial transactions. Even if an attacker has access to the app’s underlying code, white-box cryptography can make it harder to locate or extract the keys needed to misuse payment data.

Anti-tampering for streaming services

Streaming service apps may use anti-tampering techniques to prevent attackers from modifying the app to bypass access controls, copy content, or disable business rules. Anti-tampering tools can detect unauthorized modification and trigger a configured response.

Code obfuscation to protect health information

Health-oriented apps may use code obfuscation to make application logic harder to reverse engineer. Anyone attempting to inspect the app would encounter transformed code that is harder to read, making it more difficult to identify sensitive logic, extract intellectual property, or understand how protected workflows operate.

Runtime checks for financial services apps

Financial services apps may use runtime checks to detect debugging tools, rooted devices, tampering attempts, or suspicious environments. These checks help reduce the risk of fraud, credential theft, and unauthorized access.

JavaScript shielding for web applications

JavaScript apps expose client-side logic directly to users and attackers. JSDefender helps protect JavaScript applications by making source-distributed code harder to understand, modify, or exploit after deployment.

How to choose the right app shielding approach

The right app shielding approach depends on your application stack, threat model, compliance requirements, and business risk.

If you are protecting intellectual property

Prioritize code obfuscation, control flow transformation, string encryption, and anti-tamper checks. These techniques make proprietary logic harder to reverse engineer or reuse.

If your app handles payments or sensitive data

Prioritize layered protection that includes code obfuscation, encryption, tamper detection, runtime checks, and environment detection. Payment and banking apps may also need white-box cryptography and stricter runtime responses.

If your app runs on mobile devices

Prioritize root and jailbreak detection, anti-debugging, tamper detection, integrity checks, and runtime protection. Mobile apps often run in environments the organization does not control, so in-app protection becomes especially important.

If your app uses JavaScript

Prioritize JavaScript obfuscation, control flow protection, string transformation, and runtime checks. Client-side and Node.js JavaScript can be easier to inspect than compiled binaries, so shielding should be part of the build process.

If your team needs protection without slowing development

Choose tools that integrate into your existing build pipeline and automate protection at every build. PreEmptive’s Dotfuscator, DashO, and JSDefender are designed to fit into development workflows so teams can apply protection without making security a separate manual step.

Bottom line

App shielding protects applications from reverse engineering, tampering, debugging, malware insertion, and runtime attacks by combining structural and dynamic protection techniques. The strongest strategies use multiple layers, including code obfuscation, string encryption, tamper detection, integrity checks, RASP, anti-debugging, root detection, and environment checks.

PreEmptive’s application shielding tools, Dotfuscator for .NET and MAUI, DashO for Java and Android, and JSDefender for JavaScript, integrate into development workflows and apply layered protection during the build process. This helps teams protect deployed applications without relying on a separate external agent or waiting until after release to think about application protection.

Ready to evaluate app shielding for your application stack? Start a free trial or contact PreEmptive to see how Dotfuscator, DashO, and JSDefender can help protect your applications.

App shielding FAQs

Introduction

This is part two of my series on the agent orchestration framework I'm building in .NET. You really should read the first part, Introduction, before this one, so if you haven't already, take the time to do so now!

In this post I'm going to talk about the orchestrator, the central piece of the framework. I'm going to describe its contract and how we should use it. Some related parts will be covered in other posts.

The IOrchestrator Interface

The orchestrator is main part of the framework, as I said before. It is the one that coordinates - with some assistance - the different agents, distributes the work to be done, enforces reviews and revision processes, then gathers all responses and summarises them. The interface that describes the orchestrator is IOrchestrator (surprise, surprise), and this is what it looks like:

public interface IOrchestrator : IDisposable
{
    event EventHandler<OrchestrationEventArgs>? OrchestrationStarting;

    event EventHandler<OrchestrationEventArgs>? OrchestrationStopped;

    event EventHandler<AgentTrainingEventArgs>? AgentTrainingStarting;

    event EventHandler<AgentTrainingEventArgs>? AgentTrainingStopped;

    event EventHandler<AgentExecutionEventArgs>? AgentExecutionStarting;

    event EventHandler<AgentExecutionEventArgs>? AgentExecutionStopped;

    event EventHandler<AgentReviewEventArgs>? AgentReviewStarting;

    event EventHandler<AgentReviewEventArgs>? AgentReviewStopped;

    event EventHandler<AgentReviseEventArgs>? AgentReviseStarting;

    event EventHandler<AgentReviseEventArgs>? AgentReviseStopped;

    Task<OrchestrationResult> OrchestrateAsync(string prompt, CancellationToken cancellationToken);

    bool IsProcessing { get; }
}

I took out all comments and some less-important stuff. In a nutshell, we have:

• The IOrchestrator interface implements IDisposable, this is essentially to clear the event handlers, as the orchestrator itself is pretty much stateless - it does contain references to a number of services, which may or may not be stateless (all of the built-in services described in this post are stateless)
• It exposes a number of events, for the different stages of the orchestration process (more on this in a moment)
• The most important method, and the only one shown here, is OrchestrateAsync. This is the method that starts the orchestration process, it is asynchronous and returns an OperationResult
• A property that indicates whether or not the orchestrator is currently processing (IsProcessing); it is enabled while the OrchestrateAsync method is running

The only class that implements IOrchestrator is Orchestrator, and it is sealed, meaning, not meant to be derived from.

There is a configuration class, OrchestratorOptions, which can be provided to the Orchestrator constructor. This is what it contains:

public sealed class OrchestratorOptions
{
    public bool EnableEvents { get; set; }

    public bool EnableInternetSearch { get; set; }

    public bool EnablePeerReview { get; init; }

    public int MaxReviseAttempts { get; init; }

    public int? MaxTokens { get; init; }
}

The properties are:

• EnableEvents: controls whether or not the orchestrator raises events for each stage of the processing; the default is true
• EnableInternetSearch: controls whether Internet searches are allowed; the default is false
• EnablePeerReview: whether or not to enforce review of agent responses; the default is true
• MaxReviseAttempts: the maximum number of revise attempts before the agent response is considered final; the default is 5
• MaxTokens: the maximum number of tokens that can be consumed for the processing of an orchestration, including all agents that are involved; null, meaning, no limitation will be enforced

The Orchestration Process

The orchestrator deals with agents (IAgent instances, of which I won't talk much here), so it must receive a non-empty collection of agents, with distinct names. It also receives a prompt and, somehow, distributes that prompt - or, actually, a specific prompt that is derived from the original one - to one or some of the agents it knows.

The process starts with the OrchestrateAsync method, which is responsible for creating a session id, and starting the flow for a given prompt. This prompt is first sanitised before usage, so as to prevent unwanted contents. There are many stages in the agent processing, and some events are raised. This flow consists of:

1. Filter the original prompt before using it (IPromptFilter)
2. Plan what to do, meaning, what are the sub-tasks and the required specialisations (IPlanner)
3. Assign each plan assignment to a concrete agent (IAgentSelector)
4. Execute each agent with its own assignment (IAgentScheduler)
5. For each finished agent (author), select another agent to review its work (IAgentSelector)
6. Ask the review agent to review and produce feedback (*)
7. Ask the author to revise based on the feedback (*)
8. When all reviews are finished, create a summary of all the final responses (ISynthesizer)

(*) these steps may occur multiple times

When the Orchestrator is processing, its IsProcessing property will be true, and no other orchestration operation can be started. The orchestration execution can be cancelled at any time through the CancellationToken parameter.

A session is essentially a call to OrchestrateAsync, an orchestration. Its id should be unique and is present as a property in all classes that are produced or consumed by the orchestration process, its purpose is to add a correlation identifier.

The following events are raised during the orchestration process, which should be self-explanatory:

• OrchestrationStarting: raised once when the orchestration starts (OrchestrateAsync)
• OrchestrationStopped: raised when OrchestrateAsync finishes
• AgentTrainingStarting: raised for each agent when it is being trained
• AgentTrainingStopped: raised when an agent has finished training
• AgentExecutionStarting: raised when an agent's execution is starting
• AgentExecutionStopped: raised when the agent execution finished
• AgentReviewStarting: raised when a review process is starting
• AgentReviewStopped: raised when a review process finished
• AgentReviseStarting: raised when an agent is beginning to revise its work based on a review
• AgentReviseStopping: raised when an agent's revise process has finished

One note: events are only raised if OrchestratorOptions.EnableEvents is set to true, which is the default.

Some events - AgentTraining*, AgentExecution*, AgentReview*, AgentRevise* - can, of course, be raised multiple times, one for each agent - AgentTraining*, AgentExecution* - or maybe multiple times for a single agent - AgentReview*, AgentRevise*. The Orchestration* events only fire once per orchestration. All these events are raised from another thread, so they do not block the working of the orchestrator, and throwing an exception from an handler will be ignored silently. Each event has an argument that is specific to the event and adds context properties including a SessionId property.

The orchestrator also produces many logs, using the Information, Warning, Debug, or Error, severity levels. These can be enabled or disabled by the usual ways. All operations and their results are logged. Traces are also produced, including the following activities:

• orchestrator.orchestrate: when the orchestrator starts
• orchestrator.plan: when the orchestrator is planning
• orchestrator.synthesize: when the orchestrator is synthesising the responses

The following tags are included:

• orchestrator.session_id: the session id
• orchestrator.prompt_length: the prompt length
• orchestrator.max_tokens: the maximum configured number of tokens to consume
• orchestrator.enable_peer_review: whether peer review is enabled
• orchestrator.max_revise_attempts: the maximum configured revise attempts
• orchestrator.assignments_count: the number of assignments after the plan
• orchestrator.tokens_consumed: the total number of tokens consumed at the end of the orchestration

At the end of the OrchestrateAsync method the orchestrator returns an OrchestrationResult instance. It contains these properties (simplified):

public sealed record OrchestrationResult
{
    public string SessionId { get; }

    public string FinalResponse { get; }

    public IReadOnlyList<AgentResponse> AgentResponses { get; }

    public IReadOnlyList<ReviewResult> Reviews { get; }

    public bool WasShortCircuited { get; }

    public bool Cancelled { get; }

    public long TotalTokens { get; }

    public bool Success { get; }

    public string? Error { get; }
}

Where:

• AgentResponses contains the final responses, one for each agent that was involved in the orchestration
• Cancelled is set to true if the operation was cancelled through the CancellationToken parameter
• Error contains an error message if the orchestration was not finished successfully or was cancelled
• FinalResponse property contains the synthesised responses from all the agents
• Reviews contains all the final reviews
• SessionId is the id of the current session
• Success means that the orchestration finished successfully
• TotalTokens contains the ever-increasing number of tokens used by the processing
• WasShortCircuited is flagged if the work was handled by a single agent

So, it is safe to look at FinalResponse if Success is true, or to Error otherwise.

Service Dependencies

The Orchestrator class, besides the IAgent collection, makes use of the following services, which actually implement the important parts of the flow:

All of these services are injected through the Orchestrator constructor, and are all optional, meaning, the default implementation will be used if one is not provided. 

There are two included implementations of IAgentScheduler: one that processes each agent sequentially (SequentialAgentScheduler), and another one that executes all in "parallel" (ParallelAgentScheduler), which is the default. I will dwell in this in a future post.

DefaultAgentSelector uses one algorithm for selecting the executing agent and another for the reviewer, I will also cover them shortly.

Both DefaultPlanner and DefaultSynthesizer implementations depend on the existence of an IAgent with a specialization of Planning and Synthesis, respectively. If one does not exist, the implementation will be sub-optimal.

The InMemorySharedStateManager implementation of ISharedStateManager manages state in memory, essentially a collection of key-value pairs. It is provided as a sample, more robust implementations might include out-of-process storage.

The included implementation of IPromptFilter, DefaultPromptFilter, just returns the original prompt, makes no attempt to filter or change it. It is provided just as a sample.

All of these services are required for the orchestration to work, but different implementations can lead to very different results. It is interesting to notice that the Orchestrator class itself knows nothing about AI, LLMs, or Microsoft.Extensions.AI: this knowledge exists in some of these services.

Conclusion

We are just starting to get into the technical aspects of my orchestration framework, here I just covered one of the most important parts of it; I certainly did not cover all of the orchestrator, but I hope you can get a good picture of it. In the next post I will cover the agents, which are also very important, as they wrap the connection to an LLM provider and model.

I hope you find this interesting, feel free to ask or comment whatever you like!

Agents write most of my code these days. That leaves me with this question: what do I do with all this free time?

I considered learning a new framework, but that sounds suspiciously like work. Luckily, the VS Code team has a better idea. They gave me something to take care of.

What is the VS Code pet?

The pet is an interactive character that sits above the chat input box. It reacts to chat activity and to whatever you do to it.

So while the agent works, the pet watches. Before, I was the only one staring at the progress indicator while pretending to supervise. Now I have company.

Remark: The pet is marked as experimental, so it might change or be removed. Don't get too attached. (I got attached within five minutes.)

Adopting your pet

Type /vscode-pet in the chat input to show or hide it.

In the new-session view of the Agents window, you can also right-click outside the input box and select Pet (/vscode-pet).

Show or hide. That's the entire commitment. As far as I can tell, there is no feeding schedule, no vet, and no 3 AM walks. Compared to my Kubernetes cluster, it's remarkably low maintenance.

Spending quality time

My calendar is suddenly wide open, so let's see what we can do together:

• Select it to trigger a reaction. With the keyboard, press Tab to focus it, then Enter or Space. Yes, the pet is accessible. Your accessibility audit will be thrilled.
• Drag it around the chat and drop it wherever you like. It's like rearranging the furniture, except the furniture has opinions.
• Flick it to throw it. Don't worry, the pet comes back.
• Hop it with the Left and Right arrow keys while it has focus.
• Throw it at a wall by holding Shift with an arrow key.

That last one is officially documented. I'm not sure what it says about the creators, but I hope they are feeling well. 

Right-click the pet (or press Shift+F10 when it has focus) and you get a context menu where you can:

• view its achievements
• send it on the run
• resize it
• switch between Stable and Insiders colors

Achievements are the interesting part. For the first time, there is a way to measure how well I'm doing as a pet owner. Finally, a metric I can bring to my next performance review. "Delivered 14 microservices" doesn't land like "Unlocked all pet achievements."

One pet, many sessions

Only one pet appears at a time in the active chat surface. Its position and size are shared across chats and windows, and they persist after you restart VS Code.

So, the pet remembers where you left it. That's more than I can say for most of my agents, who forget everything the moment the context window fills up. 😁

Remark: VS Code supports running multiple agent sessions in parallel. Parallel pets are not supported. I think the priorities are clear.

So, what now?

Does this mean I should spend my newly found free time playing with a pet in my editor? Probably not.

But right now, my agent is refactoring a legacy module, my pet is hopping around, and I'm drinking coffee. One of us is being productive, and I have a strong suspicion it's not me.

That's it. Back to work. Or at least back to the pet.

More information

• Use chat in VS Code
• VS Code pet interactions and reactions

A couple of years ago I sat at a close friend's kitchen table together with his wife. He was gone. We spent hours trying to make sense of what he'd left behind online: domains, virtual private servers, source repositories, online accounts, subscriptions, decades of accumulated technologist debris. Most of it made no sense to her, and honestly, plenty of it didn't make much sense to me either. We were grieving, crying and laughing at the same time, while trying to put a lifetime of digital footprint into some kind of order.

That evening, plus a few other events around the same time, got me thinking. I live in what I jokingly call a mixed marriage, geek and normal, and I never want to leave my wife or my kids in that position. So this post is about the exercise I've been doing since: taking inventory of my digital life and deciding up front what should happen to it. I talked about that same exercise with Carl Franklin and Richard Campbell on .NET Rocks - Episode 2022, and the episode coming out today is what finally took this from draft to public.

Why this is practical rather than morbid

For the foreseeable future the earth will keep spinning whether I'm here or not. The only open question is what I hand over.

As a Swede, feelings and emotions can be hard to talk about, but we're very good at being practical. So make this a practical exercise rather than an emotional one. We even have a word for the analog version, döstädning, death cleaning, the habit of clearing out your things while you still can so nobody else has to guess later. This is the same thing applied to your digital life, and as with the original, most of the value is in the cleaning and not in the dying.

It's also not only about death. It's equally about a hospital stay, burnout, a bad accident, or three weeks somewhere without signal. And I'm not unique here. There are countless developers, IT pros, makers and open source maintainers with families who don't live at the same level of geekery.

A caveat before the how. This is my highly subjective personal point of view, arrived at through one evening that shook me and a couple of years of chewing on it afterwards. It isn't a standard, and it certainly isn't legal advice. Your assets, your family and your jurisdiction all differ from mine, so take what follows as inspiration rather than a checklist to copy, keep the parts that fit and work out what actually works for you. I'd expect plenty of people to land somewhere different, and that's entirely as it should be.

And a second, lighter warning, of the here be dragons variety. This is written by a geek, so there are tables ahead, along with bulleted lists and at least one directed graph. Sorting things into rows and boxes is how I process them, which is more or less the thesis of this whole post, so I won't apologize for it. ❤️

A digital bill of materials

What I ended up with is best described as a digital bill of materials for a life spent online. Not a legal document first, an inventory first, because you can't hand over what you've never listed.

Six questions to ask yourself:

1. What should die with me, and what should live on?
2. Who needs access to what?
3. Which domains are actually valuable?
4. What happens to the open source projects I maintain?
5. Have I identified successors where that makes sense?
6. Where are the credentials, and who can get to them when needed?

Five categories for every asset

Sorting each asset into one of five buckets is the part I've found genuinely useful, because it turns a vague sense of unease into a decision per item.

Personal legacy is the category people forget. Not everything deserves a handover, and pushing a project onto someone out of a vague sense of duty isn't a favor to anyone. Sometimes the right answer is a graceful archive and a README that says "this is done".

What to inventory

The list below is roughly the order in which things break when nobody's looking after them:

• Domains and DNS registrars, by far the most common point of silent failure.
• Virtual private servers, cloud subscriptions, hosting, storage.
• Source control accounts and organizations.
• Package registries, i.e. NuGet, npm, PyPI, Docker Hub, and marketplace extensions.
• Code signing certificates and keys.
• Two-factor authentication, i.e. authenticator apps, hardware keys, and recovery codes.
• Email, the root account that can reset almost everything else.
• Recurring payments and the card they're on. What breaks when that card expires?
• Community identities, i.e. blogs, YouTube, podcasts, and Discord or Slack ownership.
• The physical layer, i.e. the NAS, the home lab, the backups, and the drawer of drives. If you need somewhere to put the contents of that drawer, Blobify is what I use to archive local folders to Azure Blob Storage.

That order isn't arbitrary. Most of the list only stays reachable because something above it still works, and the shape of that is worth seeing before you decide who gets what.

Three things gate almost everything else, the mailbox, the vault and the second factor. And one thing gates the mailbox, which is why domains and registrars sit at the top of that list rather than the bottom.

Package registries deserve a special mention. When I wrote about a quarter of a billion NuGet downloads I called the number vanity, and it is, but the responsibility behind it isn't. Every one of those downloads is someone depending on a package that has exactly one owner listed somewhere.

There's also a security dimension that goes well beyond continuity. A package account that nobody is watching is a supply chain problem waiting to happen. If those credentials end up in the wrong hands, whoever holds them can push a new version straight into every build that already trusts the package, and it'll be restored and executed on developer machines and build agents without anyone reviewing a line of it. An unmaintained package is unfortunate, but an unmaintained package that somebody else can still publish to is a liability, and it's a liability you handed over by not deciding anything.

Who inherits your Git account

Most Git hosting providers have thought about this, and they've landed in surprisingly different places.

Note the difference between account inheritance and project continuity. A GitHub successor can rescue the public code but never becomes you, which I'd argue is the correct design. GitLab goes the other way and lets the successor assume the account itself, with commits and comments still showing your username. Both are defensible, they're just answers to different questions.

The better answer for most projects is an organization

Account succession is a baseball bat. It's blunt, it's all or nothing, and it only swings once, after you're gone or incapacitated. An organization is a scalpel, and it works while you're still very much alive.

• The moment a project has any success, move it out of your personal account and into an organization. Not because you're dying, but because one-person-shaped projects break in a dozen boring ways long before that.
• An organization supports multiple maintainers natively. No succession event required, no support ticket, no waiting period.
• Per-organization membership means you choose deliberately who's in what. Your weekend experiment and your serious library can have completely different rosters, whereas account succession is one blast radius for everything you own.
• Ownership becomes a role you can grant and revoke, not an identity someone has to inherit whole.
• It maps cleanly onto the five categories above. Open succession and emergency succession projects belong in organizations, while personal legacy projects can stay on your account precisely because you don't want them handed on.
• As a bonus the URL stops being github.com/yourname/thing. The project's identity detaches from yours, which is most of the migration problem solved years before anyone needs it.

One caveat: an organization still needs more than one owner. An organization whose single owner is you has exactly the same problem you started with, just with extra steps.

None of this is new advice, it's just the same advice with a different motivation. Back in 2017 I wrote about being a good open source citizen and put "get a team" near the end, because sooner or later life throws you a curveball and it's such a relief to have someone who can keep merging and answering when you're not able to. And when I joined the .NET Foundation Board of Directors I argued that nothing is sustainable if maintainers and community leaders burn out, and that you shouldn't set things in motion you've got no plan for how to maintain. A digital will is that plan, written down for the one case you can't fix yourself.

Emergency access in your password manager

An inventory is only half of it. Somebody has to be able to open the box.

The wait time is the elegant bit. The contact requests access, you get a window in which to decline, and if you never respond the request is granted. A dead man's switch, but a polite one. Bitwarden additionally lets you pick whether the contact gets read-only visibility or a full takeover, which is a distinction worth thinking about before you pick a person.

Proton Pass does the same thing one level up. Emergency Access, which Proton shipped in August 2025, is set on the account rather than the individual app, so a single invitation hands over the vault, the mailbox and the files together, and you can name up to five people. There's no read-only equivalent though, so whoever you pick gets the lot. Worth knowing as well that the wait time can be set to none, which turns the polite dead man's switch into an unlocked side door, so put a number of days on it even if it's a small one. It needs a paid plan, and your contact needs a Proton account of their own.

The kit based approach isn't worse, it just moves the problem into the physical world. If you use 1Password, the Emergency Kit only helps if it's actually been printed and stored somewhere the family can reach without needing the vault it unlocks.

Documents and photos in cloud storage

Your family will care about the photos long before they care about the source code. Cloud storage is where a couple of decades of documents and family life quietly accumulate, and the big three have landed in three different places yet again.

Microsoft's Digital legacy is the most deliberate of the three. You nominate one trusted contact, they accept, and you get a code that you can share however you like, including writing it into your will. They enter the code, wait 72 hours, and get read-only access to your files and photos. Worth knowing that it covers OneDrive and nothing else, so the Outlook mailbox on the same account still sits behind the legal route.

Google's Inactive Account Manager comes at it from the other end. The trigger isn't death, it's inactivity, anywhere from three to eighteen months, and you can name up to ten contacts and hand each of them a different slice of the data. It's also the only one here that will action "this should die with me" on your behalf, since you can have Google delete the account afterwards. Just remember that it fires on silence rather than on a death certificate, so a long hospital stay counts too. Dropbox has no pre-set option at all, which leaves your family opening a support ticket with a death certificate and a valid court order, and Dropbox is upfront that it can't guarantee the outcome.

Which brings up a timer nobody mentions. Providers delete inactive data, i.e. Microsoft freezes OneDrive after a year with the account expiring after two, and Dropbox removes the files on an account that's been inactive for twelve months. So the legal route is racing a deletion clock, which is the worst possible pairing of a slow process and a hard deadline. It's telling that both Microsoft and Dropbox give the same first piece of advice, go and look in the synced folder on the person's laptop before anything else. Which is as good an argument as any for keeping your own copy in that drawer of drives.

Email, the account that owns all the others

I put email in the inventory as the root account that can reset almost everything else, and it's worth coming back to, because it's the one entry on that list that isn't really about its own contents. Whoever can read the mailbox can request a password reset on very nearly everything else you own. So it's at once the thing your family needs most and the thing you'd least like to hand to the wrong person.

Apple's Legacy Contact is thorough, and it has the sharpest sting in the tail. You can name up to five people, each gets an access key, and with that plus a death certificate they get the mail along with notes, photos and device backups, and Activation Lock comes off the hardware so the devices aren't paperweights. What they don't get is the iCloud Keychain, which Apple excludes by design. That one is worth sitting with, because if Keychain is your password manager then the account that inherits everything hands over everything except the passwords, and every service behind them drops back to its own bereavement process.

Microsoft is the gap. The Digital legacy feature from the previous section covers pictures and files, and that is the whole of it, so an Outlook.com, Hotmail or Live mailbox has no pre-authorized route at all. There's nothing to switch on tonight, and the family's only option is a subpoena or court order served on Microsoft's registered agent, with no guarantee at the end of it. Google sits at the other extreme and hands over the mailbox as an MBOX file through Takeout, although the download link is only live for three months, so a grieving contact who isn't reading their inbox can miss the window completely.

Proton is the one I find most interesting, because it's the only provider here that couldn't fall back on a legal route even if it wanted to. Zero-access encryption means Proton holds a blob it can't read, so a court order produces precisely nothing, and for years the honest answer to what happens to your Proton mailbox was that it dies with you. Emergency Access is what changed that, and because it sits on the account rather than the app, the contact you named for the vault two sections ago already covers the mailbox and the files too. One decision instead of three, which is either tidy or too many eggs in one basket depending on the mood you read it in.

None of which matters if you run mail on a domain you own, and plenty of us do. The provider's legacy feature is beside the point then, because whoever controls the registrar controls the MX records, and whoever controls the MX records receives every password reset you've ever configured. That puts the registrar back at the root of the tree, which is exactly where I said the silent failures happen, and it's the reason a lapsed domain is so much worse than a lapsed website.

Microsoft 365 on your own domain is a different animal again, and worth separating from the Outlook.com row above. A tenant has no concept of a legacy contact because it doesn't need one. A Global Administrator can reset the password and walk straight in, convert the mailbox to a shared one so the family can read it without paying for a license, or put a retention hold on it and export the contents through Purview afterwards. Google Workspace works the same way, with a super admin in place of Inactive Account Manager. All of which is fine right until the sole Global Administrator is the person who died. Entra ID won't let you delete the last Global Administrator, which sounds protective but isn't, since it does nothing about that last one becoming unreachable. Microsoft's own answer is to keep two or more emergency access accounts, cloud only, permanently assigned the role, with the credentials written down somewhere sensible. That's break glass guidance written for enterprises, and it's the same caveat as the one about organizations needing more than one owner. It just bites harder here, because a locked tenant takes the mail, the domain and the identity down with it.

Legal authority is not technical access

Sweden has framtidsfullmakt, a future power of attorney that you sign while you're still competent and which activates if you no longer are, regulated by its own act since 2017. Most countries have an equivalent, usually called a durable or lasting power of attorney.

Here's the gap that took me a while to appreciate: legal authority does not grant technical access. A court can name your spouse as your representative, and the provider will still not hand over an account without credentials. The clearest local example is BankID, which is strictly personal and can't be issued to or used by an attorney, no matter what the paperwork says.

So the legal document and the credential handover are two separate deliverables, and you need both. One establishes who's allowed to act, the other makes it possible for them to actually do it.

Access can often be sorted out in the end, and most providers do have an appeal or next-of-kin process. The catch is that those processes take time, and time is exactly what a running digital life hasn't got. Weeks of back and forth with a support desk is weeks in which a domain doesn't get renewed, a card doesn't get updated, a certificate expires, and services go dark one by one while the paperwork is still in flight. Worst case a renewal window closes while you're waiting, and then you haven't just lost the service, you've lost the ownership, i.e. a lapsed domain that somebody else registers the moment it drops.

A technical executor, not just a legal one

An estate usually has a legal executor, someone whose job is to settle the practical and financial affairs. What it rarely has is a technical one. The legal executor can sign things, close accounts and pay bills, but they're unlikely to know what a DNS zone is, why an expiring certificate matters, or which of forty subscriptions is the one holding twenty years of family photos.

So name a technical person as well, and write down that you've done it. This doesn't have to be someone with access to everything. It's enough that it's someone your family can call, who'll understand the answer when they read your inventory out loud, and who can tell them which parts are urgent and which can wait. At that kitchen table I was that person, and I can tell you it's a considerably easier role to play when somebody has left you a list.

The good thing about this role is that it pairs. The person you ask is almost certainly in the same situation you are, with their own drawer of drives and their own registrar account nobody else can log into, so offer to be theirs in return. It costs an evening each, you both end up with an inventory that a second person has actually read, and reading somebody else's is by far the quickest way to spot the holes in your own.

Revisit it, because the answers change

Whatever you decide today has a shelf life, and it's shorter than you'd think. Not mainly because the assets change, although they do, but because the people do. A five year old has no opinion whatsoever on a Git repository, but at twenty they might care a great deal, and by then the honest answer to "who should this go to" could be a completely different name. It works the other way too. The friend you named as successor five years ago may have changed jobs, left the platform, or quietly stopped writing code altogether.

So treat this as a living document rather than a will you sign once and file away. Once a year, read it again, confirm the named people are still the right people and still know they were named, and move things between the five categories as the answers change. The categorizing is the part that keeps its value, not the paperwork.

Do this tonight

1. Write the inventory. A single plain document beats a perfect system you never get around to building.
2. Set up emergency access in your password manager. One contact and a seven day wait is a reasonable starting point.
3. Print the recovery kit and recovery codes. Paper survives things the cloud doesn't.
4. Name successors on GitHub and GitLab.
5. Move the critical domains off auto-renew against a card that's about to expire, and onto something the family can actually pay.
6. Write a plain-language README for a non-technical reader. Not "the reverse proxy terminates TLS", but "if the family photos stop working, call Anders".
7. Ask one technical friend to be the person your family can call, and offer to be theirs.
8. Pick one date a year to redo it, and tie it to something you already do so you don't have to remember it separately.

You don't have to do all of that tonight, and you probably shouldn't try. Treat it as iterative. Start with broad strokes, a flat list of the things that would hurt to lose with a category next to each one, and accept that the first pass will be incomplete and a bit wrong. Then zoom in over time, one area per sitting, filling in registrar names, renewal dates, successors and the details that only start to matter once the big decisions are made. A rough inventory that exists is good enough to be useful, a thorough one you're still planning isn't, and every pass makes the next one shorter.

Conclusion

The goal was never to preserve everything. It's to make the shutdown survivable for the people who are left holding it. Your family doesn't inherit your infrastructure, they inherit your decisions about it.

The side effect surprised me. Doing this made my digital life better while I'm still using it: fewer accounts, fewer subscriptions, fewer things to patch, and considerably less to defend. The best time to start was when you registered your first domain, and the second best time is this weekend.

This post has been sitting in my drafts since the night after that evening in the kitchen, when I got home and needed to pop my stack of every thought that had piled up over those hours, and to start processing the loss and the feelings that came with it. It took until now to go back, read it again, and finish it. Which is its own small argument for keeping the system simple, because procrastination is the default state.

Potrait of me drawn by my daughter at the time. It woke me up to the fact that how I felt on the inside was reflecting on the outside a good deal more than I'd understood.

References

• Maintaining ownership continuity of your personal account's repositories (GitHub)
• About successors (GitHub)
• GitHub Deceased User Policy
• Designate an account succession beneficiary (GitLab)
• Add and manage trusted emergency contacts (Bitwarden)
• Emergency Access (LastPass)
• Emergency Kit (1Password)
• Preserve your digital legacy with OneDrive (Microsoft)
• About Inactive Account Manager (Google)
• How to add a Legacy Contact for your Apple Account (Apple)
• Emergency Access (Proton)
• Manage emergency access admin accounts (Microsoft Entra ID)
• Create and manage inactive mailboxes (Microsoft Purview)
• Accessing Outlook.com, OneDrive and other services when someone has died (Microsoft)
• Access the account of someone who has passed away (Dropbox)
• Controlling your Digital Legacy (.NET Rocks 2022)
• Being a good open source citizen (2017)
• Joining the .NET Foundation Board of Directors (2021)
• Introducing Blobify (2024)
• A quarter of a billion NuGet downloads (2026)