I Handed Two Days of PC Troubleshooting to AI Agents | What Worked and What Failed

Introduction: Letting AI Investigate a Real Machine

Marketing Cloud Lab, the operator of AIOPulse, uses AI agents for site operations and research. In this "AI Ops Notes" corner, I record my experiences delegating tasks to AI. I write down what worked as well as what failed, exactly as it happened.

The subject of this first entry is a problem with a PC I use at home. I tried to upgrade the memory on my HP OMEN 30L, which I use to run local LLMs, to 64GB. After adding the memory, Windows stopped completing a normal boot. I spent two days having ChatGPT and Claude Code help me investigate the cause. In the end, I gave up on the purchased memory (CFD 16GB×2).

Note that this PC is unrelated to AIOPulse's measurement mechanism. It has not affected AIOPulse's measurements.

In this article, I cover the following:

• AI role division
• Rules established before delegation
• What went well and what failed when delegating
• A checklist for using AI agents in work

I have compiled the full technical steps and chronological record in the "AI Field Notes" corner on our sister site AIpedia (accessible via the related links at the bottom of this page).

What Happened: The Timeline in 3 Minutes

Date/time (JST)	Event
10/12	I had Claude Code research memory selection. CFD 16GB×2 was recommended, but with "unverified points."
11/01 PM	Inserting the CFD modules caused beep codes and no display. I also discovered the CMOS battery was dead.
11/01 around 22:20	I replaced the battery and installed 4 modules for 64GB. The BIOS recognized 64GB, and the memory Fast Test in HP's UEFI diagnostics passed. However, normal boot stopped at the white spinning ring under the logo.
11/02 Morning	Even with 64GB, the system booted in Safe Mode.
11/02 Noon	I set up SSH access from my Mac to the PC in Safe Mode, and Claude Code collected and analyzed logs.
11/02 PM	I isolated the issue by disabling the GPU and changing BIOS settings. A BIOS change suggested by the AI prevented even POST (self-diagnostic immediately after powering on) from passing, so I removed the CMOS battery to reset it.
11/02 16:58	Reverting to the original 2 modules (32GB) allowed normal boot. The cause was narrowed down to "adding the CFD modules."
11/02 17:04	I gave up on the CFD modules and decided to buy HP genuine memory.

Normal boot with 64GB failed 7 times, as far as I can confirm from records, with 0 successes. Normal boot with the original 32GB succeeded every time.

However, I have not fully identified the cause. I cannot say the CFD memory is defective. It remains unclear whether it is the CFD modules themselves (or how the BIOS handles non-HP memory) or the mixing of two types, because I did not test the two CFD modules alone.

Division of labor: ChatGPT as the “eyes,” Claude Code as the “hands” and “scribe”

While the PC would not boot properly, the only way to feed screen contents to an AI was through a smartphone camera. So I made ChatGPT (on my smartphone) the “eyes.” I photographed BIOS screens, beep codes, and recovery screens, had ChatGPT read them, and asked for the next steps on the spot. I also had it compile a history of our consultations, explicitly marking entries with ambiguous timestamps as “time unknown.”

Claude Code (on my Mac) served as the “hands” and “scribe.” From the Mac, it inspected the PC over SSH, collected and cross-referenced logs, ran the isolation tests, and wrote reports and procedures. For BIOS screens, I passed along the summaries ChatGPT generated from the photos. Claude Code did not see the photos themselves.

My role as a human was to press the power button, swap memory modules, operate the BIOS, and decide whether to execute each proposed change.

In this setup, the AIs do not connect directly; I carry the summaries between them. Information can be lost or altered in transit. If ChatGPT misreads a photo, that error passes straight through to the next AI. Even so, dividing the roles allowed each AI to focus on what it does best.

Rules I Set Before Delegating

Before letting the AI agent investigate the physical machine, I established the following rules.

1. Read first: I made the initial diagnostic script read-only. This ensures I accurately understand the current state before making any changes.
2. Require "pre-change values and rollback steps" before execution; a human decides whether to run it: This applies to registry changes or disabling the GPU.
3. Categorize information types: I prevented mixing four distinct types: physical machine logs, my memory, external documentation (such as forums), and inferences.
4. Normalize timestamps to real time before correlation: The PC clock was off by 32 minutes, and later by 2 hours and 20 minutes. Lining up events without correcting the drift leads to misreading their order.
5. Change only one thing at a time: Changing multiple things simultaneously makes it impossible to determine which change had an effect.

