Build1 publisher2 min readPublished
A LinkedIn coding agent fetches written debug instructions four times in one latency incident
Ajay Prakash's InfoQ talk walks a pager alert through logs, a downstream service and a buggy pull request. Each hop in that path depends on debugging instructions another team at LinkedIn wrote down.
The Engineer · Build desk
What happened
- Ajay Prakash, a LinkedIn software engineer, described an on-call engineer pasting a latency alert link into a coding agent such as GitHub Copilot, which fetched the company's alert debugging instructions.
- Following per-service instructions, the agent pulled logs, metrics and recent deployments, traced the errors to a downstream service, and fetched that service's debugging instructions as well.
- It wrote a summary naming the root cause and the mitigation steps, then waited for the engineer to confirm and verify before taking the mitigating action.
- The agent also filed a report into the incident management system and opened a pull request against the service carrying the buggy change.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint The agent only reaches the downstream service because another team's debugging steps were written down and current. A stale or missing runbook stops the run at the first hop, whatever the model can do.
- cost Thousands of tool interfaces and 600-plus workflows are a standing maintenance bill, and it lands on the service teams whose internal APIs and runbooks change underneath them.
- exposure The agent mitigates and opens pull requests on a service its operator does not own, and the only checkpoint described is one engineer confirming a summary during an active incident.
- decision Anyone sizing a copy of this has to settle first whether service teams will write and maintain debugging documents for readers outside the team, before any agent tooling is chosen.
Count the instruction fetches in the walkthrough. The agent pulls the company's instructions for debugging alerts [3], then the instructions for the service that paged [4]. Then the instructions for the downstream service throwing errors [5], then the instructions for changing code on that affected service [10]. That is four separate retrievals of something a person wrote [19].
Three of the four happen before anything is mitigated, and one targets a service the on-call team does not own. So the downstream team's debugging steps have to be usable by an agent working for someone else [20]. A fetch only returns something useful if the document exists, matches the current deployment, and sits where the agent can reach it [24].
Prakash attributes the result to the system LinkedIn built. "This is possible because of a system that we built, we are calling it Contextual Agent Playbooks and Tools," he said [13]. He also said the whole sequence runs in a matter of a few minutes, where the same investigation without coding agents would easily have taken a few hours [11].
The talk is titled for an organizational context layer for AI agents with MCP [23]. The published excerpt breaks off in the history section, before the architecture, and it does not quantify the minutes-against-hours comparison [22].
The counts are the firmest evidence on offer: more than 600 workflows and thousands of tools [14]. Take "thousands" at its floor of 2,000 and each workflow averages more than three tools [21].
The few-minutes figure only means something at another company if the things under it hold: a debugging document per alert class and per service, including services your team does not own [5]; telemetry, deployment history and recent changes reachable as callable tools [4]. It also needs an ownership map that tells the agent whose document to fetch next [5], and an on-call engineer who can check a root-cause summary quickly, because confirmation blocks the mitigation step [8].
Prakash traced how the tooling arrived here. Early assistants were LLM-based smart autocomplete over whatever context was open [15]. Agent mode added file edits and terminal commands across a workspace [16], and Andrej Karpathy named the practice vibe coding in early 2025 [17]. LinkedIn handed the coding tools to all its engineers early on [18]. In the incident walkthrough, every decision the agent makes comes off a document a LinkedIn engineer wrote and a tool a LinkedIn engineer exposed [19]. In my view that build order is the part that generalises to other companies, and service teams own most of it.
What to watch
- Whether the rest of Prakash's talk describes how playbooks are versioned and how stale runbooks are detected.
- Whether LinkedIn publishes a figure for how many of the 600-plus workflows are in active use.
- Whether other companies attempting this report the same requirement: runbooks written for readers outside the owning team.