GitHub's August release cycle shipped something genuinely useful: Agent Apps, which bring Amplitude, Endor Labs, LaunchDarkly, and PagerDuty directly into GitHub workflows. Feature flag status, security vulnerability scans, incident alerts, and usage data — all accessible inside the PR without opening another tab. The stated goal is reducing context-switching. That goal is partially correct, and the part it misses explains why developer burnout numbers haven't responded to several years of tool integration work.
Not all context-switching is the same. The distinction matters more than most tooling discussions acknowledge.
Two Categories of Tool Switch
There are tool switches that take 45 seconds. You leave the PR, open LaunchDarkly, confirm the flag is enabled for the deployment target, close the tab, return to the review. The answer is confirmatory. You were looking for a specific piece of information to make a decision, you got it, you moved on.
There are tool switches that take 45 minutes. PagerDuty surfaces an incident on the service you just merged to. You're no longer in code-review mode. You're in incident-management mode. The next hour involves runbooks, Slack threads, production logs, and a postmortem draft. Whether you access PagerDuty from a dedicated tab or a GitHub sidebar makes no difference to any of that.
Call these lookups and mode shifts. Lookups are quick, read-only, confirmatory. You're asking a question about state. Mode shifts are extended, action-requiring, cognitively realigning. You're switching from one kind of work to a fundamentally different kind.
Agent Apps are an excellent solution for lookups. They have no leverage on mode shifts.
The Fragmented Toolchain Data
The Harness State of DevOps Modernization report, published earlier this year and surveying 700 engineering practitioners, found that 83% of developers who use AI coding tools very frequently complain of fragmented delivery toolchains. Seventy percent say constant tool-switching significantly or somewhat contributes to burnout, rising to 78% among the most frequent AI users.
Those numbers are real. But the word "tool-switching" is carrying weight that it cannot support analytically. A developer who makes thirty quick lookups to Amplitude and LaunchDarkly over a day — each one under two minutes — reads as fragmented in any metric that counts tool switches. A developer who makes two tool switches but one of them is a three-hour production incident reads as highly focused. The metric doesn't distinguish the two patterns. Neither does the burnout stat.
The burnout is not coming from the thirty lookups. Lookups are interruptive, and high-frequency interruptions add up, but the cognitive cost is different in kind from what happens when you exit coding mode and enter incident management mode. That exit costs working memory: you have to unload whatever you were holding about the codebase, load a different mental model about the production environment and what might be wrong, work through the problem, and eventually reload the codebase context when you return. That reloading is the expensive part. It doesn't happen after a lookup.
What Agent Apps Actually Fix
The case for lookup integration is strong. In the flow of code review, there are several questions that gate decisions: Is the relevant feature flag configured correctly for this deployment? Does this diff introduce known vulnerabilities? Is there an active incident that would make merging risky right now?
Each of these is a lookup. The answer is either fine or not-fine. Getting the answer without leaving the PR eliminates the tab-open, wait-for-load, find-the-relevant-field, close-tab cycle. At 90 seconds per lookup and thirty lookups per day, that's 45 minutes. With Agent Apps at 15 seconds per lookup, it's 7.5 minutes. That is a real and worthwhile improvement. The interruption still happens — you're redirecting attention to a different information source — but the duration is short enough that working memory doesn't have to reset.
Agent Apps from Endor Labs and LaunchDarkly fit this model cleanly. Security scans and flag status are confirmatory lookups. The information is either acceptable or it isn't, and you return to the PR either way.
Amplitude is more complicated. Simple deployment-outcome queries — did the change I just shipped move this metric? — are lookups. Investigating an unexpected pattern in Amplitude is a mode shift. The same tool generates both patterns. Whether the Agent App helps depends on which pattern dominates your actual usage.
PagerDuty is the clearest case where the integration's value is limited. A PagerDuty alert inside GitHub doesn't make you spend less time managing the incident. It makes it slightly faster to discover that you need to spend time managing the incident. That is not the same thing.
Where Burnout Actually Comes From
The Harness data found that 70% of developers attribute burnout to tool-switching. The deeper question is what proportion of that is lookup friction versus mode-shift frequency. Those require different interventions.
Lookup friction is an interface problem. Tools embedded in context, fast search, in-context documentation. These make individual lookups cheaper. Agent Apps address this directly.
Mode-shift frequency is a workflow design problem. How often during a given week is a developer pulled from focused coding or review into an entirely different cognitive frame — incident management, synchronous unscheduled communication, cross-team alignment, extended debugging of production behavior? Reducing this frequency requires runbooks that reduce investigation time, automated triage that prevents some incidents from requiring human response, on-call rotations that distribute the interrupt load, and protected focus blocks that establish norms around when it is and is not appropriate to pull someone into synchronous mode.
None of those are fixed by where PagerDuty renders.
There is a version of the Agent Apps rollout where teams deploy it, count "tool switches" before and after, see a reduction, and conclude the burnout problem is improving. The lookup count goes down. The mode-shift frequency stays identical. Burnout stays identical. The metric gave a false positive.
Measuring the Difference
The distinction between lookup and mode shift shows up clearly in session-level data. A tool that appears in your app history as many 30-60 second sessions is a lookup tool for you. A tool that appears as one 60-minute block is a mode-shift tool. The same product can generate both patterns — the same developer might do twenty quick LaunchDarkly checks and one deep experimentation-analysis session on a given day.
Knowing which pattern dominates changes the expected value of an Agent App integration. If your LaunchDarkly usage is primarily quick flag-status confirmation, the integration should meaningfully reduce the interruption cost of those checks. If it's primarily deep experimentation analysis, the integration doesn't change what you're spending time on.
This is knowable. App-level session tracking shows duration distributions. If the median LaunchDarkly session is 45 seconds, you're in lookup territory, and the integration is worth deploying. If the median is 18 minutes, you have a different kind of LaunchDarkly dependency that Agent Apps won't address.
At xeve, the session data consistently shows this pattern: the same tool generates very different duration profiles depending on the developer and the context. Senior engineers doing deployment verification use monitoring tools for quick lookups. Engineers doing root-cause analysis on production regressions use the same tools for extended mode-shift sessions. Giving both groups the same "reduce tool-switching" solution is treating different problems as identical.
What This Means for the Agent Apps Rollout
Deploy them. The lookup case is real and the improvement in lookup cost is measurable. Endor Labs and LaunchDarkly integrations are particularly clean — the queries are confirmatory, the answers are brief, and keeping them in-context genuinely reduces interruption cost.
But don't evaluate the deployment against burnout metrics if you haven't first separated your lookup-pattern tool use from your mode-shift tool use. Those are different problems. The Agent Apps will move the lookup number. If burnout is driven by mode-shift frequency in your team — which it usually is — the burnout number won't move.
The tooling improved. The interventions that reduce mode-shift frequency look less like better software and more like different team norms: clearer escalation paths, protected focus windows, async-first communication for everything that doesn't require synchronous resolution, and explicit agreements about when it's appropriate to interrupt someone's working session. Those changes are harder than installing a plugin. They're also the ones that actually move the burnout number.