An example of rule 2 is the registry change that enabled SSH in Safe Mode. I needed to register sshd under HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network. I instructed Claude Code to document the pre-change backup (reg export), the specific changes, the scope of impact, side effects, and rollback steps in a procedure. After reading this, I executed the command myself.

Rule 3 also had a significant impact. I had assumptions that "Windows might be running in the background during the white spinning ring" and "the CFD might be faulty." Claude Code presented physical machine logs and distinguished between my assumptions and facts verified by records. Instead of stating "the CFD is faulty," it reasoned from the fact that "according to the records, there has never been a single successful normal boot with 64GB."

The instructions I actually gave and the format of the reports I got back

I drafted the prompt for Claude Code using ChatGPT on my smartphone, then pasted it into my Mac. In other words, I had one AI write instructions for another AI. When starting with SSH diagnostics, the instructions covered roughly these seven points:

1. First, read the existing connection documentation and SSH configuration
2. Verify connectivity using a short timeout setting
3. If it fails to connect, distinguish between “timeout,” “connection refused,” and “authentication failure,” and indicate the minimal checks needed on the PC side
4. If it connects, collect configuration details, memory info, BIOS settings, Automatic Repair logs, recent event logs, and so on
5. Analyze by separating notes from my Mac, forum information, and actual values from the machine
6. Distinguish between forced shutdown records (Kernel-Power 41) and genuine hardware failures; do not treat services stopped in Safe Mode as faults without further verification
7. Propose only one next step to try, along with how to revert it

I also explicitly listed what not to do at this stage: automatic reboots, changing BIOS or memory settings, modifying services, registry entries, or firewall rules, deleting drivers, and repairing or resetting the OS. I clearly defined the read-only scope in words.

In the afternoon, I widened the scope by telling it to run the tests itself. From that point on, Claude Code executed changes over SSH—such as disabling the GPU—only after getting my permission. I started narrow, observed the results, and gradually widened the scope. It was a phased delegation approach.

The reports it returned followed almost the same headings every time.

Heading	Content
Facts obtained from the actual machine	Command outputs, logs, timestamps (converted to real time)
Information from documentation (not verified on the actual machine)	Manufacturer documentation, forum posts
Interpretation (inference)	What can and cannot be concluded from the facts
Next move (executed by the user)	One thing to try, its purpose, steps, and how to interpret the result
How to revert	Pre-change values and the commands to restore them
Files	Locations of the records serving as evidence

Thanks to this structure, I never had to guess “how much is certain” when reading the reports. When writing this article later, I could also directly pull the timestamps and supporting evidence.

What I was glad to delegate

The most helpful part was lining up multiple records and cross-referencing them. A task that would take hours for a human, AI completed quickly with supporting evidence.

Reconstructed the timeline from another log

I could not tell when the PC was on the network based solely on the PC's own records. Claude Code used a different automated process log left on the Mac side (a record of a process that connects to the PC periodically) and restored it. "After 21:51 on 11/01, it did not appear on the network even once until 08:53 in the morning." This weakened the theory that "Windows is running in the background during the white spinning ring."

Found the decisive line

When the last normal boot succeeded, was the memory 32GB or 64GB? I could not decide from my memory. Claude Code found a record stating "physical memory approx. 32GB" in a configuration file written by an NVIDIA app at startup (SHIM.json). This single line confirmed that "normal boot succeeded only when it was 32GB."

Used the "missing record" as evidence

I enabled boot logging and attempted a normal boot, but it stopped at the white spinning ring, and not a single line was added to the boot log. Claude Code interpreted this as "it is stopping at a very early stage, before writing the boot log." No event log entries remained either. The absence of records itself became a clue to where it stopped.

Ran isolation tests in a reversible way

To check if the GPU driver was the cause, Claude Code disabled the NVIDIA GPU via SSH with my permission and attempted a normal boot. The result was the same stop. NVIDIA was ruled out as a candidate, and the GPU was immediately re-enabled. The command to revert was decided before execution.

Failures and near-misses when I delegated

1. An AI suggestion broke POST

Claude Code compared the values in the BIOS memory settings screen (Memory Overclocking) against the specifications and suggested changing tRFC from 560 to 880. This was the value required by the standard for the added CFD chips (16Gb), so it was a logical suggestion based on the specs.

