Last week, I gave a talk at GitHub Universe 2026 about context. The question behind it: when a coding agent changes one API, how does it know what else that change breaks?

The demo answers it with two agents building on a healthcare app, each in its own session with no shared memory. Agent A uses the Postman Context Graph to find which services supply the data for a claims-review API, builds a simulation of those dependencies, and publishes it to a Postman workspace. Agent B pulls that simulation, runs the existing tests, and extends the API. The checks go from 10 passing assertions to 14, and Agent B never has to rediscover a dependency.

The part nobody talks about

My talk was called “Agentic SDLC with Context Graph and API Simulations.” The premise: all of us use coding agents to do engineering work, and it’s rare for that work to have no downstream dependencies that also need updating. The agent writes the code, silently breaks a bunch of other things, and you get paged for an incident tied to your change. That’s the part nobody talks about. The agent does the engineering work, but I’m the one keeping track of everything around it: the context, the dependencies, what’s been verified, and what else needs to be updated. The talk was about handing more of that tracking to the agent, using the Postman plugin.

The endpoint is the fast part

An agent can write an endpoint quickly. The work around the endpoint is what takes longer. I framed it with four items:

What takes longer	What it means for an agent
Contract	Understanding what the API promises
Dependencies	Finding every service the change touches
Tests	Checking the behavior, not only whether it compiles
Handoff	Leaving the next person or agent a setup they can use

The Postman plugin gives an agent skills for API engineering. Each skill holds instructions the agent can read for a task: which tools to use, which files to work with, and how to check the result. The full plugin covers development, testing, documentation, CI, and monitoring, so it reaches every phase of the SDLC. For this talk I picked two skills:

• api-discovery, which includes the Context Graph, helps the agent understand the APIs and relationships involved.
• api-simulation gives the agent an environment where it can develop against those dependencies.

Then I added a constraint to make the demo honest: two agents working on consecutive tasks, in separate sessions, with a Postman workspace as the only thing carrying work between them.

A librarian, a catalog, and a lot of shelves

To explain why the Context Graph comes first, I used a library.

Imagine you walk in and ask the librarian to find everything about chess. There’s no computer catalog, so the only way to answer is on foot. The librarian walks the building, searches every shelf, and inspects individual books. A more experienced librarian might do that faster and notice more, but they’re still searching the entire building from scratch.

Now give the librarian the catalog. Instead of starting at the first shelf and working aisle by aisle, book by book, page by page, they search once and get a list of relevant books with exact shelf locations. The catalog tells them where to begin, which books to pull, and which sections deserve a closer look. It can also point to a chapter inside a book with an unrelated title, a book stored at another location, or a resource that isn’t on a physical shelf at all, like an audiobook. The librarian then opens the books and verifies they contain what you need.

In the analogy	In the agent workflow
The librarian	The model
The shelves	The checked-out repositories
The catalog	The Context Graph

The Context Graph tells the model which services, APIs, endpoints, and relationships are likely to matter and where to focus its search. Instead of exploring hundreds of repositories one by one and burning countless tokens, the model starts with a specific set of candidates and verifies those leads in the code wherever it can. Postman’s own writing on why AI coding agents need context graphs makes the same argument with more depth.

The analogy also answers the question I get most about model quality. A better model is a faster, more experienced librarian. It searches the shelves more efficiently, but it still can’t find something that isn’t on those shelves. The Context Graph gives the agent a starting point: which APIs are relevant to the task, where to find them, and which relationships to verify.

Develop against dependencies you can’t run

Knowing where an API lives doesn’t mean its service is available to run on your laptop. That’s the gap api-simulation fills.

Say my service calls four other APIs. To develop it locally, I need to exercise those calls, including their responses and failures, without bringing up all four real services. A Postman simulation groups the dependency mocks into one runnable setup. Each mock represents an API, and the simulation defines how to reach them together. My real service runs locally and sends its dependency calls to that setup, and I can add delays, errors, and rate limits to see how the service behaves when a dependency has a bad day.

Then comes the handoff. I save the requests and assertions as a Postman Collection and publish the simulation and the collection to a workspace. Another agent can retrieve both, start the same dependency setup, and rerun the existing checks before it changes anything.

The demo: two agents, one workspace

