A security warning is easy to agree with. Of course the software needs updating. The awkward part is that the same server may also handle your orders, staff tools, customer support and the jobs that run while everyone is asleep. You need to reduce the risk without creating a different problem for the business.
That was the situation behind several days of work we carried out in October. An urgent PHP warning led to fixes across websites and applications, including WordPress sites, followed by deeper work on older production systems. AI agents helped investigate, prepare changes, test them and work through recovery. I directed the work and made the decisions about scope, timing and acceptable risk.
For a small team, the hard part is finding enough time and knowledge to investigate several systems while keeping the business moving. Agents gave me more capacity to do that work. I could keep separate investigations moving, compare the findings and carry changes through testing and review, while staying responsible when an upgrade became more complicated than expected.
The warning reached beyond the website
On October 21, the PHP team urged users to update after releasing fixes for two critical vulnerabilities that could allow an attacker to run code remotely without signing in. PHP runs behind many websites and applications. The warning concerned the software running those applications, so looking only at a site’s visible pages would miss much of the work.
Our response ran from October 21 through October 25. It included urgent PHP fixes, small repairs to older code, application moves and a larger operating-system and database upgrade. I am keeping the businesses and their systems anonymous here. The decisions are useful to share; a public map of someone else’s infrastructure is considerably less helpful.
One important question came early: what was actually still being used? Older servers accumulate scripts, libraries and tools over years. Some continue to do essential work. Others remain reachable long after anyone remembers why they were created. A new storefront does not automatically retire everything behind the old one.
Before changing the software running an application, we needed to trace what depended on it: the staff screen that used it, the overnight job and the connection to another system. That gave the update plan a business purpose. It also helped keep the work focused on real dependencies and exposure instead of turning every old file into a renovation project.
Give the agents specific jobs
I split the work into specific assignments. One agent could investigate a server and its active software while another examined compatibility or prepared checks for a proposed change. Separate reviewers challenged the change before it moved forward. Findings had to return to a shared plan so that parallel work did not become several people rearranging the same cupboard.
The instructions needed to say what counted as finished. An investigation should identify the affected software and what used it. A proposed update should account for the other software it needed and a way to recover. A completed change needed evidence from the running system. Downloading an update was a preparation step.
This is related to the approach I described in the Codex Inbox article: give work an owner, preserve its context and check the outcome. During a security response, those habits become especially useful. There are several urgent threads, and a confident summary can easily get ahead of the evidence.
I still chose the priorities, decided when a more disruptive change could proceed and approved actions that crossed important boundaries. Agents could do substantial investigation and implementation within those limits. Changes to permissions, production data or the wider environment needed specific attention. The speed of the tools made those decisions more consequential.
Fix the urgent problem, then deal with the older platform
The urgent PHP fixes came first. Some systems could receive an update within their existing setup. Older applications needed compatibility work before moving to newer software. On one live system, an old piece of supporting code caused a staff screen to fail after the PHP change. A narrow correction restored the affected behavior.
That is why checking an installed version is insufficient. The business needs the staff screen, the connections between systems and the background jobs to keep working. Those paths needed their own checks. Otherwise, the update can be technically installed while somebody in the office is quietly discovering the rest of the story.
The larger platform work went further. An older live server moved onto an operating system that receives security updates, and its database was upgraded. Elsewhere, applications still in use were moved to a clean server. These were separate pieces of work with different dependencies and recovery needs. A PHP patch alone could not resolve all the maintenance problems we found.
AI agents made it practical to investigate those pieces in parallel and keep working through the details. They could inspect code, compare dependencies, prepare precise changes and review results. My job was to connect that work to the business and decide which risks belonged in the immediate response and which needed a controlled next step.
The difficult part still happened
The main PHP update involved a brief service interruption. The larger operating-system and database change involved an extended outage and recovery work. Package conflicts and a delayed reboot recovery made that window harder than expected. Service returned after the upgrade and recovery checks, but it would be misleading to describe the whole exercise as effortless or uninterrupted.
That experience belongs in the case study. Faster preparation does not remove the consequences of changing a live system. When the work became difficult, the priority was to restore service safely, preserve recovery options and check the result. Having more agents available helped with the investigation; it did not make a risky shortcut a better decision.
Recovery also needed evidence. An upgraded database backup was restored on a separate recovery server and checked there. After reopening, checks covered public pages, staff tools, database connections and the system that starts scheduled jobs. Records from completed business jobs added evidence beyond a status light saying the scheduler was running.
There were limits. At the last recorded check, confirmation of the next ordinary backup cycle and an update to the site’s search data was still outstanding. The separate restore test had passed, but it could not prove those later events. Keeping those distinctions visible is part of responsible completion, even when a shorter status update would sound more impressive.
AI gives both sides more room to act
I have been interested in cybersecurity for years. A few years ago, I would have found coordinating this range of work much harder. Now I can direct agents through investigations and changes that I would previously have struggled to take on together. I still need to understand the risks, question their work and know when a decision needs more expertise.
The same tools can also help attackers. In its investigation of an AI-assisted espionage campaign, Anthropic reported attackers using agents to carry out substantial parts of the work. That is a separate reported case, not evidence about the businesses discussed here. It is a reason to take the defensive uses seriously as well.
For a business, the practical question is how to turn an urgent warning into a response someone can carry through. That requires knowledge of the systems, permission to act, useful tests and a person who owns the result. Agents can help with a great deal of the work when those pieces are in place.
What this means for your business
If your company depends on older software, it helps to know who can explain what is running, what depends on it and how a change will be checked. Those questions matter before the next urgent notice arrives. They are also a useful starting point for deciding where AI can help your own team.
At Bombyx, this is part of the practical technical work we can help businesses plan and carry through. It draws on the same habits we use when building AI workers: understand the job, give the tools the right context, set clear limits and check what happened. This case involved security and infrastructure, where the cost of getting those habits wrong is particularly clear.
The result was several days of concrete fixes, upgrades, recovery and verification across working systems. Some follow-up still needed its own evidence. For me, the lasting change is having more capacity to tackle that work while keeping responsibility for the decisions. For a business owner, that is a useful capability to have available when the warning arrives.