Field Notes: Why I Default to OpenAI and Anthropic
Duckbill and MedFinder are a real-life example of why I prefer adaptable, general-purpose AI directly over another narrow product layer that can turn failure into a black box.
Imported markdown
Status: Working note based on two customer-service escalations on August 3, 2026.
Working thesis
I increasingly default to general-purpose AI from OpenAI or Anthropic instead of relying on a specialized AI service to sit between me and the work.
Duckbill AI and MedFinder AI are a good real-life example. Both were supposed to remove aggravating administrative work. When they failed, they created a second layer of work that was harder to inspect, redirect, or fix.
Case notes
- Duckbill AI: Returned a polished comparison that still left the call-only facts I needed unresolved. I had to audit the result, identify what was missing, and escalate the work the service was supposed to have completed.
- MedFinder AI: Produced unreliable availability information, directed me to a pharmacy that did not have the medication, restarted a search I had asked it to cancel, and turned the refund into another customer-service fight.
Whether or not either product is literally a thin wrapper around a foundation model is not the important distinction here. From my side, each one is another product layer with its own assumptions, interface, limits, and support system.
What the general-purpose layer could do
Codex could step outside both products' intended workflows and deal with the failure itself. It:
- Read the histories across Duckbill, MedFinder web chat, and Messages.
- Reconstructed the specific failures and prior commitments.
- Wrote and sent firm escalation messages.
- Kept the requests concrete: owner, deadline, written confirmation, refund reference, and next action.
- Split the follow-up between agents so Duckbill and MedFinder could be handled in parallel.
The specialized services could only operate inside their own systems. Codex could work across the systems, inspect the mismatch between the promise and the result, and change tactics when the happy path failed.
Why the abstraction becomes a liability
The abstraction is useful only while it reliably removes work. Once it fails, I am dealing with:
- The original task.
- The product's hidden assumptions and limitations.
- The customer-service process required to dispute the result.
At that point I would rather work with a capable general-purpose model directly. I can give it more context, inspect what it is doing, redirect it, and use it across whatever interface the problem moves into.
Current boundary
Codex still cannot make phone calls. That sucks. Some of the most important answers are only available by calling a person, so the workflow still stops where a phone call becomes necessary.
Working operating model
- OpenAI or Anthropic directly: Default AI layer for research, reasoning, writing, digital operations, escalation, and coordination.
- Specialized AI service: Use only when it provides a real execution capability, reliable results, and enough visibility to verify the work.
- TaskRabbit: One-off physical or local tasks.
- Mother's helper: Recurring household support that requires a person to be present.
- Me: Priorities, judgment, approvals, and decisions.
Provisional takeaway
I do not need another AI abstraction just because it packages one workflow neatly. It has to earn its place by doing something the general-purpose layer cannot do—and by continuing to reduce work when something goes wrong.