Case Study · Technology

Let AI prepare the release. A release manager approves the deployment.

Claude drafts release notes, creates a draft release and deploys to staging. Production deployment waits for the release manager’s approval, and Kroy refuses any attempt to skip it.

Example implementation A designed Kroy workflow showing how this can be set up. It is not a customer result.

The workflow

Watch this workflow run through Kroy.

  1. The request.

    “Kroy Artifacts”

  2. Who is asking.

    Kroy identifies the person in engineering and Claude acting for them, within the delegation they gave it.

  3. Only what the task needs.

    Kroy retrieves merged pull requests since the last release (GitHub), check results for the release commit (GitHub) and the team’s release checklist (KroyDB) from GitHub.

  4. Excluded by design.

    Deployment secrets, Repositories outside the release and GitHub tokens never reach Claude. That boundary is Kroy’s, not an instruction to the AI.

  5. The proposed action.

    Permitted: read pull requests (github.pull_request.read), create a draft release (github.release.create) and trigger a staging deployment (github.workflow.dispatch).

  6. What Kroy refuses.

    Refused: deploy to production without approval, edit workflow files (github.workflow.update) and publish the release before production deployment.

  7. A person decides.

    The release manager approves each production deployment.

  8. State changes. Everything is recorded.

    The work is updated in Kroy, and every request — allowed or refused — is written to the audit trail.

Claude
Engineering
Kroy
GitHub
✓ Read pull requests
✕ Deploy to production with…
! Approval
AUDIT · STATE

Retrieved

  • ✓Merged pull requests since the last rel…
  • ✓Check results for the release commit (G…
  • ✓The team’s release checklist (KroyDB)

Excluded

  • ✕Deployment secrets
  • ✕Repositories outside the release
  • ✕GitHub tokens
Claude
Engineering
Kroy
GitHub
✓ Read pull requests
✕ Deploy to production with…
! Approval
AUDIT · STATE

Retrieved

  • ✓Merged pull requests since the last rel…
  • ✓Check results for the release commit (G…
  • ✓The team’s release checklist (KroyDB)

Excluded

  • ✕Deployment secrets
  • ✕Repositories outside the release
  • ✕GitHub tokens

What the AI can and cannot do

Data accessed

  • ✓ Merged pull requests since the last release (GitHub)
  • ✓ Check results for the release commit (GitHub)
  • ✓ The team’s release checklist (KroyDB)

Data excluded

  • ✕ Deployment secrets
  • ✕ Repositories outside the release
  • ✕ GitHub tokens

Actions permitted

  • ✓ Read pull requests (github.pull_request.read)
  • ✓ Create a draft release (github.release.create)
  • ✓ Trigger a staging deployment (github.workflow.dispatch)
  • ✓ Request production approval (approval.request)

Actions refused

  • ✕ Deploy to production without approval
  • ✕ Edit workflow files (github.workflow.update)
  • ✕ Publish the release before production deployment

Human approval required

  • The release manager approves each production deployment

Business situation

A software team at ABC Limited releases every week or two. Someone collects the merged pull requests, writes release notes, checks the build, deploys to staging, then — once satisfied — deploys to production. The team wants AI to do the gathering and preparation, and a person to decide when production changes.

Why existing tools alone are insufficient

An AI with a GitHub token scoped to trigger workflows can trigger any of them, including production. Tying approval to a chat message is not enforcement. And an AI that can edit workflow files can change what “deploy to staging” actually does.

Systems involved

  • GitHub — pull requests, checks, releases and deployment workflows.
  • KroyDB — the release entity and the team’s checklist.
  • Kroy Artifacts — the release notes.

Kroy architecture

Claude connects to Kroy. GitHub is connected to Kroy by the team. The Prepare Release Skill may read pull requests and checks and create a draft release. The Deploy Release Skill may dispatch the staging workflow; dispatching the production workflow requires the release manager’s approval. Workflow files are outside both Skills. Kroy holds the GitHub credentials.

Workflow

  1. A developer asks Claude: “Prepare the next release.”
  2. Kroy returns the merged pull requests since the last tag with github.pull_request.read, and the release commit’s check results.
  3. Claude drafts grouped release notes as an Artifact and creates a draft release with github.release.create.
  4. The developer asks: “Deploy to staging.” Claude requests github.workflow.dispatch for the staging workflow. Kroy permits it.
  5. The developer asks: “Staging looks fine — deploy to production.” Kroy refuses the dispatch and raises approval.request for the release manager, with the notes and check results attached.
  6. The developer asks Claude to change the production workflow so it no longer needs approval. Kroy refuses: github.workflow.update is outside the Skills.
  7. The release manager reviews and approves. Kroy dispatches the production workflow and, once it succeeds, the release is published.

Agent permissions

Claude acts under the developer’s delegation. It can read, draft and deploy to staging. It can request, but not force, a production deployment.

Human permissions

Developers prepare releases and deploy to staging. The release manager approves production deployments.

State changes

  • A release entity is created with its notes and pull request list.
  • The draft release is created in GitHub, then published after production deployment.
  • The release moves through Draft, Staging, Awaiting approval and Released.

Audit outcome

Kroy records each read, the draft release, the staging deployment, the refused production dispatch, the refused workflow edit, the approval and the production deployment.

Security considerations

  • Deployment credentials stay in Kroy; Claude never holds a token.
  • Approval is enforced by Kroy before the dispatch is made.
  • Kroy’s approval sits alongside any environment protection configured in GitHub.

Setup requirements

  • GitHub connected to Kroy.
  • Claude connected to Kroy.
  • The two Skills enabled, with the release manager’s role and approval policy configured.

Try this with your own systems.

Try Kroy with GitHub