Agentic DevOps with GitHub Actions and Microsoft Foundry

As AI agents become a bigger part of the conversation around software development, I started thinking about what they could mean for my own role as a DevOps engineer. Where could they help in a delivery pipeline? What decisions could they support? And where would I still want myself or someone else to firmly be in control?

For sure we know DevOps already involves a great deal of automation. We build pipelines to test code, check for problems, and move changes between environments. But deciding whether a release should proceed requires context. Passing tests are useful evidence; but they do not answer every question about the risk of a change.

That made release review an interesting place to experiment. Could an agent help explain the evidence, highlight concerns, and prepare better questions for the person approving a deployment? I mean I already interact with agents like they are colleagues and it's been real so far.

I built a small proof of concept with GitHub Actions and Microsoft Foundry to explore that question. I wanted to understand the moving parts for myself, how evidence reaches a reviewer, how a recommendation affects the workflow, and how approval remains under human control.

This article shares that experiment with other DevOps and platform engineers asking similar questions about their roles. It walks through what I built, what it demonstrates, and what would still need to change before using the approach in production.

The implementation has two parts. GitHub Actions runs a deterministic release review and demonstrates an environment approval gate. Separately, a Microsoft Foundry agent reviews the same sample evidence in the playground. The workflow does not yet call Foundry, and its staging and production jobs simulate deployment.

That boundary matters. This is a practical foundation for an agent-assisted release process, with a clear path to integration.

Repository: balop3e/agentic-devops-poc

What this proof of concept demonstrates

The question I wanted to explore was straightforward, how can an AI recommendation fit into a release process without becoming the authority that approves production?

The actual unit tests run before evidence generation. However, the release evidence uses preset low-risk and high-risk scenarios. Its test counts, coverage changes, and vulnerability counts are predefined inputs for exercising the review logic.

How the components connect

Figure 1. The implemented workflow and the separate Foundry experiment. The AI response does not feed back into the workflow in this version.

A push to main or a manual workflow run starts the build and test job. When that job succeeds, the workflow generates a JSON evidence file and stores it as an artifact. The review job reads that artifact and publishes a Markdown report.

The staging simulation runs when the review exposes a proceed decision. The production simulation additionally requires a manual run with deploy_production=true, successful staging, and satisfaction of the production environment's protection rules.

Alongside this flow, I pasted the evidence into Foundry to explore the quality of an AI-generated explanation. This kept the workflow demonstration repeatable while letting me inspect the model's response separately.

Start with structured release evidence

An AI reviewer needs a defined input. Asking whether a release is safe without supplying evidence encourages assumptions.

The demo uses fields for the commit, workflow run, target environment, tests, change size, coverage, vulnerabilities, database migrations, and dependency changes. Here is an illustrative low-risk input, with placeholder identifiers:

{
  "commit_sha": "example-commit",
  "workflow_run": "example-run",
  "deployment_target": "production",
  "total_tests": 24,
  "failed_tests": 0,
  "changed_files": 6,
  "coverage_delta": -1.1,
  "high_vulnerabilities": 0,
  "critical_vulnerabilities": 0,
  "database_migration": false,
  "external_dependency_change": false
}

Note that these numbers are sample data, not measured results. The schema defines coverage_delta as a percentage-point change, a fall from 80% to 78.9% is a change of -1.1 percentage points. The original demo report displays a percent sign, which is less precise.

In a real pipeline, I would populate these fields from the test runner, coverage report, vulnerability scanners, and deployment metadata. I would also include evidence timestamps and an artifact digest so the review can be tied to the exact release candidate.

The repository includes schemas/release-evidence.schema.json. Having that file does not enforce the contract automatically, the current review script loads JSON into a Python dataclass without invoking a JSON Schema validator. Runtime schema validation and consistency checks, such as ensuring failed tests cannot exceed total tests, are next steps.

Separate policy from explanation

The Python review applies fixed scoring rules. Failed tests or critical vulnerabilities produce a block recommendation regardless of the final risk label. Other signals add points, including high-severity findings, larger changes, coverage drops, migrations, and dependency changes.

The low-risk fixture produces proceed, a low risk level, and a score of zero. These are outputs of an illustrative scoring model. A zero score is not a guarantee that a release is safe, and the score is not a probability of failure.

One implementation detail deserves attention, assess_release() can return proceed_with_extra_review, but write_github_output() maps every non-blocking recommendation to proceed. The production approval gate still applies, but the workflow does not enforce a separate extra-review process for that middle state.

Before extending this pattern, I would preserve that state explicitly and define the additional review it requires. More generally, policy should make mandatory decisions in code; the model should explain the evidence and surface questions.

Put approval in the deployment platform

Writing “human approval required” in a prompt or report does not enforce approval. The relevant control in this demo is the GitHub environment configuration.

The workflow's production job references production. A required-reviewer rule configured on that environment makes the job wait. The following simplified excerpt illustrates that relationship; it is not a complete workflow:

deploy_production:
  runs-on: ubuntu-latest
  needs: [agent_review, deploy_staging]
  if: >-
    github.event_name == 'workflow_dispatch' &&
    github.event.inputs.deploy_production == 'true' &&
    needs.agent_review.outputs.decision == 'proceed'
  environment:
    name: production
  steps:
    - name: Simulate deployment
      run: echo "Protected job released to run."

The YAML reference alone does not create a reviewer requirement. I still need to configure the environment protection rule separately. For independent review, I enabled prevention of self-review and select another eligible reviewer. Also review administrator bypass settings and restrict permitted deployment branches or tags. GitHub's current documentation says required reviewers on Free, Pro, and Team plans are available only for public repositories. See deployment protection rules.

Figure 2. The production simulation waits for environment review after the deterministic review and staging simulation finish.