However, when I switched to manual settings and set it to 880, beep codes sounded and the system stopped at POST. My inference is that when switching to manual mode, the out-of-spec values displayed on the screen (such as "0" for tWTR_S) may have been applied as-is. Restarting the power several times did not fix it. I had to remove the CMOS battery to reset and finally restore the original state.

The suggestion included a fallback method: removing the CMOS battery as a last resort. That is why I could recover. The AI itself also noted in its records that manually changing timings in the BIOS should only be done when there are no other options.

2. Unfounded probabilities

When I asked, "What are the chances that updating the BIOS will fix it?", the AI answered, "About 10–20%." It was good that the AI explicitly stated this was an estimate rather than a number based on evidence. Even so, once a number is given, it tends to stand on its own. I need to ask for the basis and treat it as an estimate if there is none.

3. Over-collection

The read-only diagnostic script collected information related to the product key of the OEM version of Windows in the BIOS. I redacted the copy on my Mac side. The script also had bugs, such as exceptions occurring during the summarization process and incorrectly recording the pagefile as "none" due to mishandling hidden files. Code written by an AI makes mistakes just like code written by humans.

4. It corrected its own explanation

Claude Code wrote that "zero memory error records (WHEA)" was evidence of normal operation. However, this memory does not have ECC (error detection and correction), so it would not be recorded in WHEA in the first place. The AI later corrected itself. If I had only read that one sentence, I might have prematurely concluded that "the memory is fine."

5. Skimming the caveats in the recommendation

When I delegated the memory selection in October, the AI recommended CFD but noted that "a mix of 2-rank and 1-rank is not verified" and "operation with this BIOS is not verified." The trouble I ran into was exactly in those "not verified" areas. I only read the recommendation part and skimmed over the unverified sections.

AI suggestions are often "correct on paper." However, they do not know the quirks of OEM BIOS or the specific circumstances of my machine. If I verify the rollback method before trying, I can recover even if it fails.

Verifying AI Answers Works the Same Way in AI Search

Most of the failures this time started because I took the AI's answers at face value. I only read the recommended text. I tested the "correct" answer from the specs directly on the actual machine. Numbers without basis appeared.

The same structure exists in the AI search that AIOPulse handles. Answers from ChatGPT, Gemini, and Claude change depending on how you ask and the date. You should not decide whether "our company is recommended by AI" or "not recommended" based on a single answer. You need to align conditions, verify repeatedly, and separate facts from speculation when reading. How many repeated answers become one share figure is explained in What is mention share in AI search?

AIOPulse's Japanese-language series on everyday questions follows the same mindset. It asks ChatGPT, Gemini and Claude the same question while changing one condition at a time, and records how the center of gravity of the answers shifts.

Using AIOPulse does not prevent failures like this one. However, the mindset that "you don't know an AI's answer until you verify it" is the same.

Checklist for Using AI Agents at Work

I turned the lessons from this experience into a checklist.

1. Start by letting it only read: Begin with checking logs and system state. In this case, I limited the initial scope to running a read-only script via SSH and collecting the results.
2. Require it to write down "pre-change values, rollback method, and scope of impact" before making changes; humans decide whether to execute: This is especially important for changes that affect the system, such as the registry or BIOS.
3. Ask it to separate facts, memory, documentation, and inference: Treat inferences as hypotheses, not definitive statements.
4. Ask for the basis behind probabilities or estimated figures: If there is no basis, treat them as "assessments."
5. Always read the "unverified" sections that appear alongside recommendations: Risks are often written there.
6. Change only one thing at a time: This ensures you can identify what actually worked.
7. Define the scope of information the AI collects in advance: Mask any secrets or identifying information that might get mixed in.
8. Align prerequisites, such as timestamps, before cross-referencing: In this case, the PC clock was off by up to 2 hours and 20 minutes.
9. Humans decide when to give up (cut losses), based on prepared materials: The deciding factor here was the realization that "even if we try with just the two CFD modules, the fix is the same either way: standardize on HP memory."

The AI agent was very useful as a "fast, tireless research assistant." However, the final judgment and responsibility remain with humans.

Summary

Over two days of investigation, AI was very helpful for cross-referencing logs and isolating issues, but it failed when suggesting BIOS changes. The memory upgrade failed, so I have to start over with HP genuine memory.

Verify AI answers before using them. Prepare a rollback plan before changing settings. These two rules apply whether you are investigating a PC or working on how AI search treats your brand.

The full technical timeline is in the “AI Field Notes” corner on AIpedia.