DEV Community: Aftab Bashir

BlazorMemory v0.8.0: Semantic Kernel adapter, Ollama embeddings, and memory decay

Aftab Bashir — Sun, 09 Aug 2026 09:57:37 +0000

Four things shipped in v0.8.0. I will go through each one.

Semantic Kernel integration

The most requested feature since I published the library. BlazorMemory now implements SK's IMemoryStore interface directly.

dotnet add package BlazorMemory.SemanticKernel

builder.Services
    .AddBlazorMemory()
    .UseInMemoryStorage()
    .UseOpenAiEmbeddings(apiKey)
    .UseOpenAiExtractor(apiKey)
    .UseSemanticKernelMemoryStore(userId: "alice");

That registers BlazorMemoryMemoryStore as SK's IMemoryStore in DI. You can now pass it to SK's SemanticTextMemory or any SK plugin that takes an IMemoryStore.

One design decision worth explaining: SK has no concept of userId, but BlazorMemory requires one for every store operation. The adapter takes a userId parameter (defaults to "sk") and uses it for all operations. If you are building a multi-user app, create one adapter per user or pass the userId at registration time.

SK collections map to BlazorMemory namespaces. So CreateCollectionAsync("work") creates a namespace called "work" and all records in that collection are scoped to it.

Ollama embeddings

dotnet add package BlazorMemory.Embeddings.Ollama

builder.Services
    .AddBlazorMemory()
    .UseOllamaEmbeddings()
    .UseOpenAiExtractor(apiKey);

No API key. No cost per request. Runs against a local Ollama instance at http://localhost:11434. Default model is nomic-embed-text which produces 768-dimensional embeddings.

You can configure it:

builder.UseOllamaEmbeddings(options =>
{
    options.Model = "mxbai-embed-large";
    options.BaseUrl = "http://my-server:11434";
    options.Dimensions = 1024;
});

The package has zero external dependencies. It uses System.Net.Http.Json directly. No Ollama SDK to pull in.

The obvious use case is development. Run Ollama locally, pull a model, and test your AI assistant without spending money on embeddings. Switch to OpenAI embeddings in production by changing one line.

Memory decay and summarization

This solves a real problem. A user who chats with your assistant every day for a month can accumulate hundreds of memories. Most of them are redundant or stale. The memory panel becomes noise.

SummarizeOldMemoriesAsync collapses old memories into a summary entry:

await memory.SummarizeOldMemoriesAsync(
    userId,
    maxMemories: 50,
    keepRecent: 20);

If the user has fewer than 50 memories, nothing happens. If they have more, the oldest ones (count minus 20) get passed to the LLM extractor for summarization, then deleted. A new memory is stored with the summary, prefixed with [Summary].

The summary prompt is: "Summarize these facts about a user into a single concise paragraph. Start with 'User background:'. Facts: ..."

You can call this on a schedule or after each conversation. It is a no-op when memory count is below the threshold so calling it frequently is safe.

Verbatim mode importance scoring

Thumbs up and down now work in verbatim mode too. Previously they only showed in Smart mode. The MemoryPanel component dispatches to the right service method based on the current mode automatically.

await memory.MarkVerbatimImportantAsync(memoryId);
await memory.MarkVerbatimUnimportantAsync(memoryId);
await memory.ResetVerbatimImportanceAsync(memoryId);

Same scoring logic as Smart mode. Important memories get a 1.5x multiplier on relevance. Unimportant ones drop to 0.3x.

Current state

11 packages on NuGet, 108 tests passing.

dotnet add package BlazorMemory
dotnet add package BlazorMemory.SemanticKernel
dotnet add package BlazorMemory.Embeddings.Ollama
dotnet add package BlazorMemory.Components

GitHub: https://github.com/aftabkh4n/BlazorMemory

Turning TravelAI.Core Into a Real Production System

Aftab Bashir — Sun, 02 Aug 2026 07:42:12 +0000

A few months ago I published TravelAI.Core, a .NET library for searching travel destinations using AI. Version 2.0.0 shipped with support for OpenAI, Anthropic, Azure OpenAI, and Ollama. It works. People are using it.

But it's still just a library. One package, doing one job, called directly from your code.

That's not how production systems work. So I'm upgrading it.

What TravelAI.Core looks like today

You install the package, call a method, and it searches destinations using whichever AI provider you configured. Simple, useful for small projects.

Plug it into a real product with real traffic and a few problems show up fast:

One process does everything. Search, AI calls, and business logic all run in the same place. If the AI provider is slow, your whole app waits. You can't scale just the search part without scaling everything else. And if something breaks, you're digging through console output trying to figure out which call caused it.

These aren't bugs. They're what happens when a library grows past its original scope.

Splitting it into services

I'm breaking TravelAI.Core into three pieces.

API Service - the front door. Takes requests, validates them, passes work along. It doesn't do the heavy lifting itself.

Search Service - handles destination search and filtering. Can scale independently if search traffic grows without touching the AI side.

