Assuming you haven’t been living under a rock, you’ve probably noticed that topics related to Artificial Intelligence (AI) are pretty well dominating most conversations about software development right now.

I’d like to lay out the Critter Stack community and JasperFx‘s strategy is for AI assisted software development at this moment and talk about all the different spaghetti we’re trying to throw up against the wall so that the Critter Stack and JasperFx can continue to thrive in our new world order.

Vertical Slice Architecture

Switching to the Critter Stack’s impact on application code, Wolverine has been built with what we now call “Vertical Slice Architecture” (VSA) in mind from the very beginning. That emphasis on VSA code organization has turned out to have been accidentally prescient as Wolverine’s very terse approach to VSA is already very optimized for AI agentic development — especially when contrasted with more traditional server side .NET code organization that leans into layered architectures that force AI agents to burn more tokens traversing the code.

Here’s a tutorial on Vertical Slice Architecture with Wolverine.

The takeaway here is that the intended idiomatic usage of Wolverine in our recommendations is already well suited for AI assisted development. The available command line tools that we bake right into your application using the Critter Stack tools can help a lot too. However, there is the very real issue of helping users utilize the AI-friendly, terse, VSA style of code when folks are coming from Clean Architecture approaches or other styles that call for more projects, layers, and abstractions that we the Critter Stack community or your AI agent ideally wants to deal with. Likewise, the usage of all those small diagnostic tools aren’t terribly obvious for troubleshooting if you don’t know they’re there or aren’t a Linux guru who’s used to banging out obscure command line calls from memory.

Wolverine and the rest of the Critter Stack is very highly optimized for simple and terse code using the Vertical Slice Architecture approach, and that’s great for AI assisted development!

And it’s incumbent upon people like me to prove that out over time of course.

Event Sourcing is Great for AI!

Or at least that’s something that all of the folks like me that are heavily invested in Event Sourcing tooling are telling you!

Now that CritterWatch 1.0 is live, JasperFx Software has a commercial offering that gives you comprehensive MCP or command line integration with all the common APIs and capabilities of our Marten/Polecat/Fisher event stores.

Command Line Tooling

We’ve long invested in command line diagnostics up and down through the whole Critter Stack just because it’s a mechanically cheap way to do that, but now the AI agent usage has made those tools more valuable than ever.

Our “classic” dotnet run describe is the human friendly tool we’ve long used to dump system descriptions out for our human users and one of the first things I ask users to try to unwind many common issues with Marten or Wolverine usage, and that’s not going anywhere. We’ve also invested quite a bit recently in additional CLI tools in Wolverine 9.0 especially that have textual output optimized for AI agents to explain message routing, preview the generated source code around a message handler, troubleshoot why a message handler isn’t being found, and other common user questions. I expect we will continue to expand this support based on any trends we see with user confusion.

We’re also doubling down even farther on the CLI path with the shortly forthcoming CritterWatch tooling that will provide CLI access to every bit of of an application’s “Critter Stack” configuration, the dead letter queue storage, domain centric queries against Open Telemetry tracking tools you might be using such as Jaeger, and queries against any Marten or Polecat event storage including a new “projection step through” function to trouble shoot projections.

I recently wrote about how we improved and expanded our CLI tooling in the “Critter Stack 2026” wave or releases.

CritterWatch

CritterWatch and its exposed MCP server will give you access to messaging and event workflow both from a static configuration standpoint and runtime discovered view as well. Every single bit of information exposed through CritterWatch and every single action is also completely exposed through its MCP endpoints, including access to the event stores of your Critter Stack application.

CritterWatch also comes with command line tooling as well that gives AI agents access to cross-application information about systems, workflows, messaging, and event stores.

AI Skills

We’ve built, and will continue to curate and evolve a set of AI Skills files for the Critter Stack tools including Marten, Polecat, Wolverine, and even Alba to help users use our tools more effectively. For Wolverine, the AI Skills will help you write code with Wolverine idioms that lead to much tighter code — or they’ll let you write the code in the conceptual way you’re used to, then suggest how to adjust that code to a tighter or more performance Wolverine idiom. All of which should help you be more effective over time with AI assisted development.

The AI Skills also teach your AI agent how to utilize the built in CLI

You can purchase access to these AI Skills here on the JasperFx website. All of our support plans also include access to these AI Skills as well as the forthcoming CritterWatch packages that are hopefully available by the time you read this.

Spec Driven Development and Event Modeling with Bobcat