The demo used a hospital app, myhealthcare.dev, with services that manage patients and billing. The goal was to add an insurance service so a user can view claims and approve or deny them. I split the work between two agents and drew the whole thing on a whiteboard first.

The whiteboard sketch from the talk. Claim data is spread across services, so Agent A has to find out which ones supply it.

Agent A builds the API for viewing claims. Each claim needs an insurance ID, a patient’s name, and a billing amount, and that information lives in different services. The patient’s name comes from the patient service. Agent A asks the Context Graph where to get each piece and which dependencies it needs.

Here’s the start of the prompt I gave it:

You can watch the whole run in the recording below.

The demo from my GitHub Universe session: two agents in separate sessions, a Context Graph query, a shared simulation, and a Postman workspace in the middle.

Here’s what happens in the video:

1. Agent A uses the api-discovery skill to ask the Context Graph which services supply the claim and patient data, and how billing connects to the decision.
2. It uses api-simulation to simulate those dependencies locally, so it can build and test without running every service on my machine. The Postman skills guide it through creating a collection and adding tests.
3. All 10 assertions pass, and all four dependencies take traffic. Agent A publishes the simulation and the collection to a shared Postman workspace.
4. I switch to Agent B in a separate session. It has no memory of Agent A’s work, so it pulls the shared assets from Postman and runs the existing tests before making any changes.
5. Agent B’s task is an endpoint that lists claims by payer. It checks the Context Graph for the relevant APIs, then develops against the simulation Agent A already created.
6. Agent B adds tests for the new endpoint and reruns the collection. There are now 14 passing assertions, and it pushes the updated assets back to the workspace.

In the original plan on the whiteboard, Agent B approves or denies claims and has to tell billing about each decision. The recorded run uses a smaller task, but the principle holds: Agent B asks the Context Graph which downstream service needs to know about a change, then uses the simulation to check that the right update reaches it.

The shared simulation in the Postman workspace. Four mocks stand in for the services the claims API depends on.

The moment I care about most is step 4. Agent B doesn’t have to figure out those dependencies or set them up again. The Context Graph helps each agent understand what its change touches, and the shared simulation lets the second agent build on the first agent’s work. That’s the agentic SDLC I wanted to show: discover dependencies, simulate them, build, test, and share the result so the next agent can keep going.

Try it yourself

You can run the same loop on your own services. I ran the demo in GitHub Copilot, but the Postman plugin installs into other coding agents too, so use whichever one you already have. One command installs it:

npx @postman/postman-plugin

The installer adds the plugin to each supported agent it detects on your machine, including GitHub Copilot and Claude Code. To install into a single agent, pass its ID, and check where the plugin is installed with status:

npx @postman/postman-plugin install --agent copilot
npx @postman/postman-plugin status

The plugin install guide covers the per-agent options if you’d rather use an agent’s own marketplace. Next, connect your repository to a Postman workspace:

postman init

Then sign in and ask the Context Graph a question about a service you own:

postman login
postman context-graph ask "What depends on billing-api?" --wait

Swap billing-api for one of your services. The --wait flag prints the answer inline, and without it the command returns an ask ID you can check later with postman context-graph status. From there, try this prompt in your agent, adapted from the demo:

Run the collection, publish the simulation and collection to a workspace, and start a second agent session. Ask it to pull the shared assets and run the existing checks before it changes anything. If it can do that without you explaining the dependencies again, the handoff works.

Resources

• GitHub Universe 2026 announcement on the GitHub Blog
• Postman plugin skills
• Install the Postman plugin
• Postman plugin on GitHub
• Context Graph commands in the Postman CLI
• Query the Context Graph with an MCP client
• Why AI coding agents need context graphs
• Create and run a simulation in Postman
• Announcing the Postman Plugin for Claude Code

The post The Real MVP of GitHub Universe 2026: Context appeared first on Postman Blog.

The Angular community is firing on all cylinders! From shaving milliseconds off your Core Web Vitals to deploying server-side rendered apps in production, mastering professional form submissions, and architecting enterprise Nx monorepos, this week’s lineup is packed with practical engineering gems.

Dive into these expert-led resources to level up your workflow:

Web Core Vitals in Angular (Spanish)

Kevin Dávila breaks down how to optimize your Angular applications for Core Web Vitals (LCP, INP, and CLS). Learn tactical patterns to enhance real-world user experience and skyrocket your performance scores.