AI Service - handles all calls to OpenAI, Anthropic, Azure, or Ollama. Isolated so a slow or unavailable provider doesn't freeze everything else.

Each service does one job.

Adding a message queue

Instead of the services calling each other directly, I'm putting RabbitMQ between them.

Here's why it matters. If the API service calls the AI service directly and the AI service is slow, the API service waits. With a queue, the API service sends a message and moves on. The AI service picks it up when it's ready. Nothing blocks.

It also means if the AI service crashes and restarts, no requests get lost. They sit in the queue until the service comes back up.

Centralized logging

I'm adding Serilog so every service writes to one place.

This sounds small. It isn't. When something breaks in a multi-service system, the hard part usually isn't fixing the bug. It's working out which service caused it. Scattered logs across three consoles turn a five-minute investigation into an hour of guessing.

Why bother

A single library shows you can write clean code. A multi-service system with a message queue and centralized logging shows you can design something that holds up under real conditions: slow networks, provider outages, traffic spikes.

And it costs nothing to build. Everything runs locally through Docker.

What's next

Split the codebase into three services
Add RabbitMQ between them
Wire up Serilog
Test under load locally
Write up the before and after with real numbers

TravelAI.Core started as a simple idea. It's turning into something more useful: a real example of how to structure a system that doesn't fall over.

More updates as this progresses.

GitHub: https://github.com/aftabkh4n/TravelAI.Core
NuGet: https://www.nuget.org/packages/TravelAI.Core

Reducing boilerplate in AI memory with a chat wrapper for .NET

Aftab Bashir — Thu, 30 Jul 2026 08:12:12 +0000

Every developer who uses BlazorMemory writes the same code after every chat message:

var reply = await CallLlmAsync(systemPrompt, userMessage);
await memory.ExtractAsync($"User: {userMessage}\nAssistant: {reply}", userId);

Query memories, build a prompt, call the LLM, extract new facts. Four steps, every time, in every app. v0.7.0 wraps all of that into one call.

MemoryEnabledChat

The new MemoryEnabledChat service takes a delegate for the LLM call and handles everything else:

// Register in Program.cs
builder.Services
    .AddBlazorMemory()
    .UseIndexedDbStorage()
    .UseOpenAiEmbeddings(apiKey)
    .UseOpenAiExtractor(apiKey)
    .UseMemoryEnabledChat();  // new

// Use it in your chat service
public class ChatService(MemoryEnabledChat chat)
{
    public Task<string> SendAsync(string message, string userId)
        => chat.ChatAsync(
            message,
            userId,
            (systemPrompt, msg) => CallOpenAiAsync(systemPrompt, msg));
}

The delegate receives a system prompt that already contains the relevant memories. You call your LLM with it and return the reply. MemoryEnabledChat handles the rest.

What it does internally

// 1. Query relevant memories
var memories = await _memory.QueryAsync(userMessage, userId, QueryOptions);

// 2. Build system prompt with memory context
var systemPrompt = BuildSystemPrompt(memories, BaseSystemPrompt);

// 3. Call your LLM via the delegate
var reply = await llmCall(systemPrompt, userMessage);

// 4. Extract new facts in background
// Errors are swallowed so extraction failures never crash the chat
_ = ExtractSafelyAsync(userMessage, reply, userId, namespace);

return reply;

Extraction errors are swallowed intentionally. A failed extraction is a degraded experience, not a crash. The user still gets their reply.

Customising behaviour

Two properties control how it works:

chat.QueryOptions = new QueryOptions { Limit = 8, Threshold = 0.60f };
chat.BaseSystemPrompt = "You are a helpful assistant for a software company.";

QueryOptions controls how many memories are retrieved and the similarity threshold. BaseSystemPrompt is prepended before the memory context block.

Single-service approach

If you do not want to inject MemoryEnabledChat separately, the same behaviour is available directly on IMemoryService:

var reply = await memory.ChatWithMemoryAsync(
    userMessage,
    userId,
    (systemPrompt, msg) => CallOpenAiAsync(systemPrompt, msg));

Same delegate pattern, same behaviour, fewer injections.

Before and after

Before v0.7.0 a typical chat service looked like this:

public async Task<string> SendAsync(string message, string userId)
{
    var memories = await _memory.QueryAsync(message, userId,
        new QueryOptions { Limit = 5, Threshold = 0.65f });

    var context = string.Join("\n", memories.Select(m => $"- {m.Content}"));
    var prompt = $"You are a helpful assistant.\n\nWhat you know:\n{context}";

    var reply = await CallOpenAiAsync(prompt, message);

    await _memory.ExtractAsync($"User: {message}\nAssistant: {reply}", userId);

    return reply;
}

After:

public Task<string> SendAsync(string message, string userId)
    => _chat.ChatAsync(message, userId,
        (prompt, msg) => CallOpenAiAsync(prompt, msg));

The logic is the same. The boilerplate is gone.

Getting v0.7.0

dotnet add package BlazorMemory
dotnet add package BlazorMemory.Components
dotnet add package BlazorMemory.Storage.IndexedDb
dotnet add package BlazorMemory.Embeddings.OpenAi
dotnet add package BlazorMemory.Extractor.OpenAi

