diff --git a/dotnet/samples/AGUIDojo/Design.md b/dotnet/samples/AGUIDojo/Design.md
deleted file mode 100644
index fdc79e016f..0000000000
--- a/dotnet/samples/AGUIDojo/Design.md
+++ /dev/null
@@ -1,390 +0,0 @@
-# Design for Blazor Agent UI
-This document covers the design of the Microsoft.AspNetCore.Components.AI library for apps that interact with AI agents. Below we enumerate the general design patterns that we aim to provide in this area
-
-## Scenario 1 - Include an agent on the UI
-
-```html
-
-
-```
-
-AgentBoundary is responsible for "connecting the UI to the agent.
-
-It keeps track of the messages back and forth between the agent and the UI.
-
-It provides an AgentBoundaryContext cascading value that other children component can use to:
-* Listen for new messages
- * The context exposes an `IAsyncEnumerable` Messages stream of messages (including past messages and future messages, this is a "cold" enumerable)
- * The context exposes an `IAsyncEnumerable>` stream of updates per turn.
- * The outer IEnumerable represents all the turns between the user and the LLM.
- * The inner IEnumerable represents the updates for the current run.
- * This is a "hot" enumerable, meaning that you don't get past updates, only new ones.
- * The context exposes a T State property that represents any state associated with the agent.
- * The context exposes an IAsyncEnumerable stream that represents state updates if there is state attached to the Agent.
- * The context exposes a `SendAsync` method to trigger an interaction with the agent, which might include new messages as well as state.
- * The context exposes a CancellationToken tied to the lifetime of the AgentBoundary
-
-AgentBoundary doesn't have any UI, it's all about managing the interaction with the agent. This gives users the freedom to implement other parts of their agentic UI as they see fit.
-
-That said, we provide components to render a default input box as well as components to render the list of messages.
-
-Here is a more complete example:
-```html
-
-
-
-
-```
-
-The snippet above will render the default Chat like UI that we are all used to seeing and using.
-
-## Messages Component
-
-The messages component is responsible for the bulk of functionality in rendering messages from the agent. It's responsible for subscribing to the AgentBoundaryContext update stream and making sure that messages are rendered as they arrive. It holds the list of messages in memory and re-renders as new messages arrive.
-
-Our default Messages component supports customizing the way messages are rendered via templates. Users can define custom content templates to control how messages are rendered. These templates reflect the different content types that are available on Microsoft.Extensions.AI. There is a default template class for each content type and a general fallback template that can be used to provide a fallback for any unknown content.
-
-Some templates can have additional parameters. For example, the DataContentTemplate can specify a mime type to filter on and only render data messages that match that mime type. Similarly, the ToolCallContentTemplate can specify a tool name to filter on.
-
-The content templates provide a context object that includes two properties:
-* Message: That gives access to the completed message (if available)
-* Updates: That gives access to the list of updates being rendered for the current incoming message.
-
-The Messages component provides a default rendering template for TextContent. Any other content type will just not be rendered unless the developer provides a custom template for it.
-
-Here is a list of all the available content templates:
-
-* CodeInterpreterToolCallTemplate
-* CodeInterpreterToolResultTemplate
-* DataTemplate
-* ErrorTemplate
-* FunctionCallTemplate
-* FunctionResultTemplate
-* FunctionApprovalRequestTemplate
-* FunctionApprovalResponseTemplate
-* HostedFileTemplate
-* HostedVectorStoreTemplate
-* ImageGenerationToolCallTemplate
-* ImageGenerationToolResultTemplate
-* McpServerToolCallTemplate
-* McpServerToolResultTemplate
-* TextTemplate
-* TextReasoningTemplate
-* UriTemplate
-* UsageTemplate
-* UserInputRequestTemplate
-* UserInputResponseTemplate
-
-MessageModifiers can be used to modify the way messages are rendered. For example, a MessageModifier can be used to customize the "frame" around a message, so that ContentTemplates can focus on rendering the content itself. At the same time, MessageModifiers can be used to add additional UI elements around the message or provide overrides for specific AI contents.
-
-All ContentTemplates and MessageModifiers extend a base class ContentTemplateBase or MessageModifierBase respectively. They expose a "When" parameter that receives the message and returns a boolean indicating whether the template/modifier should be applied to that message/update.
-
-The MessageModifiers that exist by default are:
-* UserMessageModifier
-* SystemMessageModifier
-* AssistantMessageModifier
-* ToolMessageModifier
-
-Internally the Messages component follows this algorithm to render messages:
-1. For any given message: It first tries to match against an existing WellKnown MessageModifier (User, System, Assistant, Tool). If it matches a well known MessageModifier, it uses that one to render the message.
- - We do this to avoid having to iterate over all MessageModifiers for the most common cases.
- - Well known MessageModifiers take more precedence than custom message modifiers.
-2. If no well known MessageModifier matches, it iterates over all custom MessageModifiers in the order they were defined and uses the first one that matches.
-3. If no MessageModifier matches, it uses the DefaultMessageModifier to render the message.
-
-4. We merge the list of default content renderers with the content renderers in the modifier (if applicable) and then we proceed to find the right content template for each content in the message:
- - For any given content in the message, we first try to match against well known ContentTemplates in the merged set.
- - We do this to avoid having to iterate over all ContentTemplates for the most common cases.
- - Well known ContentTemplates take more precedence than custom content templates.
- - If no well known ContentTemplate matches, we iterate over all custom ContentTemplates in the merged set in the order they were defined and use the first one that matches.
- - If no matching ContentTemplate is found, we don't render any content.
- - If no content is rendered for a message, we skip rendering the message entirely.
-
-By default we render each message inside a `div` with CSS classes that reflect the role of the message (user, system, assistant, tool) as well as whether or not the message is complete. This can be customized by providing custom MessageModifiers. The modifier context provides access to a RenderContents method that can be used to render the contents of the message using the content templates.
-
-With this in mind, let's walk through some very common scenarios:
-
-### Customizing messages based on role
-
-```html
-
-
-
-
-