The risk of ransomware is real - are you ready? Richard talks with Heather Renze about her experiences dealing with a ransomware attack and how to get prepared when it happens to you. Heather talks about how ransomware has evolved into a business that has operators, affiliates, and even tech support. Making a plan is essential - involving finance, legal, and IT. Cyberinsurance plays a big role, as do regulatory bodies - it depends on the business you're in. But your plan needs to know three essential things: what breaks first, how long your company can function with it broken, and who can decide on what to do next in the first hour of the event. The plan may or may not work perfectly, but not having a plan is far worse. Get ready!

Links

• Ransomware Guidance from NIST

Recorded June 25, 2026

Recently, five teams in the Rust project adopted a policy that I originally authored, governing how Large Language Models can be used when contributing to the rust-lang/rust monorepo. Notably, the new policy is not an official stance on LLMs, and does not apply everywhere in the Rust project. I wrote it for a very specific purpose, described below.

This post talks about why we created that policy, what it says, and how this will affect contributors.

The policy affects the following groups of people:

• People who review or moderate PRs on rust-lang/rust.
• People who author PRs with LLM-generated code on rust-lang/rust.
• People who discover issues using LLMs and post them on rust-lang/rust.
• People who write issues or comments that directly quote an LLM on rust-lang/rust.

If you are not in one of those groups, you don't have to change anything about how you work.

Why was this policy created?

While the Rust project is a collection of technical artifacts, it is also a community of people who work together to build, maintain, and extend those artifacts. When we talk about "contributing to the Rust project", we partly mean work on those artifacts, but we also mean joining that community and collaborating with the people already there.

Even before this policy was created, people were using LLMs to contribute to rust-lang/rust. Some of those uses respected our community: translating messages to English so people could draft them in their native language; finding poor diagnostics for code snippets that new contributors to Rust might write; analyzing RFCs to see if they were missing a discussion of other parts of the language that could affect the design. Some of those uses, sometimes unintentionally, did not.

I've seen LLMs causing three main issues for our community:

1. Polished technical products no longer indicate effort and understanding.
2. Making code easier to write exacerbates our existing issues with review bandwidth.
3. People mechanically copy-pasting to and from an LLM is a waste of our time.

As time went on, these issues grew and grew, until we had to create dedicated channels and moderation policy for how to deal with them. However, those channels work against our goals of being transparent and welcoming, because new contributors have no idea what the rules are.

The new policy formalizes those rules publicly, so that new contributors know how to join our community without getting their PRs closed for reasons they don't understand, and so that existing reviewers can easily point to the rules as an actionable reason when closing PRs that don't follow them.

Technical products no longer indicate effort

It used to be that if an open source project got a polished, well-tested, detailed PR, that indicated that there was someone on the other end who had put time, effort, and understanding into the PR. That influenced Rust's culture in several ways:

• We are generally reluctant to close PRs, since they represent someone else's hard work.
• Our process emphasizes incremental discussions, where PRs are allowed to change existing design if we discover new facts during creation or review.
• We treat PRs as an indication that someone is interested in joining our community and being mentored to work on future PRs.

With LLMs, none of these signals are reliable. Polished PRs no longer indicate effort; authors of polished PRs no longer necessarily understand their code—and in the case of autonomous agents, there is no longer someone on the other end at all; and because it's become so much easier to write code, a polished PR no longer indicates that someone is likely to stick around for the long term.

Making code easier to write causes review issues

At the time of writing, there are 1,281 open PRs to rust-lang/rust. This represents a staggering amount of time invested by both authors and reviewers. We have long had the problem that there are more people who want to write code than people willing to review it. With the advent of LLMs, this problem only gets worse.

Most of the work of reviewing is not simply catching bugs. A great deal of it is deciding whether this direction is a good approach, whether the PR is a good idea at all. In other words, reviewing is made of decisions.

"Shotgunning" PRs at reviewers incurs a high mental cost for them. I think most authors of LLM PRs believe that they are sincerely helping, but from our perspective, the code itself is the smallest and in some ways least important part of the change. We care much more about authors understanding what the code does, planning how it will change in the future, and deciding what it should look like. The code itself cannot help with any of those.

Mechanically copy-pasting LLM output is a waste of time