84 tests passing across 9 packages.

GitHub: https://github.com/aftabkh4n/BlazorMemory

I made my .NET travel AI library work with OpenAI, Anthropic, Ollama, and Azure. Not just one.

Aftab Bashir — Mon, 27 Jul 2026 07:50:59 +0000

When I first shipped TravelAI.Core, it only worked with Azure OpenAI and Azure AI Search. You needed an Azure subscription, a deployed GPT-4o model, a configured AI Search index, and the patience to wire it all up before you could generate a single itinerary.

Downloads were slow. Not surprising in hindsight.

Most developers don't have Azure credentials sitting around. They want to try something before committing to a cloud provider. I was basically asking people to do significant setup work before they could see if the library was even useful to them.

So I rebuilt the provider layer.

What changed

The core interfaces stayed exactly the same. IItineraryGenerationService, IDestinationSearchService, IPriceAnomalyDetector all look identical from the outside. What changed is how you wire up the backend.

In v1.0.0 you needed a config section with Azure credentials. In v2.0.0 you pick a provider:

builder.Services.AddTravelAI(options => options.UseMock());
builder.Services.AddTravelAI(options => options.UseOpenAI("sk-..."));
builder.Services.AddTravelAI(options => options.UseAnthropic("sk-ant-..."));
builder.Services.AddTravelAI(options => options.UseOllama("http://localhost:11434"));
builder.Services.AddTravelAI(options => options.UseAzureOpenAI("endpoint", "key", "gpt-4o"));

The mock provider is the one I'm most pleased with. Zero credentials, works offline, returns a realistic 3-day Rome itinerary with activities, costs, and timing. You can build and test the full integration flow on a train with no internet.

How the abstraction works

There's a single ILlmProvider interface:

public interface ILlmProvider
{
    Task<string> GenerateAsync(
        string systemPrompt,
        string userPrompt,
        CancellationToken ct = default);
}

Each provider implements it. ItineraryGenerationService now takes ILlmProvider instead of AzureOpenAIClient. The Anthropic adapter uses Anthropic.SDK, the Ollama adapter makes raw HTTP calls to /api/chat, the mock just returns a hardcoded JSON string.

The destination search side has a mock too. MockDestinationSearchService does keyword scoring in memory against five curated destinations. Good enough to build against while you decide whether you want Azure AI Search or something else.

The Ollama adapter

Ollama's API is simple but you're dealing with streaming responses and the JSON format varies slightly across model versions. I went with a non-streaming request to keep the adapter stateless, which works fine for itinerary generation.

var response = await _http.PostAsJsonAsync("/api/chat", new
{
    model = _model,
    stream = false,
    messages = new[]
    {
        new { role = "system", content = systemPrompt },
        new { role = "user", content = userPrompt }
    }
});

Nothing clever. Just works.

What the library does

Four things once registered:

Itinerary generation takes a traveller profile and destination and returns a structured day-by-day plan with activities and cost estimates. Price anomaly detection analyses flight options against historical baselines and flags anything unusual. Destination search understands natural language queries like "warm with beaches and local food, not too touristy". Booking automation runs the end-to-end flow with retry logic and rollback on failure.

The whole thing is deployed to Azure Kubernetes Service. The GitHub Actions pipeline builds for linux/arm64, pushes to GHCR, and deploys with a manual approval gate. Took me a while to figure out the arm64 part.

Getting started

dotnet add package TravelAI.Core

Start with UseMock(). If it does what you need, switch to a real provider. The rest of your code doesn't change.

GitHub: https://github.com/aftabkh4n/TravelAI.Core

I added pgvector support to my .NET AI memory library

Aftab Bashir — Mon, 27 Jul 2026 06:37:50 +0000

BlazorMemory has had EF Core storage from the start. It works. But there is a problem with how it handles search.

The current EfCoreMemoryStore loads every memory for a user into C#, then runs cosine similarity in a loop. For a user with 50 memories that is fine. For a user with 5,000 it is a full table scan on every query.

v0.6.0 ships a new package that fixes this properly.

BlazorMemory.Storage.Pgvector

The pgvector adapter moves vector search into PostgreSQL. Instead of loading everything and computing in C#, it runs a single SQL query using the <=> cosine distance operator.

SELECT * FROM "Memories"
WHERE "UserId" = @userId
ORDER BY "Embedding" <=> @queryVector
LIMIT 5;

PostgreSQL handles the math. The .NET code just maps the results.

Setup

dotnet add package BlazorMemory.Storage.Pgvector

You need PostgreSQL with the pgvector extension. If you are on a fresh database:

CREATE EXTENSION IF NOT EXISTS vector;

Then wire it up:

builder.Services
    .AddBlazorMemory()
    .UsePgvectorStorage<AppDbContext>()
    .UseOpenAiEmbeddings(apiKey)
    .UseOpenAiExtractor(apiKey);

