If a deployment fails in Octopus and no one is around to see it, does it make a sound?

The gap between an event happening and the right person knowing about it is where deployments quietly stall. We've had consistent customer feedback that Octopus is one of many tools you use, and it's easy to miss when something requires your approval or intervention.

We've built a Slack integration so Octopus can tell your team what needs action, in the tool they already have open. There are two ways to use it:

1. Subscriptions: for event notifications that can be scoped to the teams that care about them
2. Send a Slack Message step: for Slack messages sent from a specific point in a deployment or runbook process

Subscriptions: our notification engine

Subscriptions are an existing feature that let users subscribe to events in Octopus. In addition to webhooks and email notifications, you can now have these updates sent to a Slack channel.

:img{ src="/blog/img/slack-integration/variable-changes.png" alt="Screenshot showing a subscription that is tracking changes to varaibles in two specfied projects" loading="lazy" }

A couple of suggested Slack channels to help you keep up to date with important events in Octopus without constant monitoring are:

• #deployment-failures that captures all deployment failures in one place
• #deployments-variables-changed that notifies when a variable has been updated
• #octopus-api-expiries that gives you warnings prior to API expiry events
• #octopus-mcp-oauth that informs when MCP authorization tokens are issued

:img{ src="/blog/img/slack-integration/variable-changes-notification.png" alt="Screenshot showing a notification in Slack that a variable has changed" loading="lazy" }

If you want your teams to be able to narrow notifications, event filters let you drill down into resources like projects, tags, and environments, so you can update a team channel with events they care about. Keeping your audience narrow and the notifications relevant prevents a mass muting event that makes the integration ineffective.

Slack steps made simple

We have a number of community steps that enable messages to Slack but the set up is more complex, our new Octopus Send a Slack Message step uses the oAuth integration so all you need to do is choose a channel and a message to send.

:img{ src="/blog/img/slack-integration/slack-step.png" alt="Screenshot showing a process with a slack step" loading="lazy" }

This step is particularly useful when placed immediately before a manual intervention step. The message goes out the moment the deployment reaches that point, so the approver knows to go and unblock it. The message field supports Slack markdown and Octopus variables, so you can include the project, release number, environment, and a link straight to the deployment.

:img{ src="/blog/img/slack-integration/slack-notification.png" alt="Screenshot showing a process with a slack step" loading="lazy" }

Learn more

Learn more about setting up the Slack integration here.

What's next for notifications?

• We're gauging interest in a Microsoft Teams integration so if you're a Teams team comment below.
• Notify and act: we're adding webhooks triggers to runbooks so you can use the webhook event in subscriptions to trigger a runbook. Follow along here.

Happy deployments!

AI is disrupting career progression by eliminating the learning opportunities at each rung while simultaneously enabling people to perform above their experience level, Alasdair Allan explained in his talk Engineering Progression When AI Ate the Middle at QCon London. Fewer junior developers join the industry, and AI slows hiring at the entry level.

I wanted one set of SQL checks to work in three places: while exploring a query, from a terminal and during code review.

That became SQL Atlas. It is a local, deterministic SQL analyzer with a browser interface, a CLI and a GitHub Action. This article covers the interfaces, the CI contract and the limits of static SQL analysis.

One analyzer, three interfaces

The analyzer returns structured data instead of printing messages directly. Each interface decides how to present the same result:

• The browser explains findings and links them to learning material.
• The CLI returns text, JSON or Markdown and uses stable exit codes.
• The GitHub Action converts findings into file annotations and a job summary.

Keeping presentation outside the analyzer prevents the CLI and Action from becoming separate implementations with different behavior.

A CLI needs a contract

The CLI accepts one or more files, or SQL through standard input:

npx --yes sql-atlas@0.5.1 analyze query.sql

echo "SELECT * FROM customers;" | npx --yes sql-atlas@0.5.1 analyze -

