How to bring your software delivery workflow into GitHub with agent apps

Closing the context gap around pull requests

Every pull request carries an invisible cost: the context you must gather before you can confidently review, merge, and ship. A typical change touches product analytics, dependency health, feature flags, and incident history — and each of those lives in a separate tool. The result is a workflow where you shuttle between tabs, re-explaining the same change to different systems.

GitHub agent apps aim to collapse that loop. Built on the same platform and harness as the Copilot cloud agent, they let you pull external services directly into your repository workflow — no tab-switching required. The scenario below walks through a realistic change, from initial scoping to pre-deploy risk check, using agent apps for Amplitude, Endor Labs, LaunchDarkly, and PagerDuty.

Validating the change before writing code

Your product team wants to make the "invite your teammates" step optional in the free-trial onboarding flow. Support reports it as a friction point, but there's no data on whether that friction leads to churn — or whether it only affects certain user types. Before touching any code, you can query the Amplitude agent directly from the Agents tab in your repository:

@amplitude[agent] is completing the team invite step correlated with success later in the funnel? Break it down by segments we're measuring. 

The response shows a clear split: team users who complete the step are more likely to retain, while solo users show no such correlation. The original request is now justified — but only for a segment. You defer the step for solo signups and keep it for teams, and the course correction happens before a single line of code is written.

Proactive dependency checks during development

Copilot opens a draft pull request for the change, and implementation touches dependencies in the onboarding flow. Rather than waiting for a CI scan to fail further down the line, you ask the Endor Labs agent to review the changes in a PR comment:

@endor-labs-github-agenthq[agent] is there anything I need to watch out for in the dependencies being touched by this pull request?

The agent identifies the changed dependencies, checks them for known vulnerabilities and broader package risk, and reports back directly in the pull request. In this case everything comes back clean — but the value is that the check happens while the change is still in front of you, not after a failed pipeline run forces you back into the code.

Feature flag setup from a pull request comment

The implementation now carries through the product decision: solo signups get an optional path, teams keep the original flow. Because user segments are determined at signup, a feature flag can target them directly. You ask the LaunchDarkly agent to set it up, the same way you might ask a teammate:

@launchdarkly-agent[agent] please create a feature flag for this pull request and wire it into the code. 
   - key: defer-team-invite 
   - type: boolean 
   - default: false 
   - target: solo-intent signups 
   - rollout: internal > 5% > 25% > 100% 

The agent creates the flag in LaunchDarkly and adds the code implementation as a commit for you to review. If the target environment requires approval, it creates an approval request instead of applying the targeting change directly — a human still decides whether the rollout proceeds. What used to require a second tool, a manual code handoff, and Slack coordination is now a single comment and one commit review.

Checking deploy risk before merge

Code review confirms the change is correct, but it doesn't answer whether the service is in a healthy state for deployment. Before merging, you ask the PagerDuty agent:

@pagerduty-agent-app[agent] assess the deployment risk for this pull request against the onboarding service. Check active incidents and recent incident history, then recommend whether to proceed. 

The agent maps the repository to its PagerDuty service, checks for active incidents, reviews the prior 90 days, and compares the files in the pull request with areas involved in past incidents. The verdict here is low risk: no active incidents and no meaningful correlation with the current changes. The recommendation is to proceed. Nothing dramatic happens — but that's the point. Deploy-risk checking becomes a routine part of every pull request instead of a last-minute fire drill when a release already feels dangerous.

What actually changes

You still use the same tools — Amplitude, Endor Labs, LaunchDarkly, and PagerDuty — but you no longer carry the context between them. Each service steps into GitHub when its capabilities matter, and the coordination happens where the work already lives. Agents don't replace your toolchain; they make it available within it.

Agent apps are available through the GitHub Marketplace. To try one, install it and enable it for your organization, then use it however fits your flow:

• Assign it to an issue to kick off a task.
• @mention it in a pull request comment for analysis or action.
• Select it from the Agents tab in your repository.

Other inaugural agent apps cover adjacent parts of the workflow: Packfiles reads your backlog and builds migration strategies, Miro connects visual collaboration with code, Bright Security runs end-to-end dynamic security testing, SonarQube brings analysis and quality gates into agent sessions, and Octopus Deploy identifies and diagnoses deployment failures. Browse all agent apps in the GitHub Marketplace.