We will often get people who respond to review comments by copy-pasting them into their LLM, then copy-pasting its response back onto GitHub. Bluntly: this is a waste of everyone's time. If we wanted an LLM's opinion, we could have asked it ourselves. We want to hear your thoughts, not a machine's.

Moreover, this is a breach of trust between the reviewer and the author. Our assumption when we review is that we're talking to a real person who wants to do their best work. Pasting LLM text creates suspicion: does the author actually care? Is there a person here at all?

So why a policy?

Before this policy, we had a "wild west" approach to moderation. We had dozens of LLM PRs; no disclosure rules; people trying to add risky MIR optimizations as their first PR; and people posting "Verification: git diff --check" in their PR description as if that did something. While we had something for moderators to point to in the form of "Empower reviewers to reject burdensome PRs", our enforcement was inconsistent and our rules were not published anywhere. In practice, the rule was "anything goes, as long as it's not obviously horrible". Compared to the previous situation, the new policy is both much more strict and much more clear.

Regardless of your opinions on whether LLMs are good, bad, or a secret third thing, they can no longer be ignored. Our choices are not "no policy" or "policy". Our choice is whether to have the policy be an unofficial list of moderation notes or something we stand by publicly.

Why not ban LLMs altogether, or allow any use of LLMs that we think are pro-social? Because Rust governance doesn't work that way. We do not have a benevolent dictator who can say "No LLM-generated content, whether it be code or prose." or "AI is a tool, just like other tools we use".

Rust operates by consensus. As the policy says:

There is not a consensus within the Rust project—and likely never will be—about when/how/where it is acceptable to use AI-based tools. Many members of the Rust project and community find value in AI; many others feel that its negative impact on society and the climate are severe enough that no use is acceptable. Still others are working out their opinion.

Despite these differences, there are many values we all share:

• Building a community of deep experts in our collective projects.
• Building an inclusive community where all feel welcome and respected.

We want it to be possible to change the policy in the future. The policy has several provisions that make it easier to change than it was to originally adopt. The leadership council is also considering creating a sub-team that would handle LLM policy so we have fewer "nightmare" 30-person approval requirements.

I do not think every rule in this policy is wholly good. I do think that writing our rules down is better than not writing them down, and that having a policy that everyone kinda dislikes pushes us to improve our governance structures.

What does the policy say?

The policy summarizes itself this way:

It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.

Uses in the first category are allowed, sometimes requiring disclosure. Uses in the second category are heavily restricted.

General rules

No one except the author is required to read LLM output unless they choose to: LLM output isn't allowed in public docs, PR descriptions, or Github comments unless it's clearly marked; reviewers aren't required to look at LLM PRs if they don't want to.

No one is required to use LLMs to contribute to rust-lang/rust: policies must be written first for humans, and only summarized for machines; LLM reviews cannot substitute for human review or self-review.

You are allowed to generate LLM content that only you see, without disclosure, as long as you do not post it anywhere that you expect us to read or review.

Disclosure is required for machine translation, "trivial" changes, discovering bugs, and reviewing other people's work using an LLM. We welcome messages posted in your native language; English translation is not required to contribute.

There are very strict guidelines on LLM-generated code changes:

Pre-arranged, non-critical, high-quality, well-tested, and well-reviewed code changes that are originally created by an LLM are allowed, with disclosure.

The policy holds LLM-generated changes to a higher bar than human-authored changes, not a lower one: LLM PRs are required to have tests, full stop, regardless of how hard that is, as well as various other restrictions; LLMs must not generate soundness-critical changes unless the author is already a domain expert, and even then it's strongly discouraged.

In general, the policy focuses on understanding, helping to ensure that we have a mental model of our code, not just artifacts that mechanically do the right thing. Our motivation is influenced by Profession by Isaac Asimov. No programmer tapes.

Moderation rules

You must disclose LLM-generated content. You can choose to not post LLM content, or you can choose to post it and disclose its origin. You may not hide LLM involvement.

Harassment is not allowed. You may not harass people for using an LLM, regardless of whether or not their use is banned by the policy. You must follow the Code of Conduct at all times when interacting with the Rust project.

See the policy itself for more information.

Some parts of the policy are unenforceable. This is not a bug. The goal is not to catch every violation, but to create a clear bright-line rule: Disclosure is required for all public LLM text, unless specifically exempted by the policy. This allows moderators to identify violations based on actions, not on intent, and only consider intent when deciding how to respond.

