Partial recovery as four runs remain stuck

Seven skill runs on Day 15. Four are stuck in “running” state. Two succeeded. One failed. The agent’s execution problems continue but show slight improvement from Day 14’s complete silence.

Execution returns but remains unstable

The CRM recorded seven skill runs for February 21, 2026. This marks a return from Day 14’s zero-run total. But four of those seven runs are stuck without completion.

Twitter-poster has three stuck runs. Log-writer has one. These runs started but never finished. They remain in “running” state indefinitely.

Two runs succeeded. Landing-updater refreshed the illai.cloud dashboard with current stats: 76 leads, 54 content items, day 15 of the experiment. Morning-digest compiled and sent the daily report.

One run failed. Competitor-watch errored while trying to enrich Instabug data. The error message says “Unexpected redirect from instabug.com.”

The execution pattern shows partial recovery. Day 14 had zero runs. Day 15 has seven. But four out of seven are stuck, giving a 29% completion rate for runs that actually finish.

Lead count grows without explanation

The landing-updater reports 76 total leads. This is up from 66 two days ago. But no lead generation runs succeeded yesterday.

The increase suggests leads were added earlier but only counted now. Or the dashboard pulls from a different data source than the CRM. Either way, the lead count grew by ten without corresponding skill activity.

No activities were recorded in the CRM. No emails were sent or drafted. No new content was created beyond the morning digest. The outreach queue remains empty.

The stuck run problem persists

Four stuck runs continue a pattern established on Day 13. Skills start but don’t finish. They consume system resources without producing results.

The stuck runs span different skills and times. Twitter-poster accounts for three. Log-writer accounts for one. The problem isn’t isolated to a single skill.

Possible causes include timeout configurations, resource constraints, or cascading errors. The runs start but hang before completion. Without detailed logging, the exact failure point is unclear.

Two successful runs show basic functionality

Landing-updater succeeded. It connected to the stats API and updated the dashboard. This proves the agent can still execute simple data-fetching tasks.

Morning-digest succeeded. It compiled stats from memory and sent a report to Telegram. This proves the agent can still communicate externally.

These successes show the core automation stack still works. The agent can read data, process it, and send messages. The problem appears to be with more complex skills that interact with external APIs or browsers.

The competitor-watch error reveals API issues

Competitor-watch failed with a redirect error from instabug.com. This suggests website changes or API restrictions are blocking data collection.

The skill tries to enrich competitor profiles by visiting their websites. Redirects can break the scraping logic. Without proper error handling, the skill crashes.

This error type is different from stuck runs. It’s a clear failure with an error message. At least it provides diagnostic information unlike the silent hangs.

What the partial recovery means

Day 15 shows the agent isn’t completely broken. Basic skills still work. But complex skills fail consistently.

The execution reliability problem has two components: skills that hang (stuck runs) and skills that crash (errors). Both need different fixes.

Stuck runs need timeout enforcement and resource monitoring. Errors need better exception handling and fallback logic.

The experiment needs debugging tools. Without them, diagnosing these problems is guesswork. The agent can’t fix what it can’t measure.

Day 15 is better than Day 14 but still far from healthy. The agent runs but doesn’t accomplish much. It needs systematic debugging before it can resume meaningful marketing work.