We’re working a little bit on our solution for “Spec Driven Development” with a tool (so far) called Bobcat. I’m not sure what exactly will land in Bobcat or be spun out, but so far it’s the spiritual successor to my old Storyteller project for effective automated integration testing.

As part of that, Bobcat has a Gherkin capability for expressing executable specifications (we’re not taking a direct dependency on Reqnroll yet, but I’m personally undecided about whether we do that in the long run). We’re mostly going down the Gherkin path just because of the existing support inside of VS Code and JetBrains Rider for editing Gherkin documents. We’ll definitely look at other models for expressing tests too (simply marking up C#/F# test code for visualization? A markdown input? Something completely different?).

Bobcat also has a “Supervisor” capability that uses the new Microsoft Testing Platform (MTP) to drive xUnit.Net (or any testing tool that supports MTP and dotnet test) test suites with a bit more supervised parallelism and selective test retries. The “Supervisor” is also built to “know” when and how to recycle docker containers or restart test processes based on observed test failures. That’s been a god send for me doing my own CritterWatch development where the automated test suites are huge and test health can degrade as docker containers or processes have been up too long. We’re also building out a little we application you can use to see ongoing test results inside of the very long running test suites — again, for my own sanity when an AI agent is running tests and you can’t always tell if it’s active.

This is still pretty mushy as far as details, but we’re making the test output of Bobcat specifications write out quite a bit of detail about what Wolverine messages occurred, events that were appended, and HTTP calls received during the test — including the timings to help optimize test runs over time. I’m hopeful that this will be beneficial as well for AI assisted development by trying to make the tests themselves help diagnose test failures for quicker correction.

Lastly — and for the moment — we’re landing an Event Modeling capability into the core of the Critter Stack, but making the future Bobcat user interface be the visualization of the models. The concept that I’m proposing so far is:

• A new model and fluent interface API in our low level JasperFx.Events library that you can use to declare event types, read model types, and any other common elements of Event Storming or Event Modeling
• A new user interface in Bobcat that can visualize the Event Modeling slices defined by that model
• Integrate dotnet watch with that so you can interactively doodle with slice definitions and see the model change
• Have the specified model overridden when real code is built in the system, which is making us introducing “Event Modeling” concepts directly into Wolverine and our Marten/Polecat/Fisher event stores
• Integrate the Bobcat specifications directly into the Event Modeling visualization. Rather than have people waste time writing intermediate models for policies, constraints, or validation rules in a diagram, go straight to Behavior Driven Development specifications that become actionable specs
• Add more command line options to export the event slice definitions for AI agent usage
• Expand out AI Skills so an AI agent knows how to use Bobcat specifications and our models to build systems
• Probably invest in extending our existing code generation support to build out the shell of a “slice” from the model as a first step

Philosophically, I’m coming from a background in code-and-TDD/BDD-centric Extreme Programming and I’ve long been very dubious about the efficacy of “low code” visual modeling approaches or application generators like JHipster. I’m also not enthusiastic about any of the intermediate DSL approaches I’m seeing for modeling event driven architectures using YAML, XML, or custom built textual DSLs. Because of the Critter Stack’s relentless focus on low ceremony code, I think that we’re better off just adding the visualization capabilities on top of the code rather than trying for a hugely time consuming user interface effort.

Obviously

LLM Callouts?

I don’t have any details yet, but JasperFx is going to work with at least one client to build in integrations to LLMs from Wolverine and Marten/Polecat/Fisher projections using the Microsoft.Extensions.AI abstractions.

I think that we will 100% add LLM integrations into CritterWatch in the near future.

Agent Orchestration

This might end up being no more than a “build your own lightsaber” project for me, but JasperFx is building out its own take on an agent orchestrator and durable agent memory on top of the Critter Stack. And conveniently enough, we now have Fisher for Sqlite backed event sourcing that will be very convenient for this effort.

To be honest, I’ve been impressed with KurrentDb’s Capacitor tool, and that’s low hanging fruit for a Critter Stack-backed option.

It’s somewhat likely that this tooling would either end up landing in CritterWatch or at least share the same license model as CritterWatch, but it’s going to be a commercial tool all the way.

Summary

As the imagery at the top was trying to suggest, in terms of our AI strategy, we’re trying to throw all the spaghetti up against the wall right now and see what ends up sticking. And that’s the best that I’ve got for now.

CritterWatch 1.0 dropped yesterday, and you can read the official release on the JasperFx Software site.

This blog post is just me being thankful for all the folks who helped build CritterWatch or test it along the way:

• Babu Annamalai was instrumental in CritterWatch, our company infrastructure, and the Critter Stack in general
• Jeffry Gonzalez helped lay the foundation
• Anne Erdstrieck made CritterWatch (and Marten/Wolverine) a lot better by testing early versions on a very complex and high volume system
• Ben Virkler gave us a lot of feedback on usability and early problems (and we owe Ben some additional improvements for 1.1 that didn’t make the 1.0 wire)
• Laurence Gillian was an early tester
• Several other folks in Discord, and all of that feedback was helpful

And to Oskar Dudycz for all his contributions across the Critter Stack as much of CritterWatch are things that he and I were talking about years ago.

For my part, I founded JasperFx Software on the idea that we’d go down the “Open Core” model with business offerings of consulting, formal support agreements, and training around the Critter Stack tools, then supplement that with commercial add on tools for very advanced features, monitoring, and management. It took much longer than I’d hoped, but a couple months into JasperFx’s fourth year in business, we’re finally realizing the original vision.

And with all this out of the way, it’s time for me to get just a little break then start on CritterWatch 1.1!

We’re doing a live stream today on the CritterWatch 1.0 release — but it’s maybe a little dicy whether the official release happens before or after the live stream:-)