• Read the guide: https://www.codeabien.com/es/blog/web-core-vitals-en-angular

Angular SSR Deployment (Spanish with English Subtitles)

Alejandro Cuba Ruiz, Antonio Cárdenas, and Ricardo Chavarría join forces to break down the complexities of taking Server-Side Rendering to production. Discover hosting options, pipeline setups, and critical deployment pitfalls to avoid.

• Watch the deployment panel: https://youtu.be/wIaThYaieUA

Submit Like a Pro with Angular Signal Forms

Fanis Prodromou walks through how to handle form submission flows cleanly using the modern Signal Forms API. Learn how to manage loading flags, submission states, and error feedback with pure reactive ergonomics.

• Watch the tutorial: https://youtu.be/6Jr6AN6gOfY

Beyond Clean Code: Scalable Architecture with Nx Monorepos

Fanis Prodromou also delivers a must-read architectural deep dive on Angular.love. Discover how to structure large-scale enterprise frontends using Nx monorepos, establishing domain boundaries, shared libraries, and maintainable module graphs.

• Read the architecture article: https://angular.love/beyond-clean-code-building-a-scalable-angular-frontend-architecture-with-nx-monorepos

Road to Angular 22: Debounce Signal

Davide Passafaro previews what’s coming on the horizon with native Debounce Signals. See how built-in reactive debouncing primitives streamline state management without relying on third-party utilities or complex operator chains.

• Read the preview: https://medium.com/@davidepassafaro/road-to-angular-22-debounce-signal-74d76eb48384

How are you tuning your Core Web Vitals and SSR pipelines this year? Have you already started structuring your Signal Form submissions with these modern primitives?

Keep the knowledge moving. Use #AngularSparkles to share your favorite tips, benchmarks, and architectural setups with the community 👇

---

Core Vitals Optimization, SSR Deployments, and Signal-First Architecture ⚡🚀📊 was originally published in Angular Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hello Windows Insiders, Today, we’re releasing new Windows 11 Insider Preview builds to the Beta and Experimental channels. New builds this week Select your channel below to view its release notes:

• Beta: Build 26320.9876
• Experimental: Build 26340.9882

For those on other specific Windows build versions, here are today’s new builds and release notes:

• Beta (26H1): Build 28020.3445
• Experimental (26H1): Build 28120.3454
• Experimental (Future Platforms): Build 29704.1000