It supports PostgreSQL, MySQL, Oracle, SQLite, SQL Server and a generic mode. Output can be text for a person, JSON for another program or Markdown for an issue or report.

Exit codes are part of the interface:

• 0 means analysis completed and the configured policy passed.
• 1 means analysis completed but a severity or score threshold failed.
• 2 means the command or input was invalid.

This distinction matters in CI. A policy failure is not the same as a broken invocation.

Turning findings into pull request feedback

The Action runs as a bundled Node 24 program and does not download dependencies at runtime. A minimal workflow looks like this:

name: SQL review

on:
  pull_request:
    paths:
      - "**/*.sql"

permissions:
  contents: read

jobs:
  sql-atlas:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: milekv/sql-atlas@v0.5.1
        with:
          paths: |
            migrations/**/*.sql
            schema/**/*.sql
          dialect: postgresql
          fail-on: critical
          min-score: 60

Findings become GitHub file annotations. The full result is written to the job summary, and the Action exposes file count, finding count and lowest score as outputs.

The default policy only fails on critical findings. Teams can start in report-only mode with fail-on: none, inspect false positives and add stricter thresholds later.

What static analysis cannot know

SQL Atlas does not connect to a database. It cannot know table sizes, data distribution, available indexes, planner settings or the real execution plan.

For that reason, a warning such as a function applied to a filtered column means "check whether this blocks the index strategy you expect", not "this query is slow". Runtime performance still needs EXPLAIN, representative data and production-like measurements.

The browser includes a local PostgreSQL EXPLAIN JSON viewer for that next step, but the analyzer deliberately keeps its claims narrow.

Testing the distribution surfaces

The project tests the analyzer and both automation interfaces. CI builds the web app, CLI and Action bundle. A smoke workflow runs the repository's own Action against a known SQL file and verifies its outputs. CI also rebuilds the committed Action bundle and checks that it has no uncommitted difference.

The CLI package has no runtime dependencies. I verified the public npm package from an empty directory with a clean cache, including the executable version and a real stdin analysis.

Try it

• Demo: https://milekv.github.io/sql-atlas/
• Source: https://github.com/milekv/sql-atlas
• npm: https://www.npmjs.com/package/sql-atlas
• v0.5.1: https://github.com/milekv/sql-atlas/releases/tag/v0.5.1

I am particularly interested in examples where a rule is too broad, misses a dialect detail or produces an unhelpful CI annotation.

1211. Today, we look at the behind-the-scenes history of the Dictionary of American Regional English with Joan Houston Hall. We look at her personal journey into linguistics, the "word wagons" that traveled the country to collect oral histories, and the fascinating origins of regional words like "scrid" and "bobbasheely." Finally, Joan shares her top three book recommendations for fellow word lovers. This episode originally ran in March for the Grammarpaloozians. To get bonus content like this, custom crosswords, and fun tidbits from Mignon, go to Patreon.com/GrammarGirl.

"Dictionary of American Regional English" (DARE)

Support DARE by visiting the University of Wisconsin's giving page.

🔗 Join the Grammar Girl Patreon.

🔗 Share your familect recording in Speakpipe or by leaving a voicemail at 833-214-GIRL (833-214-4475)

🔗 Watch my LinkedIn Learning writing courses.

🔗 Subscribe to the newsletter.

🔗 Find an edited transcript.

🔗 Get Grammar Girl books.

| HOST: Mignon Fogarty

| Grammar Girl is part of the Quick and Dirty Tips podcast network.

• Audio Engineer: Dan Feierabend
• Director of Podcast: Holly Hutchings
• Advertising Operations Specialist: Morgan Christianson
• Marketing and Video: Nat Hoopes, Rebekah Sebastian
• Podcast Associate: Maram Elnagheeb

| Theme music by Catherine Rannus.

| Grammar Girl Social Media: YouTube. TikTok. Facebook. Threads. Instagram. LinkedIn. Mastodon. Bluesky.