CritterWatch will have its 1.0 release tomorrow (Wednesday, August 19th) just in time for a live stream on YouTube to show just the user interface part of CritterWatch. Today though, we finally got one last RC.10 release out for some much delayed feedback.

We made a large amount of changes to optimize performance based on early customer feedback as we jumped right into the deep end of the pool and started by integrating CritterWatch into literally the single biggest Critter Stack system that we’re aware of.

This release candidate basically got us to what I expect the final product to be for 1.0, minus some user interface feedback and polishing at the last minute.

CritterWatch will require you to be running basically the latest of everything:

Stack: Wolverine 6.29.0 · JasperFx 2.52.0 · Marten 9.28.0 · Polecat 5.19.0 · Fisher 0.9.2 · Weasel 9.24.0

Three stores, one console

CritterWatch runs on Marten/PostgreSQL, Polecat/SQL Server, and — new in this release —
Fisher/SQLite:

The SQLite flavour needs no database service at all, which makes it the cheapest way to try the
console or to run it beside a small deployment.

Underneath, CritterWatch.Services is the store-agnostic core, compiled once and referenced by all
three.

First off, let me peel some egg off my face because I had allowed Claude to write quite a bit of code without close enough examination until just now. Arguably, we’re all good because we do have test coverage for the code I just refactored, so it’s all good in the end, but maybe just remember that a human in the loop is a good idea. And also know that all CritterWatch code will be closely reviewed before we flip that to 1.0!

Here’s an HTTP endpoint from CritterWatch, our forthcoming monitoring console for the Critter Stack. It adds a tenant to a monitored service:

[WolverinePost("/api/critterwatch/tenants/{serviceName}/add")]
[Middleware(typeof(RequireMultiTenancyLicense))]
public static async Task AddTenant(
    string serviceName,
    AddTenantRequest request,
    IDocumentSession session,
    IMessageBus bus,
    [FromServices] AuditLogService auditLog,
    HttpContext httpContext)
{
    // ... append an event, publish a command ...
    await auditLog.LogAsync("AddTenant", serviceName, null,
        $"Added tenant '{request.TenantId}' to {serviceName}",
        new Dictionary<string, string> { ["tenantId"] = request.TenantId },
        initiatedBy: AuditActor.From(httpContext.User));
}

Six parameters. Two of them are there for the audit log alone, and one of those — HttpContext — exists for a single expression: httpContext.User. We don’t read the request, the headers, the response, or anything else on it. We take the entire ASP.NET Core request context as a dependency to get at one ClaimsPrincipal.

That has a cost you feel in the test project. To test this method you need a store, a bus, an audit service and a request context. The audit behaviour — did we record the right action, against the right service, attributed to the right operator? — is only observable by standing all of that up and then querying the audit table afterwards.

Returning the intent instead of performing it

Wolverine has an interface called ISideEffect. It’s about as small as an interface gets:

public interface ISideEffect : IWolverineReturnType, INotToBeRouted;

There’s no method on it. The contract is a convention: return one of these from a handler or HTTP endpoint, and Wolverine will call any public Execute() or ExecuteAsync() method on it after your method returns. The interesting part is what happens to that method’s parameters — Wolverine registers each one as a dependency of the chain and resolves it for you.

So the audit log becomes a record:

public record AuditLog(
    string Action,
    string ServiceName,
    string? TargetUri = null,
    string? Details = null,
    Dictionary<string, string>? Parameters = null,
    string? InitiatedBy = null) : ISideEffect
{
    public Task ExecuteAsync(AuditLogService auditLog, ClaimsPrincipal? user)
    {
        var actor = string.IsNullOrWhiteSpace(InitiatedBy) ? AuditActor.From(user) : InitiatedBy;
        return auditLog.LogAsync(Action, ServiceName, TargetUri, Details, Parameters, actor);
    }
}

And the endpoint stops mentioning either dependency:

[WolverinePost("/test/audited/{serviceName}")]
public static AuditLog Post(string serviceName)
    => new("TestAction", serviceName, Details: "smoke");

AuditLogService and ClaimsPrincipal are resolved onto the chain because ExecuteAsync asks for them. The endpoint declares neither. The HttpContext parameter didn’t move somewhere else — it stopped existing. The principal is resolved at execution time rather than threaded through a signature that never wanted it.

Pure Functions FTW!

If you want to peruse our published Wolverine Best Practices, we strongly recommend trying to make the behavioral methods of your message handlers or HTTP endpoints be “pure functions” whenever possible. We also recommend trying to simplify code by opting to remove asynchronous code from your handlers as well as a way to reducing noise code, and that was why I reached quickly for the new AuditLog side effect. Combine side effects with other Wolverine goodies like our cascading messages syntax for publishing messages and the aggregate handler workflow and you get the tools to really simplify any application code related to business logic.

And just to make this clear, using pure functions (when possible) is a great approach because that:

• Isolates business or workflow logic from infrastructure concerns
• Promotes testability through fast running unit tests
• Reduces the code noise from asynchronous invocations

When not to reach for this

ISideEffect is for work you want to describe and let the framework perform. It’s a poor fit when the result of the work feeds the rest of your method — if you need the return value, you need the call, and a side effect only runs after you’ve returned.

It’s also not free indirection. A one-line await that nothing else depends on and nobody wants to test in isolation is fine as it is. What made the audit log worth converting was the ratio: two parameters and a request context, carried by five endpoints, to express one fact about an operation that had already happened.

That ratio is the tell. When a dependency exists only to record that something happened — audit, notification, telemetry, an outbound email — you are almost always better off returning a description of it and letting Wolverine make the call.

Summary

Hoo boy, let’s try to summarize this a bit:

1. I think having a man in the loop for AI built code is still pretty important
2. Pure functions are great for testability
3. Code noise has a real cost for your ability to reason about code and how it works — and I think that is still true even with LLMs doing so much more of the grunt work now
4. I think that our JasperFx curated AI Skills are valuable for developing with Wolverine and the rest of the Critter Stack because it’ll keep your LLM using more idiomatic features that can drastically shrink your code compared to typical .NET codebases, improve testability, and opt into Wolverine or Marten features that enhance performance. You can learn more about our AI Skills here.

This is a recent addition to Marten. We’ve started supporting many of the common PostgreSQL extensions that hare frequently supported by the major cloud providers. Outside of metrics collection or sensor data, I don’t have a great handle on what folks might use this for, so I’d love to hear from other folks what they’d want to do with TimescaleDB.

TimescaleDB support lets Marten turn its tables into TimescaleDB hypertables — automatically time-partitioned tables with columnar compression, retention policies, and continuous aggregates. It ships in the core Marten package under the MIT license, scoped behind its own Marten.TimescaleDB namespace, and is entirely opt-in at runtime via UseTimescaleDB() — stores that never call it pay nothing.

What it gives you today:

• a one-line UseTimescaleDB() opt-in that registers the timescaledb extension on every database Marten manages
• ProjectionAsHypertable<T>() to turn a time-bucketed flat table projection into a hypertable, with configurable chunk interval, compression, retention, and continuous aggregates
• DocumentAsHypertable<T>() to turn an append-heavy document table (audit logs, metrics, activity records) into a hypertable partitioned by one of its own timestamp members
• full participation in Marten’s schema migration model — the hypertable, its policies, and its continuous aggregates are created idempotently through the normal ApplyAllConfiguredChangesToDatabaseAsync path, and do not show up as drift on subsequent migrations

Requirements

The feature ships in core Marten, so there is no separate package to install — reach it with using Marten.TimescaleDB; and enable it with UseTimescaleDB().

TimescaleDB is a loadable module: unlike PostGIS or pgvector it must be listed in shared_preload_libraries before CREATE EXTENSION timescaledb will succeed. The official timescale/timescaledb images already do this. This repo ships docker-compose.timescaledb.yml (which runs on port 5433 so it can coexist with the main dev database) for local development, and a dedicated CI workflow using the timescale/timescaledb-ha image.

