Problem statement
JobSync can save jobs through several paths, including the manual job form, agent chat, MCP, and discovery automations such as Greenhouse and Lever. These paths do not currently expose one supported lifecycle point for running an evaluation after a job has been persisted.
MCP-created jobs with a usable description may already return instructions asking the calling agent to produce and save a resume match. That is useful for MCP callers, but it does not cover jobs created through the manual UI, agent chat, or discovery automations. External integrations also cannot reliably discover which persisted jobs still need an evaluation, claim that work without duplication, or record retryable failures.
This makes source-independent automation difficult. An integration either has to duplicate evaluation logic inside every ingestion path, poll unsupported database internals, or risk duplicate and stale results.
Proposed solution
Provide a supported automatic evaluation lifecycle or integration point for persisted jobs with substantial descriptions.
The product behavior could be implemented natively or exposed for an external worker, but should allow JobSync to:
- identify persisted jobs that need a configured evaluation, regardless of ingestion source;
- process evaluation asynchronously so job creation is not blocked;
- prevent duplicate processing during retries or overlapping workers;
- retain the evaluator/version and the job/resume inputs used for a result;
- mark older results stale when relevant job, resume, or evaluator inputs change;
- expose failed evaluations for retry and troubleshooting;
- preserve existing resume-match behavior and discovery metadata rather than overloading them with unrelated evaluation types.
A narrow authenticated API or lifecycle hook would be sufficient if JobSync does not run the evaluator itself. The important product capability is a durable, source-independent boundary around "job saved, evaluation pending/running/completed/failed."
Alternatives considered
- Keep evaluation in each ingestion path. This duplicates behavior and still misses manual or newly added paths.
- Use the existing MCP match instruction only. This works for cooperative MCP callers but does not cover non-MCP imports and is not a durable background-work contract.
- Poll the SQLite database directly. This couples integrations to private schema details and bypasses JobSync's ownership, validation, and concurrency rules.
- Use the manual match action. This remains useful for on-demand resume matching but does not provide automatic, source-independent processing.
Expected outcome
After any supported ingestion path persists an eligible job, JobSync can either evaluate it automatically or safely hand it to an authenticated worker. Import succeeds independently of evaluation, retries do not create duplicate current results, and changes to the relevant inputs make the prior result visibly stale or enqueue a replacement.
Problem statement
JobSync can save jobs through several paths, including the manual job form, agent chat, MCP, and discovery automations such as Greenhouse and Lever. These paths do not currently expose one supported lifecycle point for running an evaluation after a job has been persisted.
MCP-created jobs with a usable description may already return instructions asking the calling agent to produce and save a resume match. That is useful for MCP callers, but it does not cover jobs created through the manual UI, agent chat, or discovery automations. External integrations also cannot reliably discover which persisted jobs still need an evaluation, claim that work without duplication, or record retryable failures.
This makes source-independent automation difficult. An integration either has to duplicate evaluation logic inside every ingestion path, poll unsupported database internals, or risk duplicate and stale results.
Proposed solution
Provide a supported automatic evaluation lifecycle or integration point for persisted jobs with substantial descriptions.
The product behavior could be implemented natively or exposed for an external worker, but should allow JobSync to:
A narrow authenticated API or lifecycle hook would be sufficient if JobSync does not run the evaluator itself. The important product capability is a durable, source-independent boundary around "job saved, evaluation pending/running/completed/failed."
Alternatives considered
Expected outcome
After any supported ingestion path persists an eligible job, JobSync can either evaluate it automatically or safely hand it to an authenticated worker. Import succeeds independently of evaluation, retries do not create duplicate current results, and changes to the relevant inputs make the prior result visibly stale or enqueue a replacement.