Case Study: Automating a Job Search With an Agentic Workflow

Where the previous case study was a hosted, provider-agnostic financial system, this one is deliberately different in almost every dimension: a personal, fork-and-own framework for job applications, built natively on one specific coding agent rather than abstracted across providers, with no sandboxed execution environment at all. The contrast between the two case studies is itself instructive — there is more than one legitimate way to apply the same underlying concepts, depending on what the system is actually for.

A repository built from the primitives

The structure of this system maps directly onto vocabulary introduced earlier in this series. A project-instructions file holding the candidate's profile is the standing-instructions layer. A set of commands — /setup, /scrape, /apply, and others — are the deterministic triggers a person invokes explicitly. A packaged skill handles the job-application procedure itself. And a set of portal tools provide direct bindings to the job sites and services the system interacts with. Every layer in this repository is a concrete instance of a concept already covered in the abstract.

The /apply workflow, step by step

The centerpiece is a single command, /apply, that chains together a deterministic gate, an explicit trust boundary, and a non-deterministic drafter-and-reviewer loop. It fetches and parses a job posting and, critically, treats that posting as untrusted data, never as instructions, so that any directive accidentally or deliberately embedded in a posting — a classic prompt-injection vector — is simply ignored by design. It then evaluates fit and presents that evaluation to the user before drafting anything at all. Only after that does a user-approval gate arrive — the one deterministic step in the whole flow, where the user explicitly approves proceeding or stops the run outright. Once approved, a drafter agent writes a tailored CV and cover letter using the candidate's active template, and an isolated reviewer — a fresh-context subagent that researches the company independently and critiques the draft without inheriting the drafter's assumptions — checks the result and sends it back for revision if needed, looping until satisfied.

Two decisions worth calling out specifically

The explicit trust boundary at the very first step deserves particular attention, because it's a concrete answer to a real and common security concern: an agent that reads job postings from the open internet is, by definition, reading untrusted content, and this system's design treats that content strictly as data to extract information from, never as a source of instructions to follow — closing off an entire class of prompt-injection risk at the architectural level rather than hoping the model simply behaves.

The isolated reviewer is the second detail worth dwelling on, because it's the context-isolation concept doing exactly the job it was designed for: a reviewer sharing the drafter's own context would simply inherit the drafter's assumptions and blind spots, effectively rubber-stamping its own work. Giving the reviewer a genuinely fresh context is what makes the review a real check rather than a formality.

A deliberately different deployment posture

Where the trading system spans multiple providers with no single point of lock-in, this system is coding-agent-native by design, run through a specific CLI with no multi-provider abstraction layer at all — a considered trade-off rather than an oversight, appropriate for a personal, fork-and-own tool one person clones and customizes for themselves, rather than a multi-tenant production service. Similarly, there is no sandboxed execution environment; enforcement is entirely instruction-level, resting on the trust boundary and standing rules described above rather than on infrastructure-level isolation. Both choices make sense for what this system actually is, and both would likely be the wrong choice for a different system with different requirements — which is, in the end, the lesson every case study keeps returning to: there is no universally correct architecture, only a set of well-understood trade-offs to make deliberately, for the specific problem in front of you.