As you can see in the demonstration, the workflow waited at this gate and then completed after approval. This shows the gate operating in that run, but does not establish independent approval by a second person or prove that bypass was disabled. A printed log message saying a human approved is not, by itself, evidence that a gate was enforced.

For a production implementation, protect workflow changes and deployment credentials too. A job that omits the protected environment must not have another route to the same production permissions.

Azure Pipelines supports a related pattern through approvals and checks on resources such as environments. That offers another way to keep the approval control outside the AI response.

Explore the AI reviewer in Microsoft Foundry

The Foundry portion gives the reviewer a specific job, interpret the supplied release evidence and prepare useful context for an approver.

The main concepts are a Foundry resource, a project, a model deployment, and an agent. The resource provides the service boundary; the project organises the work; the model deployment supplies inference; and the agent adds instructions and, when configured, tools. The playground provides an interactive place to test the behaviour. Microsoft describes the platform in its Foundry overview.

For this experiment I used gpt-4o-mini and an agent called devops-release-review-agent. That records the demo configuration, rather than recommending a particular model for every release process.

The instructions asked for a risk level, recommendation, reasons, questions for the human reviewer, and a concise approval summary. They also told the agent not to claim production was approved and to recommend blocking when tests failed or critical vulnerabilities were present.

Figure 3. The Foundry agent reviews evidence pasted into the playground. This is separate from the GitHub Actions execution.

For the supplied low-risk evidence, the response recommended proceeding and raised questions for the approver. This is a useful example of explanation, but one favourable response does not establish reliability. The experiment does not demonstrate autonomous remediation, deployment tools, or a multi-agent system.

Prompts describe intended behaviour, they are not access controls. A release-review agent should have no permission to approve its own deployment or alter the approval configuration.

Understand the permissions before connecting the pipeline

During setup, I encountered an important distinction between managing an Azure resource and using the AI service inside it.

The Azure control plane covers management tasks such as creating resources and assigning roles. The data plane covers service operations such as invoking models and working with agents. Subscription Owner does not itself grant all Foundry data-plane permissions, portal setup can add separate role assignments.

Check the specific operations and scope your identity needs in the Foundry RBAC documentation. Current documentation uses names such as Foundry User and Foundry Agent Consumer, older interfaces may still show Azure AI role names. An identity that only invokes an agent should not receive broad management privileges unnecessarily.

For a future GitHub-to-Foundry integration, I would use OpenID Connect with Azure and Microsoft Entra workload identity federation instead of a stored long-lived client secret. The workflow needs id-token: write to request an OIDC token, Azure role assignments determine what the resulting identity can do. Its trust configuration must match the intended repository and workflow context.

The agent-review identity and production deployment identity should have separate responsibilities and permissions.

Reuse the pattern across teams

The repository contains a reusable review workflow and a Team Scaling Demo caller. Two illustrative teams invoke the same implementation with different evidence profiles:

Figure 4. Team-specific jobs reuse the same review implementation within the demo repository.

A successful review job means the analysis completed. It does not necessarily mean deployment is permitted the script can successfully produce a block decision. A caller must consume that output in its deployment conditions. The scaling demonstration itself has no deployment jobs.

This shows reuse within one repository. Extending it to separate repositories needs additional work. In particular, actions/checkout inside a called workflow normally checks out the caller's repository. The shared review code must be distributed deliberately, for example as a versioned action or package, rather than assuming its scripts exist in every caller. GitHub documents the execution context in reusing workflows.

I would make the platform team responsible for the evidence contract, review implementation, prompt versions, and evaluation cases. Product teams would supply release evidence and retain ownership of their deployment and approval configuration.

What I would add before production use

The next iteration should address several concrete gaps:

1. Collect and validate real evidence. Parse actual reports, reject missing or inconsistent fields, and bind every review to the commit and deployable artifact.
2. Integrate Foundry explicitly. Call the selected agent API from the review job and validate the response against an output schema. Preserve a clear distinction between deterministic policy and AI advice.
3. Define failure behaviour. A timeout, unavailable model, or malformed response must never silently become an approval. Pause for review or follow a documented fallback policy.
4. Treat release text as untrusted input. Commit messages, pull-request descriptions, and logs can contain instructions aimed at the model. Keep them separate from trusted instructions and prevent the reviewer from changing policy or gaining deployment permissions.
5. Evaluate difficult cases. Include missing evidence, contradictory signals, failed tests, critical vulnerabilities, migrations, and attempts to override instructions. Recheck behaviour when the prompt or model changes.
6. Record decisions and outcomes. Retain evidence, policy results, AI output, prompt and model versions, reviewer decisions, and deployment outcomes. Measure review usefulness, latency, and cost before claiming an improvement.

These are proposed enhancements, not capabilities already demonstrated by this repository.

What I learned

It was very important for me to be able to prove or have a first hand experience on how infusing agents into the process will be. This allows me prepare for governance requirements not only for carrying out my work but also when it comes to making business decisions. The most useful result was a clearer separation of responsibilities. GitHub Actions executes the workflow. Deterministic rules evaluate explicit policy. Foundry can help explain the evidence. Environment protection rules control when the protected job may run.

This PoC demonstrates those pieces without claiming a complete AI-operated delivery platform. Connecting the agent is the next technical step; validating its usefulness and keeping the approval boundary intact are the next engineering responsibilities.

If you are exploring this approach, start with a release decision your team already makes. Define the evidence, make the policy explicit, and then test whether an AI reviewer helps people understand that decision better.

Source code and documentation

• Demo repository
• Main workflow
• Evidence generator
• Release policy
• Review script
• Foundry agent instructions
• Reusable review workflow

Implementation and documentation reviewed on 25 September 2026. Screenshots show the original demonstration; product interfaces and access requirements can change.