How does this affect contributors?

Issue reporters

You must disclose any LLM involvement in discovering or reporting issues. You must tell us if you found an issue using an LLM. You must clearly quote and indicate which parts of your report were LLM-generated; the "no LLM-generated comments" rule applies to you too.

Authors who post LLM-generated code

I have written a list of guidelines you should follow if you make a PR to rust-lang/rust with LLM-generated code. You can avoid thinking about them, or indeed reading the list at all, if you follow this simple guideline from the policy:

It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.

See the "Allowed" section of the policy for a full list of what's meant by that. See rustc-dev-guide for the full list of guidelines.

Reviewers

General review

You are allowed to close PRs that don't follow the policy, no questions asked. Please point the author to #llm-mentoring at the same time. See the dev guide for exact circumstances and suggested wording.

You are not responsible for determining whether a PR is LLM-generated; that responsibility lies with the author. We will add a PR template that asks authors whether their code was LLM-generated so that this rarely comes up.

If an author claims their code is not LLM-generated, but you're still not sure, please report the PR privately to moderation. Style is not evidence; please do not accuse people of using an LLM. Reporting is not intended to be a penalty; the mod team is interested in seeing non-violations as well as violations.

Review of LLM code

If you have volunteered to review LLM PRs, the following section applies to you. No one is required to review LLM PRs unless they volunteer.

Everyone is expected to follow the new policy, not just authors. That means it is your responsibility to check whether an LLM-created PR touches an area that's disallowed by the policy, such as docs, diagnostics, or soundness-critical changes. You may request that the author redo it without LLM-generated code, in which case this section doesn't apply.

There's a more detailed summary of the rules you're expected to enforce in the dev guide. The official policy remains canonical.

What next?

Quite a lot of work has been put into this by moderators, team leads, reviewers, council representatives, and various other people inside and outside the project. Some of that work started months ago before the policy itself was written. I'd like to thank everyone who contributed, whether directly or indirectly.

This is not the end of the story. One of the goals of the policy is to help us gather data: Are people doing interesting and useful things with LLMs? Are they learning? Are they making repeat contributions? The answers to those questions will help us determine how the policy changes in the future.

This is not the first LLM policy published by teams in the Rust project, and hopefully it will not be the last. While the current policy only applies to the rust-lang/rust monorepo, I still believe that Rust would benefit from a project-wide policy that specifies what we expect in chats, forums, public communications, repositories without an explicit policy, and other cross-project areas.

What you'll learn in this post:

• The challenges of maintaining collections of MCP servers.
• Why simple tools can lead to higher token usage.
• Introducing the Octopus Easy Mode MCP server.
• Demonstrating how the Octopus Easy Mode MCP server can be used to expose runbooks as MCP tools.

All examples in this post are copy and paste prompts, so you will have a working MCP server executing runbooks in 30 minutes.

Introduction

Model Context Protocol (MCP) servers are the new AI layer specifically designed to support agentic workflows. The protocol has gained an enormous amount of support, and it is reasonable to expect that major software vendors will provide an MCP server. Exposing a combination of MCP servers to your AI harness allows you to complete complex tasks while leaving decisions about which service to call to the AI. Agentic workflows are very much founded on the idea that LLMs can ground themselves with trusted, external sources of truth, use tools to interact with the world, and consume feedback to make decisions about how to complete a task.

Challenges with MCP servers

However, maintaining collections of MCP servers is a non-trivial challenge. End users have to maintain a list of servers, which is challenging to standardize across an organization, and with the added complexity of embedding credentials in the mcp.json file. Like any desktop software, local MCP servers also need to be kept up to date, while remote MCP servers must be hosted and maintained by a dedicated team.

Exposing a collection of general-purpose tools to an LLM also increases token use. LLMs are quite capable these days of reasoning about how to complete a task, but this comes at the cost of lengthy chain-of-thought reasoning as the LLM works out how to combine otherwise disparate tools.

And there will always be gaps in MCP server coverage. A server may not be available, network security rules may prevent access, or the task to be automated may be too complex and bespoke for an LLM to reliably complete.

Octopus Easy Mode MCP server

The Octopus Easy Mode MCP server is a community project that takes a different approach to traditional MCP servers by exposing runbooks as MCP tools. This allows any process that can be automated with a runbook to be executed by an LLM, which has a number of benefits:

• One MCP server can execute any process that can be automated with a runbook.
• Octopus orchestrates complex processes as a series of deterministic steps.
• Token count is reduced as the LLM can delegate the execution of complex processes to the Octopus server, rather than having to generate all the steps itself.
• Octopus provides security and auditing features, making it possible to restrict and trace the LLMs actions.
• There is no longer any specialized knowledge required to create an MCP server – anyone who can create a runbook can expose it as an MCP tool.

In this post, you'll learn how to use the Octopus Easy Mode MCP server to expose a runbook as an MCP tool and then use that tool to automate a process.

Prerequisites

• An Octopus Cloud account. If you don't have one, you can sign up for a free trial.
• The Octopus AI Assistant Chrome extension. You can install it from the Chrome Web Store.

:::div{.hint} The Octopus AI Assistant will work with an on-premises Octopus instance, but it requires more configuration. The cloud-hosted version of Octopus doesn't need extra configuration. This means the cloud-hosted version is the easiest way to get started. :::

Creating the runbook

The first step is to create a runbook that will be exposed as an MCP tool. In this example, you'll create a runbook that will print the current date and time.

Run the following prompt in the Octopus AI Assistant:

Create a project called "Easy Mode MCP" and then:
* Add a runbook description
* Add a runbook called "Get Current Time".
* The runbook must have a single script step that echoes the current time with the PowerShell command `Get-Date`. 
* Create a single environment called "MCP". Do not create any other environments.
* Configure the runbook to only run in the MCP environment.

This prompt creates a project to host the runbooks used by the Easy Mode MCP server. It then creates a runbook that you'll call from an MCP client.

Run the MCP Server

The easiest way to run the Octopus Easy Mode MCP server is to use the Docker image. The following mcp.json file can be used to configure the server:

{
  "servers": {
    "easymode": {
      "type": "stdio",
      "command": "docker",
      "args": [
        "run", 
        "--rm", 
        "-i",
        "--pull=always",
        "-e", "EASY_MODE_MCP_TRANSPORT=stdio", 
        "-e", "EASY_MODE_MCP_AUTH_TYPE=none", 
        "-e", "EASY_MODE_MCP_OCTOPUS_URL=https://yourinstance.octopus.app", 
        "-e", "EASY_MODE_MCP_OCTOPUS_API_KEY=API-APIKEYGOESHERE", 
        "-e", "EASY_MODE_MCP_OCTOPUS_SPACE_ID=Spaces-##", 
        "ghcr.io/octopussolutionsengineering/octopuseasymodemcp:latest"],
      "timeout": 600000
    }
  }
}

Replace the following values in the mcp.json file:

• EASY_MODE_MCP_OCTOPUS_URL with the URL of your Octopus instance.
• EASY_MODE_MCP_OCTOPUS_API_KEY with an API key that has access to the runbook you created.
• EASY_MODE_MCP_OCTOPUS_SPACE_ID with the ID of the space that contains the runbook you created.

Now run the prompt from your chat client:

Get the current time

:::div{.hint} Your MCP client may be able to return the date and time without needing to call an MCP server. If so, you can force the LLM to call the Easy Mode MCP server with the prompt Get the current time from the easymode mcp server. :::

The MCP server will create a new snapshot of the runbook, run it, and return the result.

Importantly, you did not have to instruct the LLM to run a runbook. The Easy Mode MCP server does not require the end user to know that they are running runbooks, or even that the server is backed by Octopus. The runbooks are exposed directly as tools.

You can see this by asking the LLM to list the available tools from your chat client:

List the available tools

Passing parameters to the tool

Prompted variables are treated as parameters to the tool. For example, you can create a runbook that takes a name as a parameter and returns a greeting.

Run the following prompt in the Octopus AI Assistant:

Create a runbook called "Greet User" in the "Easy Mode MCP" project and then:
* Add a runbook description
* Add a single prompted variable called "Name" with the description "The name of the user to greet" and set the default value to "World".
* Scope the "Name" variable to the "Greet User" runbook.
* Add a single script step that echoes "Hello, #{Name}!".
* Configure the runbook to only run in the MCP environment.

Restart the MCP server to pick up the new tool, and then run the following prompt from your chat client:

Greet the user "Finn"

