OJCP is trying to fix the mess of AI agents applying for jobs

PromptCube Advanced 2h ago 579 views 1 likes 2 min read

Scraping career pages with Playwright or Browser Use is a fragile nightmare that breaks the moment a UI element shifts or a bot-blocker kicks in. Right now, we're in this weird loop where AI writes the resumes and another AI scores them, while employers get drowned in low-quality applications. The core problem is that the web wasn't built for agent-to-server job applications; it was built for humans clicking buttons.

OJCP (Open Job Consumption Protocol) aims to standardize this. Instead of fighting with ATS forms, it uses MCP tools for searching and applying. It relies on a manifest located at /.well-known/ojcp.json so agents can actually locate providers without guessing, and it leverages schemas that extend schema.org rather than trying to reinvent the wheel.

Solving the trust and authorization gap

A common argument is that LLMs are getting smart enough to just "figure out" any form, so why bother with a protocol? The issue isn't intelligence; it's authorization. An agent can mimic a human filling out a form, but it can't inherently prove consent or verify its identity to an employer. A more capable agent is essentially a more capable impersonator.

OJCP handles this by implementing a trust layer:

  • Request Signing: Agents sign requests using methods already standardized by OpenAI and CloudFlare.
  • Provider Verification: Providers sign their manifests, allowing agents to verify them via JWKS.
  • PII Control: Trust tiers determine exactly how much personally identifiable information (PII) is shared with a specific provider.
  • Consent-Based Validation: Browsing job data is free and open, but the verification "cost" only hits when a formal interaction or submission occurs.

For anyone wanting to see this in action, the playground on their site is a live MCP endpoint, which makes it a great starting point for a deep dive into how LLM agents can interact with structured job data without the fragility of browser automation.

This approach moves us away from the "brute force" method of AI workflows—where we just throw more tokens at a scraping problem—and toward a structured AI workflow where the server and the agent speak the same language. It's a necessary shift if we want to stop the arms race between bot-blockers and application agents. For those building a custom LLM agent for career services, integrating a protocol like this is much more sustainable than maintaining a library of CSS selectors that change every two weeks.

LinkedInOJCPRecruitics

All Replies (3)

M
Max75 Advanced 2h ago
Does this handle shadow DOM elements well, or do you still have to write custom selectors?
0 Reply
D
Drew15 Expert 2h ago
Forgot to mention the ATS side; they're already deploying bot-detectors to filter these out.
0 Reply
A
AlexHacker Expert 2h ago
Had this happen last week—my script broke after a tiny CSS change and missed three deadlines.
0 Reply

Write a Reply

Markdown supported