Your AppDbContext needs to extend PgvectorMemoryDbContext or apply the configuration manually:

public class AppDbContext : PgvectorMemoryDbContext
{
    public AppDbContext(DbContextOptions<PgvectorMemoryDbContext> options)
        : base(options, dimensions: 1536) { }
}

The dimensions parameter must match your embedding model. OpenAI text-embedding-3-small uses 1536. Adjust for other providers.

The HNSW index

The package creates an HNSW index on the embedding column automatically via EF migrations:

entity.HasIndex(e => e.Embedding)
      .HasMethod("hnsw")
      .HasOperators("vector_cosine_ops")
      .HasDatabaseName("IX_Memories_Embedding_Hnsw");

HNSW is approximate nearest neighbour search. It trades a small amount of recall for much faster query times at scale. For memory retrieval this is the right tradeoff. You do not need perfect recall, you need fast and good enough.

When to use which adapter

Use BlazorMemory.Storage.EfCore when:

You are building a server-side Blazor or ASP.NET Core app
You have a small number of memories per user (under a few hundred)
You want the simplest possible setup with SQLite or SQL Server

Use BlazorMemory.Storage.Pgvector when:

You are on PostgreSQL already
You expect large memory stores per user
You want search to scale without loading data into memory

Use BlazorMemory.Storage.IndexedDb when:

You are building Blazor WASM
You want zero backend
Everything stays in the browser

Current state

9 packages on NuGet, 70 tests passing.

GitHub: https://github.com/aftabkh4n/BlazorMemory

Letting users teach an AI which memories matter

Aftab Bashir — Tue, 16 Jun 2026 18:16:25 +0000

I built BlazorMemory to give Blazor AI assistants persistent memory. The library uses an LLM to extract facts from conversations, embeds them as vectors, and retrieves the relevant ones for each new query.
The system worked but it had a quiet failure mode. The LLM decided what was important. The user had no say. So when someone marked their birthday as a memory and the assistant kept surfacing "user enjoys coffee" instead, there was no way to fix it.
v0.5.0 fixes this.
How it works
Each memory now has an

ImportanceScore

field. Default is 1.0. Users can mark a memory as important (1.5) or unimportant (0.3) via thumbs up and thumbs down buttons in the panel.
During search, the score acts as a multiplier on cosine similarity:

// In QueryAsync
results = results
    .Select(m => m.WithRelevanceScore((m.RelevanceScore ?? 0f) * m.ImportanceScore))
    .OrderByDescending(m => m.RelevanceScore)
    .ToList();

That is the entire algorithm. A memory marked important with a 0.7 similarity gets boosted to 1.05 and beats a neutral memory at 0.9. A memory marked unimportant with a 0.9 similarity drops to 0.27 and falls off the list.

API

// Boost in future searches
await memory.MarkImportantAsync(memoryId);

// Down-rank but do not delete
await memory.MarkUnimportantAsync(memoryId);

// Back to neutral
await memory.ResetImportanceAsync(memoryId);

// Custom score
await memory.SetImportanceAsync(memoryId, 1.8f);

In the UI
If you use the component, the thumbs buttons appear on every memory card automatically:

<MemoryPanel UserId="@userId" IsOpen="true" />

You can hide them with AllowFeedback="false" if you do not want users to override the LLM.
Important memories get a green left border. Unimportant ones get dimmed and a red left border. Easy to scan at a glance.
Why down-rank instead of delete
The thumbs down button could have just deleted the memory. I decided against it for two reasons.
First, users click the wrong button. A delete that can not be undone is hostile UX.
Second, sometimes you want to suppress a memory without erasing it. Maybe the assistant keeps bringing up an old job title and you want to push it down without losing the context completely. Down-ranking with a score of 0.3 makes the memory available but unlikely to surface.
If users actually want to delete, the ✕ button right next to the thumbs is one click away.

Getting v0.5.0

dotnet add package BlazorMemory
dotnet add package BlazorMemory.Components
dotnet add package BlazorMemory.Storage.IndexedDb
dotnet add package BlazorMemory.Embeddings.OpenAi
dotnet add package BlazorMemory.Extractor.OpenAi

All 8 packages on NuGet. Tests passing.
GitHub: https://github.com/aftabkh4n/BlazorMemory

I kept improving my .NET order pipeline after a CTO left feedback. Here is where it ended up.

Aftab Bashir — Sun, 24 May 2026 07:35:12 +0000

A few weeks ago I published an article about an event-driven order pipeline I built in .NET. A CTO named Andrew Tan left a comment pointing out that my outbox pattern had a gap - the polling interval was trading latency for database load, and I had no protection against multiple poller instances stepping on each other.

I fixed the outbox gap in a follow-up post. But Andrew also flagged two more things worth addressing. This is where the pipeline stands now after working through all of them.

Where we started

The original pipeline had a working outbox pattern. Orders and outbox records written in the same PostgreSQL transaction. A background service polling every 5 seconds and publishing to Kafka. Messages marked as processed after a successful publish.

It worked. But it had three gaps Andrew spotted:

No protection for horizontal scaling - two poller instances would grab the same message
No backoff when Kafka was down - just constant retrying every 5 seconds
No dead letter path - messages that failed repeatedly just sat there forever

Fix 1 - FOR UPDATE SKIP LOCKED

The original query just fetched unprocessed messages. If you ran two instances of the service, both would grab the same messages and try to publish them twice.

The fix is a raw SQL query with FOR UPDATE SKIP LOCKED:

SELECT * FROM "OutboxMessages"
WHERE "Processed" = false AND "RetryCount" < 3
ORDER BY "CreatedAt"
FOR UPDATE SKIP LOCKED

FOR UPDATE locks the rows for the duration of the transaction. SKIP LOCKED means any other poller instance skips rows that are already locked rather than waiting. Two instances running in parallel will never claim the same message. Scale horizontally as much as you want.

The transaction stays open across the entire fetch, process, and save cycle. Only when the message is marked as processed and the transaction commits do the locks release.

Fix 2 - Exponential backoff for Kafka failures

The original service retried every 5 seconds regardless of what was happening. If Kafka was down, it would hammer the broker with connection attempts at a fixed rate.

The updated service tracks whether any publish failed and adjusts the wait interval accordingly:

if (anyKafkaFailure)
{
    _logger.LogWarning("Kafka publish failed. Backing off for {Seconds}s", _currentBackoff);
    await Task.Delay(TimeSpan.FromSeconds(_currentBackoff), stoppingToken);
    _currentBackoff = Math.Min(_currentBackoff * 2, MaxBackoffSeconds);
}
else
{
    _currentBackoff = BaseBackoffSeconds;
    await Task.Delay(TimeSpan.FromSeconds(BaseBackoffSeconds), stoppingToken);
}

First failure waits 5 seconds, then 10, then 20, then caps at 60. Any successful publish resets to 5 seconds. The service backs off gracefully when Kafka is struggling instead of making things worse.

Bad payloads that fail to deserialize increment the retry count but do not trigger backoff - only Kafka connection failures do. That distinction matters because you do not want a single corrupt message to slow down processing of everything else.

Fix 3 - Dead letter path

The original implementation stopped retrying after 3 attempts and left the message sitting in the outbox with RetryCount = 3. It was effectively dead but invisible.

Now when a message hits the retry limit, it moves to a DeadLetterMessages table:

if (message.RetryCount >= MaxRetries)
{
    var deadLetter = new DeadLetterMessage
    {
        OrderId = message.OrderId,
        EventType = message.EventType,
        Payload = message.Payload,
        OriginalCreatedAt = message.CreatedAt,
        DeadLetteredAt = DateTime.UtcNow,
        FailureReason = message.Error ?? "Max retries exceeded",
        RetryCount = message.RetryCount
    };

    context.DeadLetterMessages.Add(deadLetter);
    context.OutboxMessages.Remove(message);

    _logger.LogWarning(
        "Message {MessageId} for order {OrderId} moved to dead letter after {RetryCount} retries",
        message.Id, message.OrderId, message.RetryCount);
}

The outbox stays clean. Dead messages go somewhere visible. There is also a GET /api/deadletters endpoint so operators can inspect what failed and why without touching the database directly.

What the full picture looks like now

The outbox processor now handles four scenarios cleanly:

Happy path - message fetched, published to Kafka, marked as processed. Next poll in 5 seconds.

Kafka is down - publish fails, retry count increments, backoff doubles. Service waits progressively longer and tries again when Kafka recovers.

Multiple instances - FOR UPDATE SKIP LOCKED ensures each message is claimed by exactly one instance. No duplicate publishes.

Persistent failure - after 3 retries, message moves to dead letters. Outbox stays clean. Operator can inspect and replay manually.

The honest reflection

None of these improvements would have happened without Andrew's comment. The original implementation worked in testing. All three gaps only show up under specific production conditions - horizontal scaling, broker failures, persistent bad messages.

This is why public code review matters. A fresh pair of eyes from someone who has hit these problems before is worth more than any amount of solo review.

Source code: github.com/aftabkh4n/order-pipeline

If you are building event-driven systems this is worth reading alongside the original article. The outbox pattern is the foundation. These three additions are what make it production-ready.

I added verbatim memory to my .NET AI library : here's why it outperforms extraction

Aftab Bashir — Mon, 18 May 2026 06:25:58 +0000

There is a paper called MemPalace that stores conversations verbatim instead of extracting facts from them. It scores 96.6% on LongMemEval. Most extraction-based approaches sit around 70-80%.

That got my attention.

BlazorMemory has always used AI extraction. You send a conversation, an LLM pulls out discrete facts ("User is a software engineer"), and those facts get stored as vector embeddings. It works well. But it is lossy by design. The LLM decides what matters, and sometimes it gets that wrong.

Verbatim mode skips the extraction step. The raw conversation chunk goes straight into storage with an embedding. Nothing is thrown away.

How it works

Smart mode (the original approach):

Conversation -> LLM extraction -> facts -> embeddings -> storage