Experimental (Future Platforms) synthetic payload releases Insiders in the Experimental (Future Platforms) channel will begin to notice in the coming weeks that we will be releasing a new build version on a weekly basis, in-between our usual weekly Insider preview builds. These in between releases are just synthetic latest cumulative updates (LCU's), and do not contain any new features or payload. They are helping us test backend flighting and updating services. As such, we will not publish weekly release notes or blogs for these updates, but will keep track of versions in Flight Hub. 

Notable new features:

[Windows Hello]

Release channel: Experimental Windows Hello sign-in improvement

• Sign-in and unlock now behave more consistently and give clearer guidance. You no longer have to wait for face or fingerprint recognition to finish before entering your PIN. Use whichever method works first. At certain times, such as after a restart, you'll need your PIN first. After that, biometrics work as usual.

[caption id="attachment_179264" align="aligncenter" width="1920"] Sign in with face, fingerprint, or PIN, whichever works first.[/caption] Thanks, Stephen and the Windows Insider Program team

Windows is evolving vulnerability management as advances in AI make it possible to discover and analyze security vulnerabilities faster and at greater scale. AI is accelerating vulnerability discovery on both sides. It can help defenders find and fix vulnerabilities earlier. It can also help attackers search for vulnerabilities before fixes are available and analyze published fixes after release. All of this increases the importance of timely protection. Our approach is straightforward: lead across the vulnerability management lifecycle. We’re using advances in AI to find and fix vulnerabilities earlier, while maintaining a high-quality bar so you and your organization can deploy updates with confidence. We’re promptly publishing information about what we fix so security teams can take action. Just as importantly, we’re strengthening the systems that help organizations deploy updates quickly and respond when issues arise. Since our last communication on this topic, we have continued to advance this work across vulnerability discovery, remediation, validation, and deployment.

Finding vulnerabilities earlier

Identifying vulnerabilities before they can be exploited remains the best opportunity to reduce exposure. Microsoft receives vulnerability findings through responsible disclosure from security researchers and partners, while our engineering and security teams find issues internally. These paths come together through the Microsoft Security Response Center (MSRC), which serves as Microsoft’s central hub for vulnerability reporting, security updates and coordinated response. We are increasingly using AI to help security and engineering teams identify vulnerabilities and act on them more efficiently. One example is MDASH, an agentic code scanner that uses multiple AI models and specialized agents to find and validate potential vulnerabilities. Security and engineering teams then review the findings and determine the appropriate response, keeping human judgment and accountability central to the process. The objective is not simply to find more issues. The goal is to identify meaningful vulnerabilities earlier and make the findings more actionable. By using AI-assisted capabilities, we can distinguish relevant findings from false positives. We can give our engineers better information. As vulnerability discovery accelerates, these capabilities help us focus engineering resources on vulnerabilities that have the potential to affect customers more efficiently.

Moving from discovery to remediation faster

Finding vulnerabilities more quickly only helps if engineering processes can keep pace. We are applying AI assistance across the remediation process to help engineers assess impact, determine which versions of Windows are affected, identify variants in related code, evaluate remediation options, develop backport strategies for different versions of Windows, and build security and regression tests. Engineers remain responsible for reviewing the work, making the engineering decisions, and owning the final output. This distinction matters. Our goal is to use automation and AI to help engineers investigate and remediate issues more efficiently, not to remove engineering judgment from security decisions.

Strengthening validation

Increased discovery and remediation also require validation systems that can operate at greater scale. Windows validation combines multiple sources of evidence. Today, it’s internal flighting, functional testing, security proof-of-concept testing, application compatibility testing, and validation with OEMs, security vendors, ISVs, and customers through the Security Update Validation Program. We also apply AI-assisted capabilities to areas including test selection, test creation, triage, analysis, and reporting. Together, those signals provide evidence for engineers making release-quality decisions. Optional non-security preview updates remain an important part of this process. Organizations can install these updates on select devices before the content becomes part of the following month’s security update, providing additional real-world validation across devices, applications, hardware and configurations.

Making vulnerability discovery actionable

AI-assisted discovery is helping us find more vulnerabilities, across more code and earlier in the development process, so we can address more of them through Windows security updates. In fact, the October 2026 monthly security update addressed more than 1,100 Common Vulnerabilities and Exposures (CVEs) for Windows. The number of CVEs doesn’t tell the full story, though. We are using AI to examine more code, more deeply. The research community continues to find and report vulnerabilities. And we are prioritizing fixes in real time as vulnerabilities are identified. A higher number of CVEs does not mean Windows has become less secure. It means more vulnerabilities have been discovered and closed, reducing the opportunities attackers have to exploit them. Transparency makes those fixes more actionable. We publish CVE information for the vulnerabilities we address, whether they are reported by external researchers or identified by our own teams and AI systems. The Security Update Guide provides details on severity, impact, exploitability, and guidance for each CVE. We also make this data available in machine-readable formats, including Common Security Advisory Framework (CSAF) advisories, Vulnerability Exploitability eXchange (VEX) documents, and API, so it can flow straight into your vulnerability management and compliance tools. Security teams can use CVE information to:

• Track which vulnerabilities are addressed on each device.
• Prioritize which devices receive updates first based on exposure, starting with internet-facing systems, identity infrastructure, and high-value assets.
• Measure protection in days from release, not in patch cycles.

Because Windows security updates are cumulative, prioritization should decide which devices update first, not which fixes get deployed.

When protection becomes available, the clock starts

On Patch Tuesday, Microsoft releases monthly security updates and the information and resources you need to evaluate and deploy them. This includes release notes, vulnerability information (available in the Security Update Guide), cumulative updates (through Windows Update and other deployment channels), and updated servicing media. Releasing an update changes what information is publicly available. Before an update is released, vulnerabilities are triaged through coordinated disclosure. Once the update and associated guidance become public, the fix itself can be analyzed. That means attackers might be able to use a published fix to better understand the underlying vulnerability and develop an exploit—potentially within hours. That’s why our work doesn’t stop when an update is released. We monitor diagnostic data and rollout reporting, customer support and inquiries, and feedback from social channels and forums. Automated systems help us correlate those signals and identify patterns for engineering investigation. Engineers investigate potential issues, validate their cause, and determine the appropriate response. Depending on the cause and impact, that response can include updated documentation or guidance, a workaround, Known Issue Rollback (KIR) to mitigate an affected change, or an out-of-band update. This is the lifecycle in practice: discover vulnerabilities earlier, develop and validate protections, publish them transparently, monitor their performance after release, and respond quickly when needed. But there is one part of that lifecycle Microsoft cannot complete alone: getting those protections onto devices.

Reducing your exposure window

Microsoft engineering systems are one half of the equation. Deployment is the other. The time between an update becoming available and reaching your devices is part of your security posture. A recent article by Anthropic¹ noted that N-day exploits (the time between when vulnerabilities are disclosed but only patched on some devices) is a “patch gap”, as large language models now accelerate developing N-day exploits in hours not days as in the past. This has created a heightened risk threat for devices in the “patch gap”. Yet some organizations still take weeks to deploy updates. Diagnostic data from August 2026 showed that, among a measured Windows enterprise sample, fewer than half of devices had installed the security update two weeks after release, and about one in four still had not installed the update after four weeks. That gap between available protection and deployed protection is the exposure window we need to close. We are seeing organizations move in the right direction, accelerating rollout, moving to supported versions of Windows, and adopting newer update management and servicing capabilities. But faster deployment needs to become the standard, not the exception. Organizations should focus on four practical areas:

• Stay on supported versions and install updates promptly after they are released.
• Reduce unnecessary exposure and use security baselines to implement well-tested, industry-proven configurations.
• Maintain endpoint detection and apply available mitigations.
• Establish effective response and recovery practices.

Of those, staying current is foundational. Shortening the time between when Microsoft publishes a fix and when devices receive it reduces how long a known vulnerability remains unpatched. Newer, supported versions of Windows and modern management tools provide capabilities designed to make updating faster and less disruptive. For Windows 11, Windows Autopatch provides update management through Microsoft Intune, including staged deployments and reporting. For eligible devices, hotpatching can apply monthly security updates without a restart, while standard cumulative baseline updates are required periodically. Hotpatching also provides a path to faster protection for Windows Server while reducing restart requirements. Windows Server 2025 supports hotpatch updates² across eligible Azure, Azure Local, and Azure Arc-connected environments, with Azure Update Manager providing patch orchestration. Organizations running older supported versions of Windows client or Windows Server should continue to keep those environments current and use the update management capabilities available to them. Where extended security updates are necessary, treat them as a bridge while moving to a supported version, not as a substitute for modernization. The goal is simple: turn an available fix into deployed protection as quickly as possible. Reduce the update deployment window wherever possible instead of treating security updates as a task that can routinely wait.

Leading at the pace of change

AI is changing the pace of vulnerability management. It gives defenders new ways to find vulnerabilities, analyze code, and develop protections. At the same time, it can shorten the time between public disclosure and potential exploitation. At Microsoft, our commitment is to stay ahead of that change. We are expanding AI-assisted vulnerability discovery, helping engineers move more efficiently from validated findings to fixes, strengthening validation, and monitoring updates after release. We are also investing in the tools and servicing capabilities that help organizations deploy protection faster. As we apply AI across this lifecycle, human judgment and accountability remain fundamental to how we build and service Windows. Our request of every organization is to move with urgency. Stay on supported versions, maintain layered protections, monitor security guidance, and make reducing the time from release to deployment a security priority. Vulnerability management will continue to evolve as AI advances. We intend to lead that evolution, share what we learn along the way, and give customers the information and tools they need to act. But protection ultimately depends on both sides moving quickly: our ability to find, fix, validate, and publish protections, and your ability to deploy them.

---

1. Measuring LLMs’ impact on N-day exploits. Jun 8, 2026. Anthropic 2. Hotpatch updates for eligible Windows Server 2025 machines connected through Azure Arc are available at no additional cost. Windows Server 2025 Datacenter: Azure Edition does not require Azure Arc for hotpatching and has hotpatch updates enabled by default.

Job postings that came across my desk, slack, email, discord, etc this week.

The post Job listings for week ending 11/06 appeared first on Leon Adato.

A collection of upcoming CFPs (call for papers) from across the internet and around the world.

The post Call For Papers Listings for 11/06 appeared first on Leon Adato.