Day 2 of Wave 8! If you haven’t been following along, Wave 8 is happening over multiple days. On Day 1, we introduced a slew of capabilities targeted towards teams & enterprises.

Today’s theme is Cascade customization.

The quick tl;dr of features we are launching today:

Custom Workflows: Create and save rulebooks that can be invoked from Cascade with autogenerated slash commands
File-Based Rules: A refresh of our .windsurfrules file that allows for multiple rules files that are tied to various conditions
Simultaneous Cascades: Start work in a new Cascade while another one is executing, and never be left waiting
Cascade Plugins: New panel to manage and discover MCPs, disable individual tools, and more
Further MCP Integration: MCP resources and multimodal responses now available

What do we mean by Cascade customization?

Cascade is a very powerful platform, but at the end of the day, it is a platform. By that, we mean that it is a generic system that is capable of doing a very large range of tasks, and benefits from a user guiding it so that it can be even more effective at completing that user’s unique tasks. While this generality is great for many reasons (ex. it isn’t just a point solution that can only be used for a subset of tasks), it also means that our users benefit from intuitive and convenient ways to customize the platform. That’s the set of features that we are going to talk about today.

Custom Workflows

Raise your hand if you have ever found yourself repeating the same set of steps you did before, with maybe some slight variations in details. This could take a whole lot of forms:

Build a particular target, change a config file, redeploy the service, generate a PR with the config changes
Pull PR comments from a PR and automatically resolve the comments (a nice tie in with Windsurf Reviews from yesterday’s Wave 8 announcements)
Update dependencies across multiple services and create PRs for each one
Generate and update API documentation when endpoints change
Set up a new microservice with all the required boilerplate code and configurations

It’s a natural part of software engineering, especially within enterprise software organizations. Of course Cascade can accelerate our users across any of these workflows, but why do our users even have to prompt Cascade to do the same things over and over? Why do different developers in the organization that are doing the same tasks have to redefine the wheel for themselves? These were the basic questions that motivated Custom Workflows.

Defining a Workflow is simple. A user just has to create a markdown (.md) file within the repository root folder of .windsurf/workflows/, and name it something descriptive to the Workflow they want to specify, such as build-and-deploy-mytarget.md.

Once the file is created, the user will be greeted with a custom GUI wrapper around the markdown file, with the bulk of work being to write out the steps in the Workflow.

Once the Workflow is saved, all the user has to do to invoke it within Cascade is to use a slash command with the format of /name-of-workflow, essentially the file name that the user defined the Workflow with, except without the .md filetype suffix:

An easy way of thinking about Workflows is that a Workflow provides a skeleton for the multiple steps that Cascade has to take. Cascade will use it as input, combine it with information about the current unique shared timeline of human and AI activity, and take action accordingly.

One important aspect to highlight of how we have architected Workflows is that they are checked into a repository. That means they are instantly shared within the organization, and multiple team members can participate in iterating and refining these Workflow descriptions. Users don’t have to redefine wheels, everyone automatically gets better with every improvement to a prompt, and best practices get encoded directly into the codebase.

All of these pieces means that Cascade can actually be used to create a Workflow based on a Cascade conversation itself. If a user has figured out a pattern with Cascade, they can just ask it to save it as a Workflow, and it’ll generate a corresponding markdown file!

Our engineering team has already built dozens of Workflows to eliminate a lot of the effort executing repetitive, simple tasks. We are excited to see what everyone else builds with Custom Workflows!

File-Based Rules

Ok, now raise your hand if you have found yourself adding similar sentences to the prompt for Cascade across multiple conversations because of particular rules you want it to follow, such as packages to use or best practices to adhere to. Another very common use case that is also usually more prominent in enterprise settings.

We introduced the concept of a .windsurfrules file all the way back in Wave 1, but we wanted to revisit the Rules concept because how users want to define rules is often much more granular than stuffing all of the potential rules in a single file.

Now, Rules are defined in markdown (.md) files within the repository’s root folder of .windsurf/rules. After creating a Rules file with a descriptive name (just like with Workflows), the user will be greeted with a GUI wrapper around the Markdown file.

There are two main pieces to define for the Rule: the rule itself and its Activation Mode. The Activation Mode essentially defines under what conditions the Rule should apply. The current options are:

Manual: the user has to explicitly @-mention the Rule by name within the conversation
Always On: always applied, which is great for specifying information about the preferred libraries and frameworks of the repository
Model Decision: defined by a text description of when the Rule should be applied, which Cascade will evaluate to determine whether the Rule should be applied or not
Glob: defined by a glob pattern, which is a heuristic to force a Rule to only be applied within a subdirectory or subset of files within the repository

All Rules can also be at-mentioned as well using @rules: (Manual Activation Mode rules must be at-mentioned to apply), using the name of the corresponding markdown file, without the .md filetype suffix:

These Rules are defined within the root of the repository and therefore only apply when the repository is loaded into the workspace. If multiple repositories are loaded into the same workspace, then the union of all corresponding sets of Rules will be available to the user. That being said, we also have the concept of “Global Rules”, which are rules that transcend any repository and are tied to the user’s Windsurf account. This is a single file similar to the previous .windsurfrules file, but should be really limited to rules such as “respond in Spanish” that are truly global:

One thing we want to point out is that Rules and Workflows are complementary. Rules allow our users to not have to define the same general standards in every Workflow description, while Workflows allow for placing structure around a series of actions as opposed to Rules applying on each individual response. Both are defined as files in a repository, allowing organizations to share best practices and enforce standards at the point of code generation and iteration, as opposed to later in the software development life cycle during code review.

We think that this is a massive upgrade to the Windsurf Rules system, and coupled with Workflows, we believe that Windsurf has some of the deepest agentic customization capabilities on the market today.

Simultaneous Cascades

There are a lot of raising hands today - raise your hand if you’ve found yourself just waiting and watching Cascade get work done even if you are very confident that it will do the right thing, either because there are multiple steps and edits that just take time to iterate over or because there are executed terminal commands that take time to run. Wouldn’t it be great if you could just start another Cascade conversation to get started on some more work rather than getting blocked on this existing conversation’s run?

Well, that’s pretty much the entire gist of simultaneous Cascades. Now, even when a conversation is running, users can start a new conversation and get even more done:

The cool part is that if there is action that the user needs to take themselves in the “background” Cascade, such as accepting a terminal command to run, we will provide a notification for you to quickly navigate to that conversation and keep the process running:

This pattern provides even more control over the system, and should be a clear accelerator for every power user of Cascade.

Cascade Plugins

There has been a lot of momentum in the overall industry behind the Model Context Protocol (MCP), introduced by Anthropic late last year. We think this is great, because that means Windsurf can benefit from work done generically by the broader community to improve agentic behavior, and our customers can also build upon this protocol for their custom data sources and use cases.

However, our implementation of integrating in MCP servers, which we did back in Wave 3, was due for a refresh. There was no great way to manage or discover MCPs, and no finer grained control over which tools from the MCP server were actually desired (which is especially relevant since we have to enforce a max number of MCP-based tools to prevent degradation in the agentic behavior).

In this Wave, we are introducing a new Cascade Plugins panel that helps with all of this.

First, it is much easier to see what MCP servers are available, and we have even added a verified checkmark for the MCP servers created and maintained by the corresponding company:

Each MCP server now has a proper description, and a settings toggle to disable or uninstall an enabled server, just like with extensions to the Editor itself:

With this view, users can also enable or disable individual tools within an MCP server. Often, users don’t need the full set of tools offered, so this helps conserve the number of tools connected to Cascade. As part of this Wave, we have also increased the max number of enabled MCP tools (not servers) to 100, from previously 50:

We hope this makes it even easier to work with MCP within Cascade!

Further MCP Integration

For those of you familiar with MCP, you will know that MCP servers and clients are not the only pieces of the protocol, and so in this Wave, we have extended our integration with MCP to include MCP resources as well as multimodal responses:

Note that image output support currently only works with Anthropic models.

To continue the recap:

Day one: Teams and enterprise features, including Windsurf Reviews, Knowledge, and Conversation Sharing
Day two (today): Cascade customization features, including Customer Workflows, File-Based Rules, and Simultaneous Cascades

See you tomorrow, where we will wrap up Wave 8 with our last batch of updates!