Has this ever happened to you? You pick up what looks like a straightforward coding task: update an API, run the tests, open the PR, and move on. Then, a few nights later, you’re paged for an incident tied to that change. The update worked exactly as expected in your service, but it silently broke a dozen downstream consumers you didn’t know existed.

You even asked your coding agent to verify that the change wouldn’t break anything, and it did, within the boundaries of the repository. That’s the problem. A repository can show an agent what an endpoint calls, but it rarely reveals the full dependency graph: who calls that endpoint, which consumers rely on an undocumented field or side effect, whether those consumers are still active in production, where they’re deployed, or which team owns the pager when they fail. The agent reasoned accurately about the systems it could see. It just didn’t have enough operational context to understand the true blast radius.

In this talk, we’ll work through that scenario as an agentic software development lifecycle. We’ll give an agent an API requirement and follow it through implementation, a collection, tests, CI, and monitoring, all in the terminal. You’ll see the agent use task-specific skills to carry out each step, inspect the results, and fix what fails.

Then we’ll change the requirement. Before editing the API, the agent will query a Context Graph to find affected callers and consumers beyond its local checkout. We’ll use those findings to decide what needs to change, update the implementation and its supporting tests and contracts, and check the results again. We’ll also show where an engineer needs to review the evidence and coordinate with the teams that own affected services.

You’ll leave with a real world use case of what an agentic SDLC requires across the whole API lifecycle: instructions that help an agent do the work, checks that expose failures, and enough context to catch consequences outside the repo before they become an incident.