Agents are applying for jobs: building an open protocol for hiring

Agent candidates are real candidates

Hiring is stuck in what Greenhouse CEO Daniel Chait calls an AI doom loop. Candidates pay about $20 for tools that fire applications at every open role, Greenhouse jobs now average around 254 applicants each, and both sides answer with more AI.

Most employers respond by blocking or slowing the bots. But behind nearly every agent is a person who wants a job, and 80% of job seekers already use AI in their search. Blocking the agent doesn't remove that person. It makes them invisible, and it throws away the one thing hiring is short on: signal. (It also may eliminate great hires from your pool).

Agent candidates should be first-class citizens in hiring, with a documented way in, a way to prove whom they act for, and a way to hear back. That's what the Open Job Context Protocol (OJCP) is for, and it's built on the tools the agent ecosystem already uses: MCP on the server and WebMCP in the browser.

Hiring needs a shared language

OJCP is a proposed open standard for how AI agents discover, evaluate, and apply to jobs. It defines six MCP tools (search_jobs, get_job_detail, get_employer_context, begin_application, submit_application, and check_application_status), the schemas they exchange, and a manifest at /.well-known/ojcp.json that tells agents where to find them. Only search_jobs is required to start, and it layers over existing job feeds and apply flows rather than replacing them.

(Full transparency: I wrote the first draft, and Recruitics (where I work) is the founding sponsor. A steering committee governs the spec, with members including Workday, Cross Country Healthcare, LoopCV, HiringCafe, aiApply, scale.jobs, and Tink. It's openly, freely licensed and actively developed by an open community.)

"Industries often have specific needs where common protocols can provide value. Built on top of existing layers, I see OJCP as a promising application of the agentic web for hiring."

Andrew Nolan, co-creator of WebMCP

The problems it solves

Blocking is a blunt instrument. Blocking often relies on what traffic claims to be, and bots can misrepresent themselves. Thales found 41% of bot attacks pose as Chrome. A blocked agent goes back to scraping pages and guessing at form fields, and recruiters still can't tell a candidate's agent from a spam bot. OJCP gives agents an official route in, one that can carry intent, consent, and identity with an application.

Candidates can check progress. Where providers support it, check_application_status lets a candidate’s agent retrieve an application’s status. Fit scores can also come back with a rationale, giving candidates more visibility into how a match was assessed.

Employers get signal, not just volume. Applications arrive structured, tied to an identified agent, with the candidate's consent and a qualification rationale attached, so recruiters can route and prioritize them.

Agent builders write one integration, not hundreds. Any MCP client can call any OJCP provider and get typed results instead of scraped HTML that breaks with every redesign.

Compliance teams get an audit trail. Every agent application records who sent it, for whom, and under what consent.

How it works on MCP and WebMCP

OJCP decides which tools exist for hiring and what they exchange, and runs the same tools on both surfaces. It does not add a new transport or SDK. MCP already gives agents typed tools with input and output schemas, and WebMCP already lets a web page expose those tools to an agent in the user's own browser.

On the server, a provider's manifest points agents at an ordinary MCP endpoint, and each tool's schema maps directly onto MCP's own, so any MCP client gets typed results. You can try it now at https://ojcp.dev/api/mcp.

OJCP also has an optional agent identity layer. Agents sign every request and publish their keys on a domain they control, so a provider can confirm an agent is who it claims to be before trusting it with anything that matters.

In the browser, WebMCP lets a careers page expose the same tools to an agent working in the candidate's own session. The simplest place to start is the apply form itself:

<form toolname="begin_application"
      tooldescription="Apply to this role at Acme Corp."
      action="/apply" method="POST">
  <input name="full_name" toolparamdescription="Candidate full name" />
  <input name="email" type="email" toolparamdescription="Contact email" />
  <button type="submit">Apply</button>
</form>

WebMCP keeps a human in the loop by default. The agent fills in the fields, and unless the form opts into automatic submission, the candidate’s human finger still presses Apply. That provides an explicit user review and submission step in the browser.

Trust without passing personal data

With OJCP, search stays open to any agent. Anything that moves candidate data requires the agent to identify itself and carry the candidate's consent, and each piece builds on an existing standard:

• Verified agents. Agents sign requests with HTTP Message Signatures on the Web Bot Auth profile, so a provider can tell an accountable agent from an anonymous scraper.
• Real postings. Providers sign their manifests, and each job carries an official_job_url a candidate can check against fake listings.
• Scoped consent. Agents share only what the candidate's consent covers, and fit scoring can run on resume embeddings instead of the resume itself (note that embeddings can reveal textual meaning, so it's an obscurity measure not private).
• Verified people, when needed. For regulated roles, an identity verifier such as ID.me or CLEAR can send the provider a signed proof, never the ID document.

Adoption so far

OJCP already runs well beyond the company that started it. Three independent teams have shipped implementations: a commercial job search product, an open-source job aggregator, and an open-source job search tool. The aggregator alone fronts an index of roughly 4 million postings, and across commercial and open-source providers, millions of jobs are reachable through the protocol today. Enterprise interest is growing as well, with implementation conversations already underway.

On the agent side, three candidate-side and auto-apply tools hold seats on the steering committee, an AI recruiting platform is evaluating OJCP for both its customers’ career pages and its own apply agent, and a public conformance suite lets any provider check its implementation against the spec.

Build the front door

Agents will reach your jobs either way. You only choose which door they use: a structured one with verified identity, consent, and a status channel, or a side window full of scraped listings and applications nobody can trace.

To try OJCP, point any MCP client at https://ojcp.dev/api/mcp or add the WebMCP attributes to a test apply form. Getting started is extremely accessible. A read-only provider needs a manifest and one tool serviced from an MCP server.

You can find the spec, Discussions, and ADOPTERS.md all live on GitHub. Would love to hear your thoughts and you can message me if you are interested in contributing 🙂

Whoever agents can talk to wins. Fixing hiring is going to take all of us.

Austin Anderson is CTO at Recruitics. He previously led engineering teams at LinkedIn. Find him on LinkedIn and X