Enabling TimescaleDB on a store

using Marten;
using Marten.TimescaleDB;
var store = DocumentStore.For(opts =>
{
    opts.Connection(connectionString);
    // Registers CREATE EXTENSION IF NOT EXISTS timescaledb on every database
    opts.UseTimescaleDB();
});

Flat table projections as hypertables

The cleanest, highest-value fit is a flat table projection that rolls up events into a time-bucketed table — per-minute/per-hour metrics, IoT rollups, activity counters, and the like. Because the projection’s table is written by the async daemon (or inline), TimescaleDB then gives you time-chunked storage, columnar compression of old chunks, continuous aggregates for dashboards, and automatic retention — all declaratively.

opts.Projections.Add(new MetricsProjection(), ProjectionLifecycle.Async);
opts.UseTimescaleDB(ts =>
{
    ts.ProjectionAsHypertable<MetricsProjection>("captured_at", hyper =>
    {
        hyper.ChunkInterval = TimeSpan.FromHours(1);
        hyper.CompressAfter = TimeSpan.FromDays(30);
        hyper.RetainFor     = TimeSpan.FromDays(365);
        hyper.ContinuousAggregate("hourly_metrics", "1 hour",
            "avg(value) as avg_val, max(value) as max_val");
    });
});

public class MetricsProjection: FlatTableProjection
{
    public MetricsProjection(): base("sensor_metrics", SchemaNameSource.EventSchema)
    {
        // The single primary key IS the time column — see the constraint below.
        Table.AddColumn<DateTimeOffset>("captured_at").AsPrimaryKey();
        Table.AddColumn<double>("value").NotNull();
        Project<SensorReadingRecorded>(map =>
        {
            map.Map(x => x.Value, "value");
        }, tablePrimaryKeySource: x => x.CapturedAt);
    }
}

Configuration options

Compression / retention policies are applied on creation only

The compression and retention settings (CompressAfter, RetainFor, CompressSegmentBy/CompressOrderBy) are emitted when the hypertable is first created. Later changes to those values are not diffed and re-applied on subsequent migrations — adjust an existing policy with TimescaleDB’s own add_/remove_compression_policy / add_/remove_retention_policy functions (or drop and recreate the hypertable). The hypertable, its policies, and its continuous aggregates are otherwise created idempotently and do not show up as drift.

The partition column must be the projection’s primary key

TimescaleDB requires the partitioning column to participate in every unique/primary key on a hypertable. A FlatTableProjection always has exactly one primary-key column and upserts ON CONFLICT against it, so the only shape that maps cleanly onto a hypertable is one where that single primary-key column is the time column (a time-bucketed rollup). If you configure ProjectionAsHypertable against a projection whose primary key is something else (e.g. the stream id), Marten fails fast at schema-application time with a descriptive error rather than letting TimescaleDB reject the create_hypertable call.

Document tables as hypertables

Append-heavy document types — audit logs, metrics, activity records — can be stored in a hypertable partitioned by one of their own timestamp members:

opts.UseTimescaleDB(ts =>
{
    ts.DocumentAsHypertable<AuditEntry>(x => x.CreatedAt, hyper =>
    {
        hyper.ChunkInterval = TimeSpan.FromDays(1);
        hyper.CompressAfter = TimeSpan.FromDays(30);
        hyper.RetainFor     = TimeSpan.FromDays(365);
    });
});

Because TimescaleDB requires the partition column to be part of the primary key, DocumentAsHypertableduplicates the selected member into a NOT NULL column and adds it to the document table’s primary key, making it (id, created_at). Marten’s own schema model is updated to match, so there is no schema drift, and the generated upsert / update / delete SQL picks the composite key up automatically (the same machinery that backs list- and range-partitioned document tables).

The partition member must be immutable

Because the timestamp is now part of the primary key, it must not change for a given document id. Marten’s update path matches on the full primary key, so mutating the timestamp after the first Store would fail to find the existing row. DocumentAsHypertable is intended for append-heavy types whose timestamp is set once on creation and never modified. Loading and deleting by id still work (there is exactly one row per id), though a load by id alone cannot use chunk exclusion and will scan all chunks — query by the time column, or by id plus a time range, for time-partitioned performance.

Multi-tenancy

Hypertables work with Marten’s conjoined (single-table) tenancy — the tenant column is just another column on the chunked table. For database-per-tenant, each tenant database needs the timescaledb extension; UseTimescaleDB() registers it on every database Marten manages, so this is handled for you.