My AI agent, VibeJobHunterAIPA_AIMCF, was discarding 610 jobs from Torre. All of them. This wasn't a filtering issue; it was a source failure. The agent was fetching jobs, but a timing misconfiguration meant it couldn't process them. This specific failure, along with others across different job sources, highlighted a critical vulnerability in my job search automation: if the data input pipeline breaks, the entire system starves. Over the last 48 hours, I've pushed 12 commits to address these issues, focusing on robust source integration and error handling.
The Torre Timeout: 610 Discarded Jobs
The Torre source was configured with a 20-second timeout. This seemed reasonable initially, but the reality of fetching job data from their API proved otherwise. The agent was successfully connecting and initiating requests, but the responses often exceeded this window. The result: 610 jobs, primarily from LATAM, were fetched but then immediately discarded because the processing logic timed out. The commit 5af1858 (2026-09-29) addressed this directly: fix(sources): Torre gets 90s, not 20s - it was fetching 610 LATAM jobs and discarding them all. Extending the timeout to 90 seconds allowed the agent to fully ingest and process these jobs, preventing a massive data loss. This wasn't about finding more jobs; it was about keeping the jobs already found.
Bright Data's Door: Gating the Snippet, Not the Posting
Another significant issue emerged with Bright Data. The agent was configured to gate job snippets based on location or other criteria, which meant it was filtering potential jobs before it even had the full posting details. This led to a situation where potentially relevant jobs were never even considered because the initial, limited data didn't pass the filter. The commit 0a980de (2026-09-29) fixed this: fix(bright-data door): search where she can work, and gate the posting, not the snippet. The change ensures that the agent first retrieves the full job posting, then applies the filtering logic. This prevents premature rejection based on incomplete information, allowing for a more accurate assessment of job suitability.
Himalayas: From Zero Searches to Targeted Queries
The Himalayas source presented a different kind of failure: it wasn't searching anything at all. My logs showed no activity for this source, indicating a complete breakdown in its integration. The root cause was an incorrect API endpoint or query structure. Instead of using a general search, the agent needed to hit a specific endpoint with targeted queries. The commit 06f6329 (2026-09-29) resolved this: fix(himalayas): the source searched nothing - use /jobs/api/search, one query per lane. This involved switching to the /jobs/api/search endpoint and structuring queries to run "one query per lane," ensuring that each search criterion was properly applied and executed. This brought the Himalayas source online, adding another stream of potential jobs.
Learning from Internal Notes and External Feedback
Beyond direct source integration, I also refined how the AI agent interprets internal notes and external feedback. The system uses specific notes for internal tracking, like "📌 JOB POSTING" for hand-staged jobs or "🎯 ROLE DEFENSE" for specific rejection kits. Previously, these internal markers could be misinterpreted by the agent as reasons for application or rejection. The commit debac32 (2026-09-29) addressed the job posting note: fix(learning): the "📌 JOB POSTING" note on hand-staged jobs is never her reason or her "applied". Similarly, 026419e (2026-09-29) ensured internal feedback isn't confused with external rejections: fix(feedback): the new 🎯 ROLE DEFENSE kit note is never read as Elena's rejection reason. These fixes prevent the agent from "learning" incorrect patterns from its own operational metadata, improving the accuracy of its decision-making.
Finally, I added a specific blocklist entry for my own email domain (@aideazz.xyz) to prevent the agent from misinterpreting internal communications as employer replies. The commit 6c072e6 (2026-09-30) states: fix(responses): our own @aideazz.xyz mail is never an employer reply - one entry in the existing sender blocklist. This is a small but crucial detail for maintaining clean data and avoiding false positives in reply detection.
Operational Stability and Continuous Deployment
These 12 commits to VibeJobHunterAIPA_AIMCF in the last 48 hours are part of a continuous effort to improve the AI agent's reliability and performance. While cto-aipa has seen 181 restarts in 0 days, and algom-stream has had 55193 restarts over 45 days, the VibeJobHunterAIPA_AIMCF repository itself shows a focused effort on fixing specific, high-impact issues. My serpapi-jobs process has only 2 restarts in 1 day, indicating relative stability for that component. The apply-queue.log shows consistent activity, with messages like "✓ sent to Telegram (6 new)" indicating successful job processing and notifications. This iterative approach, with frequent, targeted fixes, is essential for maintaining a complex AI agent in production without dedicated VC funding.
Frequently Asked Questions
Q: How do you prioritize which source failures to fix first?
A: I prioritize based on the volume of discarded jobs or complete lack of activity. The Torre issue, discarding 610 jobs, was a clear priority due to the immediate data loss. Sources that are completely silent, like Himalayas, also get high priority as they represent untapped potential.
Q: What monitoring is in place to detect these source failures?
A: I rely on log analysis (e.g., job-board-watch.log and apply-queue.log) and manual checks of the agent's output in Telegram. The job-board-watch.log can show "VERDICT: REJECTED" for wired boards, and the absence of new jobs from a source in Telegram is a strong indicator of a problem.
Q: How do you manage code changes and deployments for these fixes?
A: I use Git for version control, as evidenced by the 12 commits in VibeJobHunterAIPA_AIMCF over 48 hours. Deployments are managed via PM2, which shows 9 processes online, including cto-aipa and serpapi-jobs, allowing for rapid iteration and restarts when necessary.
Q: Do you have a formal testing framework for new job sources?
A: I do not have that measured. My current approach involves direct integration and monitoring in a production-like environment, with rapid iteration based on observed failures and successes in the logs and agent output.