Verbatim mode (new):

Conversation -> embedding -> storage

That is it. No extraction, no consolidation, no decisions about what to keep.

When you query, both modes use cosine similarity. The difference is what you are searching over. Smart mode searches extracted facts. Verbatim mode searches raw conversation chunks.

Using it

// Store a conversation chunk verbatim
await memory.StoreVerbatimAsync(userId, "User: I just got promoted to senior engineer. Assistant: Congratulations!");

// Search verbatim memories
var results = await memory.SearchVerbatimAsync(userId, "what is my job level", topK: 5);

The MemoryPanel component now has a toggle between Semantic and Verbatim mode. One line of markup, no extra wiring:

<MemoryPanel UserId="@userId" IsOpen="true" />

When to use which

Smart mode is better when you want clean, structured facts. After a long conversation the panel might show four memories instead of forty. It also uses less storage since embeddings are only stored for the extracted facts, not every message.

Verbatim mode is better when you cannot afford to lose context. Support tools, research assistants, anything where exact phrasing matters. You keep everything, and retrieval decides what is relevant at query time.

You can also run both at the same time. Store verbatim for retrieval accuracy, extract facts for the summary panel.

Getting started

dotnet add package BlazorMemory
dotnet add package BlazorMemory.Storage.IndexedDb
dotnet add package BlazorMemory.Embeddings.OpenAi
dotnet add package BlazorMemory.Extractor.OpenAi
dotnet add package BlazorMemory.Components

builder.Services
    .AddBlazorMemory()
    .UseIndexedDbStorage()
    .UseOpenAiEmbeddings(apiKey)
    .UseOpenAiExtractor(apiKey);

v0.4.0 is on NuGet now. 49/49 tests passing.

GitHub: https://github.com/aftabkh4n/BlazorMemory

I made my .NET travel AI library work with OpenAI, Anthropic, Ollama, and Azure. Not just one.

Aftab Bashir — Tue, 12 May 2026 06:47:37 +0000

Downloads were slow. Not surprising in hindsight.

So I rebuilt the provider layer.

What changed

In v1.0.0 you needed a config section with Azure credentials. In v2.0.0 you pick a provider:

builder.Services.AddTravelAI(options => options.UseMock());
builder.Services.AddTravelAI(options => options.UseOpenAI("sk-..."));
builder.Services.AddTravelAI(options => options.UseAnthropic("sk-ant-..."));
builder.Services.AddTravelAI(options => options.UseOllama("http://localhost:11434"));
builder.Services.AddTravelAI(options => options.UseAzureOpenAI("endpoint", "key", "gpt-4o"));

How the abstraction works

There's a single ILlmProvider interface:

public interface ILlmProvider
{
    Task<string> GenerateAsync(
        string systemPrompt,
        string userPrompt,
        CancellationToken ct = default);
}

The Ollama adapter

var response = await _http.PostAsJsonAsync("/api/chat", new
{
    model = _model,
    stream = false,
    messages = new[]
    {
        new { role = "system", content = systemPrompt },
        new { role = "user", content = userPrompt }
    }
});

Nothing clever. Just works.

What the library does

Four things once registered:

Getting started

dotnet add package TravelAI.Core

Start with UseMock(). If it does what you need, switch to a real provider. The rest of your code doesn't change.

GitHub: https://github.com/aftabkh4n/TravelAI.Core

A senior engineer spotted a bug in my pipeline. I fixed it the same day. Here is what I learned.

Aftab Bashir — Sun, 10 May 2026 05:37:10 +0000

A few weeks ago I published an article about an event-driven order pipeline I built in .NET with Kafka and Azure Service Bus. Someone left a comment that stopped me in my tracks.

Andrew Tan wrote:

"One thing I'd watch: you now have two sources of truth in flight, PostgreSQL and Kafka. If the API crashes after writing to Postgres but before publishing, you've got an order that never gets processed. Have you considered using an outbox pattern or transactional writes to close that gap?"

He was right. I had not thought about it properly.

The gap he spotted

Here is what the original code did when a new order came in:

Save the order to PostgreSQL
Publish an event to Kafka

Two separate operations. No transaction between them. If the API crashed, ran out of memory, got killed by Kubernetes, or just had a bad moment between step 1 and step 2, the order would exist in the database with a Pending status and never move forward.

Nobody would know. No error. No alert. The order would just sit there.

At low volume this probably never causes a visible problem. At scale, or in production with real money on the line, it is a serious reliability issue.

The outbox pattern

The fix is called the outbox pattern. The idea is simple.

Instead of writing to the database and then publishing to Kafka as two separate operations, you write the order and an outbox record in the same database transaction. The outbox record is just a row in a table that says "this event needs to be published."

A separate background service then reads unprocessed outbox records, publishes them to Kafka, and marks them as processed. If publishing fails, the record stays unprocessed and gets retried. If the background service crashes mid-publish, it picks up the same record on restart.

The database transaction is the source of truth. Either both the order and the outbox record are committed together, or neither is. There is no window where one exists without the other.

