Jessica Isenhower

Lab · failure notes

Epic AI Fails

The polished demo is rarely the interesting part. These are notes on what happened when AI, automation, and permissions met real work, and which assumption actually broke.

Real incidents, anonymized where neededNo employer confidential dataFailure used as design evidence

I automated a whole company before anyone used the product

UnitRate Watch was my attempt to start a business with next to no money. Self-storage renters get hit with big rent increases, and checking the new rate against nearby listings is harder than it looks, because size, climate control, fees, and move-in promotions all change the math. You entered your facility or ZIP, current rent, and unit size. AI searched current public listings and recommended whether to stay, negotiate, or switch.

AI made the building fast and cheap, so I built all of it: a rate-hike calculator, private result pages, a rule that answered “insufficient evidence” without at least two comparable listings, a library of guides written to rank in search, automatic search-engine submissions, and daily AI tasks watching demand, search visibility, and monetization. It went live two days after I picked the idea.

The product worked. In one test run, a fresh market check with live web search cost about three cents.

It could answer the question in eight seconds. No confirmed customer ever asked it.

55visitors through Sept. 21
0confirmed customer scans
1 of 13pages indexed by Google

At the last check, Google had indexed the homepage and left the other twelve pages “Discovered – currently not indexed.” Bing sent seven visitors. Google sent three. My test needed 100 relevant visitors before it could judge anything, and the whole site had 55.

So the test never got enough traffic to show whether renters want this. I stopped putting time into it anyway, because more guides and more automation weren’t producing any sign that visitors wanted the scan.

See it live

The site is still up. The calculator and guides are public.

Open site ↗

The sane version

  1. Start with one landing page and run the first comparisons by hand.
  2. Find the first renters directly, in renter, housing, personal-finance, and local community groups, instead of waiting for search traffic.
  3. Track calculator use, form starts, and submissions before launch.
  4. Talk to visitors who didn’t submit before automating anything.
  5. Pair the traffic target with a deadline. For example: revise or stop if four weeks of direct outreach can’t produce 25 qualified visits and 3 scan starts.

The automation that got automation banned

Leadership wanted us to move faster on AI and automation.

Then Salesforce started throwing 500+ flow errors.

We spent about a day cleaning it up and eventually found the source: a certified Salesforce admin from another department had been given production access and had quietly started deploying changes through n8n.

Her manager didn’t know. The executive who supported the access didn’t know. We definitely didn’t know.

But now leadership knew one thing: n8n bad.

500+flow errors
~1 daycleanup
0owners informed

So the team actually responsible for automation became more constrained.

Then came the obvious follow-up: Why aren’t the AI automations moving faster?

Automate faster → shadow automation breaks production → become afraid of automation → slow governed automation → demand faster automation.

n8n got convicted for a crime committed by governance.

The lesson

A Salesforce certification is not a change-management process. And neither is executive sponsorship.

My AI worked all night. Except it didn’t.

An agentic website task appeared to keep working for roughly nine hours. It had completed substantial work, hit a publishing handoff problem, launched monitoring agents, and then stopped making forward progress.

The monitoring agents finished. The parent workflow never reconciled that fact. The interface kept displaying activity.

“Still working” became a very polished way of saying “stuck.”

~9 hrsapparently working
0active subagents at discovery
0verified deployments

The failure was operational, not magical: no effective timeout, bounded retry, durable recovery path, or final reconciliation step asking whether the requested business outcome had actually happened.

The sane version

  1. Define the exact completion event.
  2. Set a maximum wait for every external handoff.
  3. Use a heartbeat that proves forward progress, not just activity.
  4. Bound retries.
  5. Escalate blockers clearly.
  6. Checkpoint durable state.
  7. Finish with one question: did the requested outcome actually occur?

The mission-critical workflow nobody used

At a SaaS company, leaders became concerned that disabling an AI integration could break workflows people depended on. Multiple teams got involved. Cost controls were discussed. The vendor was pulled in. The workflow had become “critical” through repetition.

Then somebody checked the usage data.

The workflow was so critical that it had been run zero times.

0actual uses
Severalteams involved
1missing first question

The integration was fine. The mistake was assuming people depended on it before checking whether anyone used it.

The sane version

  1. Confirm the business owner and intended use case.
  2. Check actual usage before escalating availability risk.
  3. Define cost, access, and approval controls before broad enablement.
  4. Test with a controlled group.
  5. Expand only when usage and value justify the risk.

Somewhere, this version of me is VP of Strategic Enablement

I asked an AI avatar tool to create a version of me. It created a woman who looks like she has definitely led a webinar, owns three blazers in the same color palette, and has strong opinions about stakeholder alignment.

She was polished. She was plausible. She was not me.

Sometimes generic AI feels less artificial than personalized AI.

Watch the experiment

A short HeyGen avatar test. She is polished, confident, and only loosely related to me.

Open video ↗

The sane version

Use synthetic presenters when the presenter does not need to be you. If identity matters, require human review for voice, mannerisms, appearance, and whether the result actually represents the person rather than a statistically attractive approximation.

Composite satire · not a real incident

Automated Beyond Recognition

The recurring pattern deserves its own fictional scorecard: take a simple business problem, solve it with as many tools, nodes, agents, alerts, and failure points as financially possible, then discover the last step is still “send Jess a Slack message so she can fix Salesforce manually.”

The machine’s only output is a more expensive to-do list for a human.

The joke lands because the mistake is real: companies automate moving and announcing bad data without automating the fix.

Why keep these

Because each one needs a different fix. A bad output may be a model problem. A stalled workflow is usually an orchestration problem. A “critical” integration nobody uses is a governance problem. A product too few people find is a distribution problem. Adding another tool fixes none of them.