This week: Git security fixes, agent skills, and running AI at scale

This week's stories circle one theme: making AI agents dependable in real engineering work. Git shipped security fixes you should install now. GitHub published its October availability report and a guide to portable agent skills. Martin Fowler's site contributed three pieces on glossaries, test contracts, and durable execution for long-running agents, plus notes on the new Technology Radar.

Git patches six vulnerabilities in recursive clones and merges

Git released updates addressing six security vulnerabilities. The affected areas include recursive clones, reference handling, merges, binary patches, and imports.

Because Git runs on virtually every developer machine and CI runner, these bugs expose a wide surface. A malicious repository could potentially trigger them during routine clone or merge operations.

Check which version your systems run and upgrade to the patched release. Pay attention to CI images and build agents, which teams update less often than workstations.

Source: Git security vulnerabilities announced

GitHub reports eight incidents for October

GitHub's monthly availability report covers eight incidents that degraded service performance during October.

These reports are worth more than a skim. They show which subsystems fail most often, and they help you decide how much redundancy your workflows need around GitHub-dependent automation.

If your pipeline assumes GitHub is always up, read the incident details and consider how your jobs behave during degraded performance, not just full outages.

Source: GitHub availability report: October 2026

Agent skills make repeatable work portable across hosts

GitHub published a practical guide to agent skills: files that capture repeatable engineering work so agents can review and reuse them. The key split is that skills travel, while tools, project context, and permissions stay specific to the host that runs the agent.

This separation matters if you support several agents or editors. You write the skill once instead of duplicating prompts and instructions per tool.

If your team keeps rebuilding the same prompts for common tasks, the guide is worth reading. Treat skills like code: version them and review changes.

Source: Build once, run on any agent: A practical guide to agent skills

Generated glossaries teach LLMs your domain vocabulary

Martin Fowler describes using an LLM to build a glossary of an organization's specialized terms, then feeding that glossary to any LLM working in that domain. The source material can be documents, emails, and chat logs; most organizations already generate enough text.

The interesting detail is that the generator should flag two things: terms new to the model, and familiar terms used in unfamiliar ways. The second category causes the most confusion, because the model confidently applies its default meaning.

If your team uses LLMs against internal systems or domain-specific processes, this is a cheap way to cut misinterpretation. Start with your existing documentation.

Source: Bliki: Generated Glossary

Put the human-AI contract in test data, not test code

Matteo Vaccari argues that when AI writes both production and test code, developers become the code's customers. So customer tests, not developer tests, become the primary contract between humans and AI. Moving that contract into test data rather than test code makes it harder for a coding agent to quietly weaken it.

The economics changed too. Domain-specific language parsers and custom test runners used to be expensive to build and maintain. AI makes them cheap enough to justify.

If you review AI-generated code, ask what stops the agent from editing its own tests. Data-driven test definitions are one concrete answer.

Source: Tests as data: ensuring AI-generated code does what we want

The Technology Radar flags the gap between pilot and operating model

The November Thoughtworks Technology Radar is out, heavy on AI blips from the last six months. Chris Ford's accompanying article covers the macro trends.

The sharpest point: a small enthusiastic team can make agents work because they share context, a budget, and a mental model, and review each other's output in person. Two hundred people cannot. At scale, new questions appear: how teams share context, what the token spend looks like, how to handle increased review load, what agents may read and change, and who owns the harness everyone depends on.

If you are moving from an agent pilot to a wider rollout, read the radar article and use those questions as your checklist.

Source: Fragments: November 10

Durable execution keeps long-horizon agents on track

Kiran Prakash explains durable execution, an emerging pattern for agents that run for days or weeks and interact with people and external systems. The runtime records the result of each step that touches the outside world. On failure, the program reruns, skips completed steps, and rebuilds its state from the record.

This addresses a real gap. A crash on day three of a week-long task should not mean starting over. The model resembles workflow engines, applied to agent loops.

If you build agents that outlive a single request, evaluate whether your runtime persists step results. Frameworks built on this idea are worth comparing before you write your own recovery logic.

Source: Long-horizon agents and durable execution

What I'd watch next

Which subsystems recur across GitHub's monthly incident reports, and whether degradation handling becomes a standard part of CI design.
Whether agent skills converge on a shared format or stay host-specific.
How durable execution support lands in mainstream agent frameworks, since recovery is the hard part of long-running tasks.
The specific fixes in the new Git release, especially anything affecting clone behavior in CI pipelines.