What I built

First I added an OutboxMessage model:

public class OutboxMessage
{
    public Guid Id { get; set; } = Guid.NewGuid();
    public Guid OrderId { get; set; }
    public string EventType { get; set; } = string.Empty;
    public string Payload { get; set; } = string.Empty;
    public DateTime CreatedAt { get; set; } = DateTime.UtcNow;
    public DateTime? ProcessedAt { get; set; }
    public bool Processed { get; set; } = false;
    public int RetryCount { get; set; } = 0;
    public string? Error { get; set; }
}

Then I updated the controller to write both in the same transaction:

public async Task<IActionResult> CreateOrder([FromBody] CreateOrderRequest request)
{
    var order = new Order { ... };

    var outboxMessage = new OutboxMessage
    {
        OrderId = order.Id,
        EventType = nameof(OrderEventType.OrderCreated),
        Payload = JsonSerializer.Serialize(order)
    };

    db.Orders.Add(order);
    db.OutboxMessages.Add(outboxMessage);
    await db.SaveChangesAsync(); // one transaction, both or neither

    return CreatedAtAction(nameof(GetOrder), new { id = order.Id }, order);
}

No Kafka publish in the controller anymore. The controller just writes to the database and returns.

Then I built the OutboxProcessorService as a BackgroundService that polls every 5 seconds:

protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
    while (!stoppingToken.IsCancellationRequested)
    {
        await ProcessOutboxMessagesAsync();
        await Task.Delay(TimeSpan.FromSeconds(5), stoppingToken);
    }
}

private async Task ProcessOutboxMessagesAsync()
{
    var messages = await db.OutboxMessages
        .Where(m => !m.Processed && m.RetryCount < 3)
        .OrderBy(m => m.CreatedAt)
        .ToListAsync();

    foreach (var message in messages)
    {
        try
        {
            await PublishToKafkaAsync(message);
            message.Processed = true;
            message.ProcessedAt = DateTime.UtcNow;
        }
        catch (Exception ex)
        {
            message.RetryCount++;
            message.Error = ex.Message;
        }

        await db.SaveChangesAsync();
    }
}

What the logs look like now

When an order comes in:

INSERT INTO "Orders" ...
INSERT INTO "OutboxMessages" ...
Order f21613da created and outbox message queued

Five seconds later:

Processing 1 unprocessed outbox messages
Order f21613da published to Kafka topic orders at offset 5
Outbox message published successfully
UPDATE "OutboxMessages" SET "Processed" = true ...

The gap is closed. The order and the outbox record live or die together in the same transaction. Kafka gets the event eventually, guaranteed.

What Andrew also flagged

After I posted the fix, Andrew came back with more good points. He mentioned that with a 5-second polling interval, you are trading latency for database load. Fine at low volume. At scale you want FOR UPDATE SKIP LOCKED so multiple poller instances do not step on each other.

He also asked what happens if Kafka is down. Currently unprocessed records pile up and the poller keeps retrying every 5 seconds with no backoff. That is worth fixing. A dead letter path and an alert on outbox message age would make this production-ready.

Both are on the backlog. The current implementation is correct for a single poller. Horizontal scaling and dead letters are the next iteration.

The bigger point

I almost shipped this without the outbox pattern. The original code worked perfectly in testing. Kafka and PostgreSQL both got their data. No errors. No warnings.

The failure mode only shows up when something crashes between two operations that look like one. That is exactly the kind of bug that stays invisible until it costs someone something real.

Public code review from people who know what they are looking at is genuinely valuable. Andrew's comment was worth more than any linter or test suite would have caught here.

Source code: github.com/aftabkh4n/order-pipeline

If you are building event-driven systems and not using the outbox pattern, it is worth understanding. The implementation is not complicated. The reliability guarantee it gives you is significant.

We've been building AI-style modular systems for years, we just called them plugins

Aftab Bashir — Tue, 05 May 2026 06:58:28 +0000

There’s a lot of excitement right now around AI agents, tools, and modular systems.

Define tools.

Describe them well.

Let something else decide when to use them.

Sound familiar?

It should.

Because we’ve been doing this for years | we just called them plugins.

The core idea

A well-designed system doesn’t hardcode features.

Instead, it does one thing at startup:

Load modules (plugins)

That’s it.

No giant Program.cs doing everything.

No tightly coupled feature logic.

Just a host application that loads capabilities dynamically.

Everything is a plugin

In this model:

Pages → plugins
UI components → plugins
Business logic → plugins
Side effects (logging, API calls, events) → plugins

Even things you don’t normally think about, like routing, become plugins.

Why this matters

When every feature is a plugin:

Adding a feature → drop in a file
Removing a feature → delete a file
Replacing a feature → swap a file

No refactoring. No ripple effects.

This is true modularity.

A simple mental model

Think of your app like this:

App = Host + Plugins

The host:

Loads plugins
Provides shared context
Coordinates execution

Plugins:

Declare what they do
Register themselves
Execute when needed

Mini example using TOPS (stream-oriented)