:::div{.hint} The process of restarting the MCP server is different with each client. Visual Studio Code allows you to restart the MCP server by clicking the "Restart" link above the MCP server when editing the mcp.json file:

:::

The MCP client is smart enough to know the name Finn must be passed to the Name variable in the Greet User runbook, and the MCP server will return the greeting.

Adding elicitation

Elicitation is the process of asking the user for information that is required to complete a task. The Octopus Easy Mode MCP server supports elicitation by adding manual intervention steps to a runbook.

Run the following prompt in the Octopus AI Assistant:

Create a runbook called "Welcome User" in the "Easy Mode MCP" project and then:
* Add a runbook description
* Add a single manual intervention step called "Ask for Name" with the instruction "Please enter your name" and the prompt "What is your name?".
* Add a single script step that echoes "Hello, #{Octopus.Action[Ask for Name].Output.Manual.Notes}!".
* Configure the runbook to only run in the MCP environment.

Restart the MCP server to pick up the new tool, and then run the following prompt from your chat client:

Welcome the user

You will be asked to enter your name and The MCP server will then return the greeting.

:::div{.warning} Not all MCP clients support elicitation. This post was tested with Visual Studio Code and the GitHub Copilot Chat extension. :::

You can automatically add generated notes to the manual intervention by setting EASY_MODE_MCP_AUTO_POPULATE_INTERVENTION_NOTES to True:

{
  "easymode": {
    "type": "stdio",
    "command": "docker",
    "args": ["run",
      "--rm",
      "-i",
      "--pull=always",
      "-e", "EASY_MODE_MCP_TRANSPORT=stdio",
      "-e", "EASY_MODE_MCP_AUTH_TYPE=none",
      "-e", "EASY_MODE_MCP_OCTOPUS_URL=https://yourinstance.octopus.app",
      "-e", "EASY_MODE_MCP_OCTOPUS_API_KEY=API-APIKEY",
      "-e", "EASY_MODE_MCP_OCTOPUS_SPACE_ID=Spaces-##",
      "-e", "EASY_MODE_MCP_AUTO_POPULATE_INTERVENTION_NOTES=True",
      "ghcr.io/octopussolutionsengineering/octopuseasymodemcp:latest"],
    "timeout": 600000
  }
}

The content placed into the notes section can be defined with the EASY_MODE_MCP_AUTO_POPULATE_INTERVENTION_NOTES_VALUE environment variable:

{
  "easymode": {
    "type": "stdio",
    "command": "docker",
    "args": ["run",
      "--rm",
      "-i",
      "--pull=always",
      "-e", "EASY_MODE_MCP_TRANSPORT=stdio",
      "-e", "EASY_MODE_MCP_AUTH_TYPE=none",
      "-e", "EASY_MODE_MCP_OCTOPUS_URL=https://yourinstance.octopus.app",
      "-e", "EASY_MODE_MCP_OCTOPUS_API_KEY=API-APIKEY",
      "-e", "EASY_MODE_MCP_OCTOPUS_SPACE_ID=Spaces-##",
      "-e", "EASY_MODE_MCP_AUTO_POPULATE_INTERVENTION_NOTES=True",
      "-e", "EASY_MODE_MCP_AUTO_POPULATE_INTERVENTION_NOTES_VALUE=Your custom note",
      "ghcr.io/octopussolutionsengineering/octopuseasymodemcp:latest"],
    "timeout": 600000
  }
}

:::div{.hint} Setting the EASY_MODE_MCP_AUTO_POPULATE_INTERVENTION_NOTES environment variable to True allows you to run runbooks that contain manual intervention steps without any user interaction. This is useful for MCP clients that do not support elicitation or for automating processes that require manual intervention. :::

Practical examples

Here are some practical Runbooks that you might expose to an MCP server.

Creating cloud resources

A common scenario for DevOps teams is to provision new cloud resources. This is often done with a combination of Terraform and Octopus.

Run the following prompt in the Octopus AI Assistant:

Create a runbook called "Create EC2 Instance" in the "Easy Mode MCP" project and then:
* Create a feed called "Docker Hub" pointing to "https://index.docker.io" using anonymous authentication.
* Add a runbook description
* Add a Terraform Apply step to the runbook called "Create EC2 Instance" with the following configuration:
```
# A mocked Terraform configuration simulating the construction of an EC2 instance
output "ec2_instance_id" {
  value = "i-1234567890abcdef0"
}
```
* Use the "Hosted Ubuntu" worker pool.
* Configure the Terraform step to use the execution container image "octopusdeploy/worker-tools:6.6.4-ubuntu.22.04" from the "Docker Hub" feed
* Add a step to run a script that writes `Your instance is #{Octopus.Action[Apply a Terraform template].Output.TerraformValueOutputs[ec2_instance_id]}` as a highlight.
* Configure the runbook to only run in the MCP environment.
* The runbook must be untenanted.

Restart the MCP server to pick up the new tool, and then run the following prompt from your chat client:

Create a new EC2 instance

Debugging a Kubernetes application

In this example, we'll imagine that a support team needs to restart a Kubernetes application. The runbook will delete the pod, triggering a restart.

Run the following prompt in the Octopus AI Assistant:

Create a runbook called "Restart K8s Web App" in the "Easy Mode MCP" project and then:
* Define the first step as a kubectl script step to the runbook called "Restart K8s Web App"
* Use the "Hosted Ubuntu" worker pool.
* Configure the kubectl step to use the execution container image "octopusdeploy/worker-tools:6.6.4-ubuntu.22.04" from the "Docker Hub" feed
* Add a script that checks for a pod called "my-web-app-pod", and if it exists, deletes it. If the pod doesn't exist, the script should write a message to the log and exit successfully.
* Use client side apply in the Kubernetes step (the mock Kubernetes cluster only supports client side apply).
* Disable verification checks in the Kubernetes steps (the mock Kubernetes cluster doesn't support verification checks).
* Enable retries on the K8s deployment step.
* Define the second step as a Slack notification step to the runbook called "Notify Slack" that sends a message to the channel "#k8s-notifications" with the message "The K8s Web App has been restarted." using the web hook url "https://mockslackwebhook.octopusdemos.com/".
* Configure the runbook to only run in the MCP environment.
* The runbook must be untenanted.

---

Create a token account called "Mock Token".

---

Create a feed called "Docker Hub" pointing to "https://index.docker.io" using anonymous authentication.

---

Create a Kubernetes target with the tag "Kubernetes", the URL https://mockk8s.octopusdemos.com, using the health check container image "octopusdeploy/worker-tools:6.5.0-ubuntu.22.04" from the "Docker Hub" feed, using the token account, and the "Hosted Ubuntu" worker pool. Scope the target to the "MCP" environment.

Restart the MCP server to pick up the new tool, and then run the following prompt from your chat client:

Restart the Kubernetes Web App

What is neat about this example is that we have captured a lot of business logic in the runbook. The pod to be deleted is defined, eliminating the need for the end user to know which pod to delete. The Slack notification step is also defined, so the team is notified when the pod is restarted.

While this logic could be captured in an LLM skill, you can imagine how many tokens would be required for the LLM to reason about the steps to restart a Kubernetes application and send a Slack notification. By exposing the process as a deterministic set of steps in a runbook, the LLM only needs to know that a tool exists to restart the Kubernetes application, and it can delegate execution of that process to the Octopus server.

Bootstrapping a new project

Here is an example where we create a runbook to call the AI Assistant to create a new Terraform project. The Octopus - Prompt AI step allows you to run the same prompts you have been typing into the AI Assistant directly from a runbook.

Run the following prompt in the Octopus AI Assistant:

Create a runbook called "Create new Terraform project" in the "Easy Mode MCP" project and then:
* Define the first step as an "Octopus - Prompt AI" step
* Set the prompt to "Create a new Terraform project with the following name: #{ProjectName} in the #{Octopus.Space.Name} space." and enable auto approve.
* Add a prompted variable called "ProjectName" with the description "The name of the new Terraform project" and scope it to the "Create new Terraform project" runbook.
* Configure the runbook to only run in the MCP environment.
* The runbook must be untenanted.

You will need to create an API key for the "Octopus - Prompt AI" step and define it in the Project.Octopus.Api.Key variable.

Restart the MCP server to pick up the new tool, and then run the following prompt from your chat client:

Create a new Terraform project called "My New Project"

A new project will be created in the same space as the runbook to deploy a sample Terraform configuration.

You're now chaining AI agents:

1. The MCP client calls the Easy Mode MCP server
2. The Easy Mode MCP server calls a runbook
3. The runbook calls the AI Assistant to create a new Terraform project
4. The AI Assistant calls an LLM to create a new Terraform project

Governance and compliance

Because the Easy Mode MCP server is backed by Octopus, it inherits all the governance and compliance features of Octopus.

You get audit logs showing what was run, when, and a persistent log of all the output:

These logs can optionally be sent to an external log aggregation service, such as Splunk or Datadog, for long-term retention and analysis.

The runbooks can be subject to Platform Hub policies, and can consume process templates.

Runbook events can trigger webhooks to notify external systems of runbook execution.

All credentials are centrally managed and can be sourced from external secret management systems, such as HashiCorp Vault.

Octopus provides a robust platform with proven governance and compliance features, all of which are now available to AI agents through the Easy Mode MCP server.

Difference between the Easy Mode MCP server and the Octopus MCP server

Octopus provides a general purpose MCP server that allows MCP clients to execute common Octopus operations, such as creating releases, deploying releases, running runbooks, getting deployment logs, etc.

The Octopus MCP server is more than capable of running runbooks, but it does not inherently know about the existence of runbooks, nor does it have a reason to link a runbook to a specific task.

For example, to run the "Get Current Time" runbook, you would write a prompt like this:

Run the runbook "Get Current Time" in the "Easy Mode MCP" project in the "MCP" environment in the "Default" space.

This command queries the space to get the space ID, the project to get the project ID, and the runbook to get the runbook ID. It then runs the runbook and returns the result. It then executes the runbook and returns the result.

In Claude Code, this was the token usage:

Usage by model:
    claude-haiku-4-5:  549 input, 17 output, 0 cache read, 0 cache write ($0.0006)
       claude-opus-5:  16 input, 1.5k output, 157.8k cache read, 12.7k cache write ($0.1956)

Running the same runbook with the Easy Mode MCP server, the token count is significantly lower:

Usage by model:
    claude-haiku-4-5:  521 input, 14 output, 0 cache read, 0 cache write ($0.0006)
       claude-opus-5:  4 input, 145 output, 29.0k cache read, 5.0k cache write ($0.0497)

By directly exposing runbooks as tools, the Easy Mode MCP server provides a more efficient way for LLMs to execute runbooks, reducing token usage and improving performance.

Conclusion

The Easy Mode MCP server provides a simple way for AI agents and MCP clients to execute Octopus runbooks as tools. This means AI-based workflows gain the scale, reliability, auditability, governance, and convenience of Octopus. And because most of the work is performed by Octopus, AI agents reduce their token use by offloading the execution of complex processes to Octopus.

Are your characters heading for a split? Discover 9 ways to set up a believable fictional breakup that feels natural and convincing.

Have you ever watched a film or read a book where a relationship falls apart for no convincing reason? It happens all the time. It’s as if the author or screenwriter knows they need conflict, so they use a breakup to create it.

This usually happens when the relationship is a sub-plot. But that doesn’t mean you can write it carelessly.

A poorly written breakup often happens in a single scene with little or no build-up. It makes me distrust the author—and everything that has happened in the story.

So how do you end a relationship in a believable way?

Start by creating a relationship that could plausibly fail. This is usually the relationship between protagonist and the love interest.

The warning signs don’t have to be obvious, but they should be there—in the dialogue, the body language, and interior thoughts. Weave them into the story from the beginning so the breakup does not come as a complete shock.

9 Ways To Set Up A Believable Fictional Breakup

1. Use the rescuer-rescued relationship

People in healthy relationships can save each other from mistakes and provide comfort when things go wrong. The problem begins when one person is always the saviour and the other is being saved. The rescuer will see the other person as needy and helpless. The rescued person will either enjoy being ‘looked after’ or he or she may begin to feel inferior.

To set it up: Use pressure to put this relationship to the test. When the saviour is needed somewhere else, the other character may feel abandoned. Or the ‘saved person’ could fight back against the over-protective behaviour.

2. Use the avoidance of difficult issues

Most of us would prefer not to deal with difficult issues, and we can get away with it for a while. However, actively avoiding dealing with them will put a relationship under severe strain.

To set it up: When tensions are running high, the issues will surface and it won’t be pretty.

3. Use the changer

People who are always trying to change each other cannot be happy. You know who they are. They say things like ‘Why can’t you be more like __________?’ or ‘If you weren’t always _________, we would be happy’. They are always living in that impossibly perfect future moment.

To set it up: Put them in situations where it becomes clear that their fantasies are just that. Show that the person is never going to change and has no desire to change.

4. Use the family

One of the partners may be too attached to or too distant from family members. This can be used as a believable way of building up tension. If somebody asks a partner to constantly choose them over other family or if somebody shows absolutely no interest in a partner’s family, there will be problems.

To set it up: Use family gatherings to highlight tensions. Allow one character to tell the other how his or her father would solve a problem. Interrupt an important conversation with a phone call from the family.

5. Use tension over money

The ways people save, earn, and spend money are brilliant pressure points. How much they earn is also a good way to set up conflict. Both partners should feel valued and equal in the relationship. They should both have a say in the way money is spent.

To set it up: Show how the one person uses money to control the other person or make them feel worthless.

6. Use an ex

People who still think about their previous partners or spend too much time with them – on the phone or in person – are doomed to fail in the present relationship.

To set it up: Let the character use the ex-partner as an excuse to avoid the new partner. When the pressure mounts, this will be a contributing factor to the breakup.

7. Use friends

If your friends don’t like your partner, trouble is brewing. Most people’s friends genuinely care about them and they have valid reasons for their dislike. Sometimes, they simply feel threatened by change. Whatever the reason for the conflict, it creates an unhappy relationship.

To set it up: Make it difficult to plan social events. Let the character spend more time with these friends. Watch the fireworks.

8. Use sex

Everything seems okay on the surface, but the intimacy is non-existent. In a healthy relationship, people work on keeping their sex lives interesting and healthy. In a bad relationship, this falls apart. Alternatively, the relationship could be based only on sex. This makes it difficult for the relationship to work on an everyday level.

To set it up: Contrast the couple with a happy, balanced relationship. Show them what they’re missing.

9. Use an age difference

If you need to have a relationship break up relatively simply, allow the people to outgrow each other. The younger person may want different things to the older person and vice versa.

To set it up: Put the couple in new situations where they encounter people who are not used to the age difference.

10 Ways To Build The Tension

1. Allow small things about the other person to annoy your character.
2. Let the character feel as if they are walking on eggshells around their partner.
3. Allow them to argue about morals, ethics, politics, animals, religion. Things that may have seemed abstract or tolerable in the past become important.
4. Let jealousy slip into everything.
5. Allow a lack of empathy for the other to set in.
6. Let the characters stop treating each other as friends.
7. Make sure that certain subjects are off limits.
8. Show a lack of respect. They could call each other names or mock each other.
9. Use body language. Examples: eye rolling when the partner is speaking, crossing arms, or turning your back.
10. Use silence.

The Last Word

A believable breakup begins long before the relationship ends. By planting small moments of conflict, unmet needs, and growing distance throughout your story, you create a separation that feels natural rather than forced. If the breakup is true to the characters and the story, readers will believe every word of it.

by Amanda Patterson
© Amanda Patterson

More posts from Amanda:

1. 3 Ways Sidekicks Strengthen Your Novel
2. Have You Chosen The Wrong Character As A Protagonist?
3. Does Your Character Fight, Freeze, Flee, Or Fawn?
4. 30 Character Motivations To Kickstart Your Story
5. 5 Instances When You Need To Tell (Not Show) In Your Writing
6. What Is A Sequel In Story Structure? A Writer’s Guide
7. What Is A Scene In Story Structure? A Writer’s Guide
8. How To Write A Gripping Novel: 5 Essential Tips
9. How Many Words Should A Novel Be? A Writer’s Guide To Word Counts
10. What Is A Novel Outline? 5 Strong Reasons To Outline Your Novel Before You Start Writing

Top Tip: Sign up for our free daily writing links.

The post 9 Ways To Set Up A Believable Fictional Breakup appeared first on Writers Write.

What's Changed

• .NET and Python: Extract Durable Task and Azure Functions integrations by @cgillum in #7465
• .NET: Fix Handoff orchestration sample not responding to user input by @peibekwe in #7442
• .NET: Fail declarative workflows when an agent returns an error by @peibekwe in #7497
• .NET: Updating version for dotnet release 1.17.0 by @peibekwe in #7514