Hosted on Acast. See acast.com/privacy for more information.

Introduction

I hope you have already found Auditing and Telemetry for the Agent Governance Toolkit - Getting Started with .NET Core. This article demonstrates how you can leverage the Agent Governance Toolkit practically.

This time, I'll take it a step further and combine the Microsoft Agent Framework Harness with AGT. The example is a file-access agent that operates on a local working directory.

As soon as you let an agent touch files, a familiar set of requirements shows up:

• Listing, reading, and searching files should be allowed
• Creating, deleting, and overwriting files should not be
• That decision shouldn't be left entirely to the agent's prompt
• Blocked tool calls need to show up in an audit log

This is exactly the kind of split where Harness answers "what can the agent do" and AGT answers "should this particular call be allowed."

The sample referenced throughout this post is here:

https://github.com/normalian/MyAGTSamples/tree/main/AGTPolicywithMAFApp03

Dividing responsibility between Harness and AGT

Let's start by separating the two components' jobs.

Harness is what shapes an agent's capabilities. In the sample, AsHarnessAgent() is given a FileSystemAgentFileStore, which exposes tools like file_access_ls, file_access_read, and file_access_grep to the agent.

But just because Harness exposes a tool doesn't mean every call to it should execute. Applying AGT's .WithGovernance() afterward inserts a governance check into the pipeline right before the agent actually invokes a tool.

In other words, it's not enough to tell the model "please don't delete anything" in the prompt — you can deny the delete tool at the execution layer even if the agent calls it.

A closer look at the Microsoft Agent Framework Harness

Before going further, it's worth understanding what Harness itself actually does.

Microsoft.Agents.AI.Harness isn't just a package that bolts on some file-operation tools. It's an extension that assembles, as a ready-made pipeline, the pieces that long-running, repeatedly-tool-calling agents tend to need.

A plain Agent Framework AIAgent already lets you configure tools, conversation history, the execution loop, and context management individually. But if every application has to reimplement the following on its own, the code gets complicated fast:

• The loop that executes function calls returned by the model and feeds results back
• Persisting conversation history that includes tool execution
• Compacting context that grows during long-running tasks
• Auxiliary capabilities like todos, file access, and sub-agents
• An approval flow before a tool actually executes

Harness wires these long-task building blocks together, taking you from an IChatClient all the way to an AIAgent.

What's assembled inside HarnessAgent

The reference material describes Harness's core as three layers:

Instead of wiring these together by hand, you call a single extension method:

Given an IChatClient, AsHarnessAgent() is the entry point for building a HarnessAgent designed for long-running tasks. In this sample, that call also takes a FileSystemAgentFileStore plus several additional options.

Microsoft.Agents.AI.Harness and the related AIContextProvider were experimental at the time this reference material was written. API shapes, tool names, and package versions may change, so check the official docs and release notes for the version you're using.

Compacting the context window

In a long-running agent, user instructions, model responses, function calls, and function results all accumulate in history. As that history approaches the model's context limit, there's no room left for new tool calls or results.

Harness computes an input budget from maxContextWindowTokens and maxOutputTokens:

Conceptually, the input budget available for conversation history and tool results is whatever's left of the model's context limit after reserving room for the next response. As history grows, Harness's compaction mechanism compresses older history while trying to preserve what later reasoning still needs.

That removes a lot of the code you'd otherwise write to manually truncate messages or summarize old tool results yourself. That said, compaction isn't "preserve everything perfectly" — if there's state you can't afford to lose, it's worth saving it explicitly through structured mechanisms like todos or file-based memory.

Sample project layout

Here's the shape of the sample:

working is the file store the agent operates against. The project file copies both the policy and this directory into the build output:

Paths are built relative to AppContext.BaseDirectory at runtime, so the sample doesn't depend on the current working directory.

Environment and packages

The sample targets .NET 10. Main packages (versions as of when the sample was written):