Let’s make it concrete.

Using a stream-oriented approach like TOPS, everything becomes part of a flow.

Entry point

var app = new App();

app.LoadPlugins("plugins/");

app.Run();

That’s it.

Router plugin

public class RouterPlugin : IPlugin
{
    public void Register(IApp app)
    {
        app.UseRouter(routes =>
        {
            routes.Map("/", "HomePage");
            routes.Map("/about", "AboutPage");
        });
    }
}

Home page plugin

public class HomePagePlugin : IPlugin
{
    public void Register(IApp app)
    {
        app.RegisterPage("HomePage", ctx =>
        {
            return "<h1>Home</h1>";
        });
    }
}

Navbar plugin

public class NavbarPlugin : IPlugin
{
    public void Register(IApp app)
    {
        app.RegisterComponent("Navbar", ctx =>
        {
            return "<nav>...</nav>";
        });
    }
}

Now here’s the interesting part:

👉 Remove HomePagePlugin.cs → home page disappears

👉 Remove NavbarPlugin.cs → navbar is gone

👉 Remove RouterPlugin.cs → no routing

No changes anywhere else.

Effects are plugins too

In real systems, it gets more powerful.

Things like:

Logging
API calls
Background jobs
Event handling

…can all be plugins.

Example:

public class LoggingPlugin : IPlugin
{
    public void Register(IApp app)
    {
        app.OnEvent("RequestStarted", ctx =>
        {
            Console.WriteLine("Request started");
        });
    }
}

This is basically how AI tools work

Modern AI systems:

Define tools (plugins)
Describe them
Let the model choose which one to call

That’s not new.

That’s just:

Plugin architecture + dynamic orchestration

The difference is:

Instead of a developer calling the plugin
An AI decides which plugin to use

The real takeaway

The important shift isn’t AI.

It’s this:

Capabilities should be decoupled from the core system

Whether it’s:

a web app
a backend service
or an AI agent

The winning pattern is the same:

Small, focused modules
Clear contracts
Easy to add/remove

If you're not doing this yet

Start simple:

Extract one feature into a module
Give it a clear interface
Load it dynamically

You’ll quickly see the benefits:

cleaner code
easier testing
faster iteration

Final thought

AI didn’t invent modular systems.

It just made us realize how powerful they are when something else | not you | decides how to use them.

And if your system is already plugin-based?

You’re already ahead.

How I added memory export and import to my open-source AI library

Aftab Bashir — Tue, 05 May 2026 04:30:52 +0000

When I built BlazorMemory, I knew from the start that storing memories in the browser had one obvious problem. What happens when you clear your browser data? Or switch devices? Everything is gone.

v0.3.0 fixes that with two new methods: ExportAsync and ImportAsync.

What it does

Export serialises all memories for a user to JSON:

var json = await memory.ExportAsync(userId);

The output looks like this:

{
  "userId": "demo_user",
  "exportedAt": "2025-03-15T10:00:00Z",
  "version": "1.0",
  "memories": [
    {
      "id": "abc123",
      "content": "User is a senior .NET engineer",
      "learnedAt": "2025-03-14T09:30:00Z"
    }
  ]
}

Notice embeddings are not in the export. They are large (1,536 floats per memory) and they are model-specific. If you exported with text-embedding-3-small and later imported using a different model, the similarity search would break. So the export skips them, and import re-generates them fresh.

Import reads the JSON, skips any memory whose content already exists (to avoid duplicates), and stores the rest:

await memory.ImportAsync(userId, json);

It is built into the MemoryPanel component

If you use BlazorMemory.Components, you get Export and Import buttons in the panel footer with no extra code:

<MemoryPanel UserId="@userId" IsOpen="true" />

Export triggers a browser file download. Import opens a file picker that accepts .json files.

Both buttons are opt-in via parameters if you want to hide them:

<MemoryPanel UserId="@userId"
             AllowExport="false"
             AllowImport="false" />

Why not include the embeddings

I thought about this. Including embeddings would make the import faster since you skip the re-embedding API call. But it creates two problems.

First, file size. A user with 50 memories using text-embedding-3-small would have a 300KB export file. Not terrible, but not great either.

Second, model coupling. If you export from an app using OpenAI embeddings and import into an app using a different provider, the vectors are incompatible and similarity search silently breaks. Re-generating on import keeps things clean regardless of which embedding provider the target app uses.

Getting started

dotnet add package BlazorMemory
dotnet add package BlazorMemory.Storage.IndexedDb
dotnet add package BlazorMemory.Embeddings.OpenAi
dotnet add package BlazorMemory.Extractor.OpenAi
dotnet add package BlazorMemory.Components

builder.Services
    .AddBlazorMemory()
    .UseIndexedDbStorage()
    .UseOpenAiEmbeddings(apiKey)
    .UseOpenAiExtractor(apiKey);

<MemoryPanel UserId="@userId" IsOpen="true" />

That is all you need. The panel handles display, delete, clear, export, and import.

GitHub: https://github.com/aftabkh4n/BlazorMemory