My job judge AI agent vetoed a candidate for Epoch AI on October 7th, citing "three hours of overlap with Pacific Time." This was a direct misinterpretation of time zones. Panama operates on UTC-5 all year. US Pacific Time (UTC-8) from 9 AM to 5 PM translates to 12 PM to 8 PM in Panama. This is a 7-hour overlap, not 3, and it's perfectly compatible. The agent, despite being explicitly prompted with the correct time zone context, failed to apply it.
The Veto Trigger and Initial Misunderstanding
The VibeJobHunterAIPA_AIMCF agent, responsible for evaluating job applications, rejected a candidate for Epoch AI. The specific reason logged on October 7th was a perceived time zone incompatibility. The agent's internal logic, even with the prompt line, was not correctly mapping US Mountain/Pacific hours to Panama's UTC-5. This wasn't a subtle error; it was a fundamental miscalculation of time differences. The agent was designed to filter for specific working hours, but its interpretation of those hours across time zones was flawed.
Enforcing Time Zone Compatibility in Code
On October 12th, I committed two fixes to VibeJobHunterAIPA_AIMCF. The first commit, 7b4a975, explicitly stated that "US Mountain/Pacific hours are compatible with Panama (UTC-5 all year: Pacific 9-17 = 11-19 Panama)." This was a direct response to the October 7th veto. However, the agent vetoed Epoch AI again on October 12th, even with this prompt line. This confirmed that relying solely on prompt engineering for such a critical, deterministic rule was insufficient.
The second commit, 6a0a94e, addressed this by enforcing the rule directly in the code. The commit message reads: "fix(judge): enforce in code that US Mountain/Pacific hours fit Panama - the live judge vetoed Epoch AI again on 12 Oct WITH the prompt line, so like the LATAM rule the criterion is overruled in code (veto stands for residence, country lock, a range without UTC-5, or non-US hours); tests." This meant that for specific time zone compatibility, the agent's internal decision-making process was overridden by a hard-coded rule. The agent can still veto based on residence, country lock, or non-US hours, but the specific US Mountain/Pacific to Panama time zone conversion is now a non-negotiable compatibility.
Broader Implications for AI Agent Reliability
This incident highlights a recurring challenge in AI agent development: the gap between explicit instructions in a prompt and the agent's actual operational logic. While large language models are powerful, their interpretation of nuanced, deterministic rules, especially those involving numerical calculations like time zones, can be unreliable. My cto-aipa process, for example, has seen 201 restarts, indicating ongoing adjustments and refinements. The algom-stream process has 55193 restarts, showing a different scale of operational volatility.
Operational Stability and Ongoing Monitoring
Despite these specific agent-level issues, the overall system shows a degree of stability. Nine of nine PM2 processes are online. algom-poll has 0 restarts over 77 days, and n8n also has 0 restarts over 61 days. This indicates that core infrastructure components are robust. However, dragontrade-dashboard has 1 restart over 58 days, dragontrade-main has 4 restarts over 5 days, whitespace has 5 restarts over 1 day, and serpapi-jobs has 4 restarts over 1 day. These numbers suggest that while some parts are stable, others require more frequent attention.
The apply-queue.log shows "sent to Telegram (1 new)" and "sent to Telegram (3 new)," indicating successful job application notifications. The atlas-lead-machine.log shows "[lead-machine] done · staged 8 · looked at 9 · no-email 3 · already-in-CRM 0 · outside-band 0 · audit-failed 0 · crawler-blocked rescued 0," indicating lead generation activity, though with some timeouts.
Frequently Asked Questions
Q: Why not just improve the prompt for the AI Agent Time Zone Fix?
A: The agent vetoed the candidate again on October 12th with the improved prompt line. This demonstrated that for deterministic, numerical rules like time zone conversions, relying solely on prompt engineering was insufficient and led to repeated errors.
Q: How do you prevent similar time zone errors in other parts of the system?
A: For critical time zone calculations, the approach is to enforce compatibility directly in the code, as done with commit 6a0a94e. This overrides the agent's interpretive capabilities for specific, non-negotiable criteria.
Q: What was the impact of the "cut landed inside an emoji" incident?
A: The incident caused every structured call to the primary model to return 400. The entire document kit for that deal was then quietly built and reviewed by a fallback model instead, without explicit notification of the primary model's failure.
Q: How do you manage communication between disconnected AI agents like Cursor and Claude Code?
A: I use a shared NOW.md file as working memory. Since Cursor Cloud, Cursor Desktop, and Claude Code cannot see each other's chats, this file serves as a protocol for agents to avoid redundant work and share context.
Q: What is the most stable process in your current setup?
A: The algom-poll process has been online for 77 days with 0 restarts, and n8n has been online for 61 days with 0 restarts, indicating high stability for these components.