Set the Azure OpenAI endpoint and sign in with the Azure CLI:

On Windows PowerShell:

Because the sample uses AzureCliCredential, there's no key to embed in the application.

Controlling file operations with policy

policies/default.yaml allows the read-oriented tools and denies the mutating ones:

The important part here is the combination of default_action and priority.

Because this sample uses default_action: allow, any tool not covered by a rule is allowed by default. Mutating tools then get a higher-priority deny. Since ConflictStrategy.DenyOverrides is also configured, a deny wins whenever an allow and a deny conflict.

For a stricter whitelist approach, switch to default_action: deny and explicitly allow only the tools you need. In production, that's worth considering — a whitelist means a newly added tool (from a Harness version bump, for example) doesn't get executed by accident.

Note that tool_name is the function name Harness exposes. file_access_read and file_access_Read are different names, so the strings in your policy need to match the actual tool names exactly.

Wiring AGT into the Harness agent

The core of Program.cs:

What AsHarnessAgent() provides

Configuring AsHarnessAgent() with a FileSystemAgentFileStore gives the agent access to the file-operation tools.

This sample turns off everything else Harness offers:

That's just to keep the demo focused on file access. In a real application, enable only the capabilities you need, and write a policy for each corresponding tool — the more capabilities you turn on, the more surface area your policy and audit log need to cover.

FileAccessProviderOptions vs. AGT

DisableReadOnlyToolApproval and DisableWriteToolApproval control Harness's own approval flow. Turning them off does not disable AGT's policy evaluation.

Harness answers "how is the tool exposed," AGT answers "should this call to it execute." An approval UI or human-in-the-loop check and a policy-enforced deny aren't alternatives to each other — they're two separate layers of defense you can combine.

.WithGovernance() is the boundary

This is the part that actually joins the two together:

With EnableFunctionMiddleware = true, AGT intercepts the agent's function calls. Even if the model's reasoning concludes "write this file," the policy is consulted before the tool actually runs — and if that's a deny, it doesn't run.

BlockedToolResultFactory lets the application control what gets returned to the agent on a deny — useful for surfacing a user-facing explanation or attaching an audit ID.

Two agent IDs, on purpose

The sample deliberately uses two different identifiers.

This is the Harness / Agent Framework side's agent name.

This is the identifier AGT uses for policy evaluation and audit events.

They don't need to match. In fact, keeping the framework-level display name separate from a stable governance/audit ID means you can rename the display name without losing continuity in your audit trail. If you're running multiple agents, it's worth deciding on a unique ID scheme up front that accounts for tenant and environment.

Running it

The sample walks through read, write, and delete in sequence:

Run it with:

Expected results:

On a denial, BlockedToolResultFactory returns something like:

What matters isn't just that the agent gets an explanation — it's that the denied tool never actually executes. Even if a prompt injection or similar attack changes the agent's instructions mid-conversation, the write/delete boundary stays enforced at the execution layer as long as the policy is in place.

Using governance events for auditing

The sample writes every event to the console:

That's fine for local development, but in production you'd want to send these to Application Insights or OpenTelemetry. At minimum, it's worth capturing:

• Agent ID
• Tool name
• The policy that applied
• The allow/deny outcome
• The reason for denial
• A correlation ID for the originating request

Also design your logging so file contents and other sensitive arguments aren't written verbatim — separate what you need for auditing from data you shouldn't be persisting at all.

Choosing between default_action: allow and deny

The sample uses default_action: allow to keep the walkthrough simple: allow everything Harness's read/write/delete/replace tools expose, and deny only the dangerous ones explicitly.

In a real deployment, though, the two modes serve different purposes:

Deny-list approach

Broadly permissive, with specific dangerous operations explicitly blocked. Easy to adopt, but a newly introduced tool could end up allowed by default.

Allow-list approach

Every permitted tool has to be listed explicitly. More setup up front, but unknown tools fail safe.

