Job Agent

Overview

Job Agent is a personal job-discovery and application-workflow project, still in development. It combines ATS integrations, browser automation and saved workflow state. It also includes a coding-agent workflow for implementing and reviewing changes in separate Git worktrees. What I built: Python orchestration, Playwright/Chrome CDP workflows, SQLite state tracking and execution controls, plus the Cursor/Codex review workflow. The source is private; no application records or operational screenshots are shared here.

Two workflows, two kinds of control

Application automation needs to distinguish a known outcome from an uncertain one. The implementation includes execution leases, bounded retries, duplicate-submission safeguards, explicit outcome tracking and human handoffs. Their presence does not prove correctness. AI-assisted development uses isolated Git worktrees, implementation/reviewer stages and acceptance checks. I inspect changes and integration gaps before accepting the result.

Engineering decisions

Persist what happened. SQLite-backed state makes workflow progress and uncertain outcomes explicit instead of relying on a browser's current appearance alone.
Bound attempts. Retry and handoff logic define when automated execution should stop and require attention.
Separate implementation from acceptance. Worktree isolation and independently rerun checks make an agent's claimed completion something to inspect.

Engineering details, reliability and next steps

The challenge: an action can have an ambiguous result

A browser interaction can complete while its confirmation is unclear. Treating uncertainty as permission to repeat an action can create duplicates. The code therefore contains outcome tracking, submit-once checks and reconciliation/handoff paths. The effectiveness of these safeguards still depends on the specific integration and observed runtime behavior.

How I use coding agents here

The orchestration code separates planning, implementation, review and acceptance. Review stages inspect evidence; acceptance code reruns bounded commands and records mismatches or timeouts. This is the implementation basis for the Plan → Implement → Review → Test → Validate practice shown on this site.Tests and generated suggestions also need scrutiny. I do not treat the presence of a test file or a passing agent summary as evidence that a feature has been independently verified.

Testing and reliability

Read-only review found lease/concurrency self-tests and acceptance-check implementation, alongside regression and browser-workflow checks. These project tests were inspected, not executed during the portfolio update. No live application workflow, user account or submission was used for this case study.

Current state and limitations

Active development with private source. No production-readiness claim, success-rate claim, duplicate-prevention guarantee or measured productivity improvement is made. Private application data, account information, sessions, employer records and source code are deliberately excluded.

Future improvements

A shareable fixture-only execution walkthrough, documented failure cases and reproducible acceptance results would strengthen public evidence. They remain future work. For V1.1, I chose the public DevGraph chunking lab as the more inspectable demonstration.

Evidence scope

The description combines my October 2026 CV with read-only inspection of the private orchestration, acceptance and execution-control modules. There is no public repository or live demo link to publish for this project.