When one AI tells you to ask another

May 29, 2026

A practical story about Oracle 19c, RHEL 9, and an unexpected referral.

I was automating an Oracle 19c installation on Red Hat Enterprise Linux 9 by creating an Ansible-playbook. What followed was a small lesson in how AI tools are starting to complement each other in ways I didn't expect.

The problem: base release, wrong era

When you download Oracle 19c, you get version 19.3, the original base release. The catch: Oracle 19.3 was never certified to run on RHEL 9. Oracle 19.3 shipped before RHEL 9 existed. The installer doesn't refuse outright, but things quietly break in ways that are hard to trace from first principles.

My Ansible-playbook kept failing. I adjusted prerequisites, kernel parameters, user limits. Nothing worked. The errors were vague, the Oracle docs were circular, and the usual sysadmin intuition wasn't cutting it.

What Claude did next

After several iterations, I was using Claude to help debug the playbook. At some point, after the obvious fixes were exhausted, it made a suggestion I hadn't expected.

It recognized that the root cause was likely a certification gap between Oracle 19.3 and RHEL 9, and that Oracle Support's AI assistant has direct access to the official patch matrix. It handed me a ready-made prompt to use:

We are trying to install Oracle Database 19c (19.3 base installer) with RU 19.31 (patch 39034528) on RHEL 9 x86-64 using a silent installation (no GUI available). The silent installer consistently fails with "undefined reference to stat" in libnnzst19.a(ccme_ck_rand_load_fileS1.o) during the linking of the orion binary (make target all_no_orcl). Because the installer fails at this point, the oraInventory is never created, which means opatch apply and runInstaller -applyRU both fail as they require a registered inventory to proceed.
MOS Note 3064394.1 describes a workaround involving copying files from patch 33794281 into ORACLE_HOME/lib/stubs and clicking Retry in the GUI installer. We cannot use this workaround because we have no GUI.
We have already tried CV_ASSUME_DISTID=OL7/OL8/RHEL8/RHEL7.8, -ignoreInternalDriverError, libpthread_nonshared.a symlink, and manually creating the oraInventory XML.

Question: How do we apply the lib/stubs fix from patch 33794281 during a silent installation on RHEL 9 x86-64 with RU 19.31, so that the linking errors are resolved and the oraInventory is created successfully?

So I did. I opened Oracle Support, pasted that prompt into their AI assistant, and within seconds got a concrete answer: a specific patch number that brings 19.3 to a version certified on RHEL 9.

Patch applied, playbook fixed

I added the patch steps to the playbook and ran it again. The installation completed cleanly. What had been a multi-day friction point resolved in minutes, not because I found the answer, but because I was pointed to where it lived.

Claude didn't know the Oracle patch number. But it knew who did, and it knew how to ask the right question to get there.

The actual takeaway

This wasn't magic. It was a routing decision. Claude recognized the boundary of its own knowledge and pointed toward a system (Oracle's support AI) that has access to proprietary, continuously updated patch data. The value wasn't in the answer; it was in the referral and the framing of the question.

It's a pattern worth internalizing: AI tools aren't monolithic. Some have broad general knowledge; others have deep, domain-specific, up-to-date access. Knowing which to ask, and how, is increasingly part of the job.

In this case, one AI sent me to another. The second one had what the first one didn't. The playbook works.

Want to reach out? Contact me.