If the agent is going to operate against production data, default_action: deny is the safer baseline — start from nothing allowed and grant read access (with path conditions) incrementally. Combine that with per-agent IDs, per-environment policies, rate limiting, and circuit breakers for a stronger boundary overall.

Why this combination is worth it

Pairing Harness with AGT gives you four main benefits:

1. Capability and permission are separated. You can change what's executable through YAML policy alone, without touching the Harness configuration.
2. Denial happens at the execution layer, not the prompt. Deny rules apply at the tool-call boundary regardless of how the agent's instructions or conversation history change.
3. Decisions are auditable. Which agent, which tool call, which rule it matched, and why it was denied — all available as events.
4. Approval flows and enforced policy can coexist. Use Harness's approval features for UX, and AGT as the safety boundary that can't be crossed.

None of this is specific to file access. The same pattern applies anywhere an agent is delegated a hard-to-reverse action — database writes, external API calls, closing a ticket, sending an email.

Summary

This sample built a read-only file-access agent through the following steps:

1. Expose file-operation tools through Harness's FileAccessProvider
2. Allow reads and deny write/delete/replace in AGT's YAML policy
3. Insert the policy check into tool calls via .WithGovernance() and function middleware
4. Use governance events and blocked-call results for auditing and user-facing feedback

Harness gives an agent capability; the Agent Governance Toolkit draws the boundary around that capability. Getting an AI agent closer to production isn't just about adding useful tools — it's equally about being able to control, from outside the agent's own code, when, by whom, and under what conditions each tool can actually run.

Sample code for this post:

https://github.com/normalian/MyAGTSamples/tree/main/AGTPolicywithMAFApp03

References

• Previous post — Putting a "gatekeeper" in front of an AI agent
• MyAGTSamples — AGTPolicywithMAFApp03
• Microsoft Agent Governance Toolkit
• Microsoft Agent Framework
• Tutorial 43 — .NET MAF Hook Integration

There are a lot of ways to build with AI right now: chat frontends, copilots, greenfield agent apps, orchestration frameworks. All of them have their place, and some customers are building entirely new applications this way. But across customer engagements, a consistent pattern has emerged: the most successful and most cost-effective AI projects are not rewrites. They are existing, deterministic, event-driven business workflows (queue processing, message handling, scheduled jobs) with AI added at exactly the one step that was never deterministic to begin with. This enables the parts that are battle hardened to remain as before, adding AI where non-deterministic smarts are needed. This creates a more robust application along with spending costs for tokens only where beneficial.

That pattern has a natural home in Azure Function and Serverless Agents runtime now support non-Http triggers.

This post walks through the pattern in three layers: the app you already have, what it takes to add AI processing onto it yourself, and what it looks like with Serverless Agents. Learn and try it here: Build serverless agents using Azure Functions | Microsoft Learn

The scenario: expense processing

Picture an expense approval pipeline. Expense and purchase-order requests arrive as messages on a queue: some as quick notes, some as forwarded emails, some as key-value text or JSON from intake tools. Most of the piping around the decision is deterministic and should stay that way: queueing, retries, policy storage, output queues, identity, and the audit trail. You do not want a language model reimplementing any of that.

But one step in the middle has always resisted automation: understanding the request, choosing the policy that governs it, and applying a natural-language rulebook. "Booked a $450 round-trip flight to Denver for the customer onsite next week. — Albert" Turning that into a structured decision (amount, currency, vendor, category, policy applied, destination queue, reason) is exactly the kind of fuzzy, judgment-shaped work that used to mean either a human in the loop or a brittle pile of regexes and keyword lists.

That one step is the AI part of the equation. Everything else stays as code.

Layer 1: the app you already have

If you're running message-based workloads on Azure Functions today, your expense processor looks something like this, using the standard Python v2 programming model with a queue trigger:

This is good architecture, and nothing in this post asks you to change it. You get scale-out per message, retries with a poison queue after repeated failures, and scale to zero between messages. On the Flex Consumption plan you pay for execution, not for idle. The queue itself is doing real architectural work: it buffers spikes, absorbs backpressure, and decouples producers from processing.

The limitation is only that process_expense can read only the schema for which it was written. Free text, email-shaped messages, and inconsistent key-value input require a parser before the deterministic policy code can use them, and selecting among category-specific policy documents means encoding more rules in code.

Layer 2: the do-it-yourself middle step

The obvious next move is to call a model from inside the function. The first version is deceptively short:

The problem isn't the first version. It's everything the first version turns into. Model SDK and auth wiring. Prompt templates living in Python strings. Retry and backoff logic for rate limits, on top of the queue's own retry semantics. Output parsing and re-prompting when the model returns almost-JSON. Then the requests start arriving: "can it look up the current policy documents?" (now you are building tool-calling), "can it run a calculation?" (now you need somewhere safe to execute generated code), "why did it say that?" (now you are building telemetry for model and tool activity). None of this is your expense pipeline. All of it becomes your code to own, patch, and secure.

This is the middle step where a lot of AI-in-the-workflow projects stall, not because the idea was wrong, but because the glue outgrew the feature.

Layer 3: the same trigger, with the Serverless Agents runtime

The Serverless Agents runtime, collapses that middle layer. An agent is a markdown file, with instructions in the body and the trigger in YAML front matter, and it runs on the same Azure Functions triggers you already use. Here is the complete agent from the expense processor sample, expense_processor.agent.md:

Note what the front matter is: the same queue_trigger configuration you would pass to the Functions decorator: queue name, connection setting, and string data type. If you know Azure Functions triggers, you already know how to trigger an agent.

The entire function_app.py is bootstrap:

And app-wide defaults live in agents.config.yaml:

When a message lands on expense-requests, the runtime invokes the agent once for that one item. The trigger's data_type: string and the host's messageEncoding: "none" keep the raw text human-readable, while the runtime serializes the queue message body and metadata before adding them to the agent prompt. The agent's instructions do fuzzy work; the results show up in your Function App logs and Application Insights like any other execution.

For the expense scenario, the pattern points directly at the intake queue: the agent extracts the amount, currency, vendor, category, and expense ID; calls list_expense_policies and get_expense_policy to choose and read the current policy from Blob Storage; applies the rules; and calls route_expense_decision to send the result to expense-approved, expense-review, or expense-flagged. Queueing, policy storage, identity, and routing stay deterministic; the agent gets responsibility for the part that needs judgment.

What changed between layer 2 and layer 3

The economics follow from the architecture. On Flex Consumption, the app scales to zero between messages, so you pay when expense requests arrive, and the AI spend is confined to the single step that needs a model, instead of being architected into every request the way a chat-first design tends to force. This is a large part of why the augment-don't-rewrite engagements are the cost-effective ones: the deterministic 90% of the workload keeps running at deterministic-workload prices.

Use all Event Driven triggers

Queue Trigger is one row in a much longer table. The runtime supports the breadth of the Functions trigger model in .agent.md front matter: Service Bus queues and topics, Event Hubs, Event Grid, Blob Storage, Cosmos DB, Azure SQL, Kafka, timers, Dapr bindings, and connector triggers, alongside HTTP

when you do want a chat endpoint. Wherever your events are already flowing, an agent can meet them there.

Try it

The sample deploys with the Azure Developer CLI:

Then send one of the bundled requests to the provisioned expense-requests queue and read the decision queues:

The travel request is a $450 flight. Swap samples/travel.txt for samples/client-dinner.txt or samples/equipment.txt to see the same amount, select a different policy and route differently. The sample's README also covers running locally with Azurite and Core Tools.

We are working on many more features to make it really easy for you to take your existing apps and make them intelligent, including Hybrid AI apps (your code + AI markdown binding), dynamic workflows and so on.