Critter Stack Roadmap for September 2026

JasperFx Software is closing in on a couple big releases in the next week or two that are worth talking about now to get last minute feedback and maybe additional requests.

Critter Watch 1.1

I’m hoping to have a follow up https://critterwatch.jasperfx.net release that builds on our 1.0 release with a handful of new features:

1. Cron type scheduled recurring message publishing with a full dashboard for each management as well as matching MCP tools for AI agents. This builds on some recent Wolverine work that added recurring messaging. We looked at Quartz.Net, TickerQ, and Hangfire and decided that we could do what we needed to do for Wolverine and CritterWatch without taking on any explicit coupling. We’ll also be adding guides on what we think the best practices are for integrating Wolverine with the mature job scheduling tools out there, but we won’t be doing formal integration packages.
2. Stream compacting policies for users to be able to specify recurring background jobs to automatically choose event streams for compacting based on user defined criteria (more than 1,000 events? older than 6 months?). We think this will be a great way to keep Marten/Polecat/Fisher applications performant over time. That will build on top of the Cron messaging.
3. LLM callouts from CritterWatch alarm detection to use AI tools to potentially decide and carry out amelioration steps. This also builds on recent Wolverine additions for LLM integration.
4. Scheduling projection rebuilds or subscription rewinds for Marten/Polecat/Fisher so you can have projection rebuilds happen during off hours.
5. Bringing back the Embedded CritterWatch option to add CritterWatch to a single ASP.Net Core application instead of having to have a separate application. We think this will be very helpful for development time
6. Moar robustness! One of our earliest users has a phenomenally large system with a complex multi-tenancy strategy that has given CritterWatch internals and user interface quite a workout
7. Formal support for Event Modeling diagrams of configured and observed system behavior. To be more clear, this is Critter Watch being able to show you an Event Modeling visualization of the system as it actually is according to Wolverine configuration and observing the cause and effect between command messages and events appended or other messages being cascaded. This is part of our larger effort toward Event Modeling support.

Event Modeling Support and Spec Driven Development

Alright, this one is an arc across the entire Critter Stack to enable people who want to use Event Modeling, then use AI tools to scaffold or build applications using those models. We’re also working on a first class Spec Driven Development story for Critter Stack applications with and in addition to the Event Modeling tooling.

Here’s a diagram of the three main ways we’re looking to support Event Modeling and Spec Driven Development across the Critter Stack, with a pair of newer critter tools that aren’t quite to 1.0 yet in “Stoat” and “Bobcat” (more on these below).

The major pieces are:

1. A “Semantic Model” in our low level JasperFx.Events library that models everything there is to a vertical slice according to Event Modeling semantics
2. A new library called “Bobcat” that’s going to be our main Event Modeling visualization tool and Gherkin specification executor. It’s also a spiritual successor to my much older Storyteller project and has a lot of the same DNA for hopefully making automated integration testing more successful in enterprise systems. Bobcat also has command line helpers for generating skeleton Wolverine code for the event slice model
3. Our JasperFx curated AI Skills that help constrain your AI tools to generate the cleanest and most idiomatic possible code you can with the Critter Stack as well as helping you choose the best Wolverine or Marten options for whatever your system needs. The AI Skills will also help you utilize the Critter Stack test automation support.
4. A new tool named “Stoat” (no website yet, but we’re working on it!) that’s our “everything that makes AI usage more successful” tool including a feature set inspired by KurrentDb’s Capacitor that will add durable memory across your AI agents and coordination and visibility across AI agents. Stoat will be the controller for our entire Spec Driven Development story. Our thinking right now is that Stoat will be a commercial tool that will be bundled into AI Skills or CritterWatch purchases from JasperFx Software.

Imagine a couple approaches to modeling an event driven system:

1. Use the EventModelers.AI tooling for modeling. Stoat will be able to take the YAML file of the model exported from EventModelers.AI, then invoke AI agents and Bobcat to scaffold and develop a Critter Stack system from the model
2. Using nothing but Gherkin to define the slice model for your system, including BDD style specifications, and have Bobcat create a running Event Modeling visualization of your system as well as enabling Stoat to again execute a development plan based on that model
3. Lastly, and here’s where the Critter Stack is going to diverge quite a bit from seemingly the rest of the Event Sourcing community, a model where you can just write at least a skeleton of C# or F# types for events, read models, and command messages, then use a lightweight fluent interface in code to generate the Event Modeling visualization for easy review. I personally do not believe that the attempts to create intermediate DSLs for modeling event sourced systems like ESDM are going to be successful and that the Critter Stack’s very low code ceremony actually makes it easier to just write C# or F# code with a real IDE instead of futzing with DSLs.

But, to that last point, I think we’re going to be well set up to potentially add support later for all those DSLs and YAML formats and even that really gnarly 2000’s era looking XML format going around in conferences by translating those to our own event slice model and working from there.

And just to be clear, Stoat & the AI Skills and therefore our full Spec Driven Development strategy including our support for the EventModelers platform will be commercial add ons to the CritterStack. We’re still committed to “Open Core,” but these items are going to fall out of the MIT licensed core.

I’m of the opinion that everybody’s approach to AI assisted development is exactly what their prior opinions were about software development. I was much more heavily influenced by Extreme Programming back in the day and have always been very dubious about any kind of “Model Driven Development” and that has carried through to being dubious about a lot of these new event modeling or spec driven development approaches. That’s also why you’re going to see us emphasize BDD style specifications more than modeling approaches.

Extreme Scalability for Marten and Wolverine

JasperFx has an ongoing effort with a large client that involves some rather extreme scalability requirements (10’s or 100’s of billions of events in a single system, 500+ different PostgreSQL databases, about 250 unique message types and that many HTTP web services. And a modular monolith to boot). We’ve already done quite a bit, with more ideas still to come. JasperFx and our client will be publishing a white paper sometime this year laying out all the challenges they faced and what we did to be able to enable their scale.

I’m pretty excited for this to all come to fruition.

Random Things?

• More AI integration into Wolverine with the possibility of it maybe being a more durable option in place of Microsoft’s Agent Framework?
• DuckDb integration for Marten, with Polecat and Fisher coming later

Or suggestions or requests?

Oh, and this is a stoat: