The Six Unsolved Layers of AI-Mediated Hiring (and Why Your ATS Isn't Filling Them)

The hiring market is running at higher pressure than any previous era. Applications per role have risen from ~28 in 2021 to ~95 in 2025 — a 239% increase. AI agents auto-apply on the candidate side. AI screeners, sourcers, and interview scorers act on the employer side. Both sides are now partly synthetic; both sides routinely get flagged for fraud; both sides run into systems that don't talk to each other.

And yet — despite $2.8B in agentic-AI VC funding through H1 2025 alone — the infrastructure that should connect all of this remains absent. There is no protocol layer. No universal job format agents can parse. No trust protocol between systems. No interoperability between the 60+ ATS products in market. Hiring in 2026 is structurally analogous to payments in 2010: fragmented, manual, disconnected, and waiting for its Stripe.

OpenRole's thesis — and the frame we use to map every product decision — is that there are six specific unsolved infrastructure layers underneath AI-mediated hiring. Whoever solves them owns the category. This post explains each layer, why no incumbent has filled it, and what OpenRole is specifically building toward.

Layer 1: Authentication

The problem: there is no way to verify that an AI agent is authorised to act on behalf of a specific candidate or employer.

Today, when a candidate-agent platform like Massive or LazyApply submits 200 applications on behalf of a candidate, the employer has no cryptographic way to confirm the candidate authorised that submission. When an AI sourcer emails a candidate on an employer's behalf, the candidate has no way to verify the sourcer actually speaks for the employer. The entire interaction runs on trust-by-email-address.

Google's A2A protocol exists for generic agent-to-agent authentication but has no hiring-specific implementation. No one has productised "the agent verification layer for hiring." Until someone does, every agent interaction in hiring has a fraud surface proportional to the number of agents involved.

Layer 2: Standardisation

The problem: there is no universal, agent-readable job format.

Schema.org/JobPosting exists and is widely implemented, but it wasn't designed for agent consumption. It's sufficient for "show this role on Google Jobs" but insufficient for "let my candidate-agent decide whether to apply, compare offers, and schedule interviews." Critical fields for agent reasoning — interview process structure, specific working conditions, verification claims, response SLA — aren't in the spec.

Every ATS implements its own extensions. Every careers page emits a slightly different JSON-LD. The result: agents have to parse and reconcile dozens of variant formats, and the resulting reasoning is brittle.

The layer that's missing is an extended job format — Schema.org/JobPosting plus hiring-specific fields plus a signed attestation layer. This is actively being sketched in standards bodies but not yet productised.

Layer 3: Trust

The problem: there is no attestation that an application, a candidate, or an employer is genuine.

This is the deepfake/fraud layer. 1 in 3 hiring managers have caught fake identities in interviews. Amazon has blocked 1,800+ North Korean applicants. Fake employer listings ("ghost jobs") make up ~30% of some categories. There's no shared trust layer — every participant in the hiring market runs their own anti-fraud in isolation.

The right primitive here is verifiable credentials for both sides. W3C VCs exist as a standard but are not integrated into hiring workflows at any scale. Velocity Network is working in this space but remains niche.

What's needed: a pragmatic, industry-wide trust layer that doesn't require everyone to adopt W3C VCs overnight but uses lighter primitives (signed badges, dated audit attestations, cross-model consistency checks) to raise the trust floor. This is where OpenRole's audit/attestation stack operates — not the whole answer, but the beginning of the employer-side piece.

Layer 4: Interoperability

The problem: 60+ ATS platforms, each with different schemas, auth models, rate limits, and write permissions. They don't talk to each other. There is no Plaid for ATS.

The write side is especially broken. Applications, status updates, rejection reasons, interview schedules — these move between systems only via email or manual copy-paste. No agent can submit an application to 10 different ATS products via a unified API. No candidate can track their status across Greenhouse + Lever + Ashby + Workday in one place without plumbing.

Unified.to and Merge are building this on the read side (pulling data out of ATS products). The write side — the actual agent-to-ATS application submission — remains fragmented. This is the layer that needs the most concentrated engineering work, and it's the layer with the clearest "Plaid analogy" — someone will build it, and the value will accrue to whoever does.

Layer 5: Credentials

The problem: there's no way to carry verified credentials (education, employment, certifications, identity) from system to system.

If you're verified in LinkedIn's Identity system, that verification doesn't transmit to a careers portal. If you have a verified degree in Parchment, it doesn't propagate to an ATS. If your previous employer verified your employment via The Work Number, that attestation is siloed.

W3C Verifiable Credentials finalised the spec years ago. Velocity Network has built an implementation. A handful of enterprises have integrated. But at the hiring workflow level, candidates and employers still exchange photocopies of passports, manually verify references by phone, and re-attest the same facts across every application.

The adoption barrier is chicken-and-egg. Candidates don't bother acquiring VCs because no employer requires them; employers don't require them because no candidates have them. What breaks this is usually an infrastructure actor that can bootstrap both sides simultaneously — or a regulator that mandates them.

Layer 6: Semantics

The problem: skills ontologies are vendor-specific with no universal standard.

Every major ATS and every AI screener maps skills differently. "Python" and "Python 3" and "Python (3+ years)" get hashed to different skill IDs across systems. ESCO (European Skills, Competences, Qualifications and Occupations) and O*NET (US Occupational Information Network) exist but are regional and only partially overlapping.

When a candidate-agent reasons about fit between a candidate's skill set and an employer's requirements, it has to resolve across mismatched ontologies. The result is sloppy matching at scale — the same problem ATS keyword filtering has had for 15 years, now inherited by AI agents at higher volume.

A universal hiring ontology is a 3–5 year standards effort. In the interim, the winning approach is ontology-agnostic semantic matching via embeddings — which several vendors are working on but none own as a shared infrastructure service.

Why no ATS will solve this

The obvious question: ATS vendors control hiring workflows. Won't they solve the six layers?

Three structural reasons they won't:

1. ATS products are walled gardens by design. Their business model depends on employer lock-in. Opening to interoperability reduces switching costs, which reduces pricing power. A vendor that aggressively interoperates cannibalises its own moat.

2. The six layers are primarily cross-employer, not single-employer. An ATS is built to serve one employer's workflow. Trust, standardisation, and interoperability require coordination across employers and across systems. That's not what ATS architectures are optimised for.

3. Neutrality matters. The role that has to be filled here is structurally like Stripe, Plaid, or Twilio — a neutral layer that no marketplace participant can credibly occupy. An incumbent HR tech vendor is perceived as partisan; a neutral infrastructure actor is the only kind that both sides will adopt.

This is why the protocol layer for hiring will be built by a company that is not an ATS, not a job board, and not a marketplace. It will look more like Stripe than like Workday.

The five platform analogies worth studying

When thinking about what wins in infrastructure plays like this, five companies are the right references:

All five share one pattern: solve one specific problem extraordinarily well, with developer-first self-serve economics, and let the network effect compound. Not "we do everything." Not "we replace the incumbent." Specifically: become the neutral rails that the incumbents' customers route through.

What OpenRole is building toward

The honest version: OpenRole doesn't solve all six layers today. What OpenRole ships in 2026 is the beginning of Layer 3 (Trust) — employer-side verifiability via the audit, the badge, the pixel, and the attestation history. That's one piece of one layer.

The roadmap extends from there. Near-term (6 months): expose the audit data as a public API; ship signed, machine-verifiable badges; add agent-vs-human pixel instrumentation. Medium-term (6–18 months): MCP server exposing employer data to agents; agent authentication primitives; partner integrations with ATS vendors. Longer-term (18–36 months): the trust layer matures into the interoperability hub where candidate-agents and employer-side systems route.

Whether OpenRole ends up solving all six layers, two of them, or becoming the trust-layer component of a multi-player infrastructure set is a 2027–2028 question. What matters now is that the gap is real, it's large, and whoever closes even one layer cleanly has a defensible position.

What employers should actually do about this today

Reading a "six unsolved layers" post and nodding is not a plan. Here's what's actionable right now:

1. Make yourself agent-readable. The investments in schema, llms.txt, and structured data are the same regardless of which company ends up winning the infrastructure layer. Early adopters compound into whatever stack emerges.
2. Invest in attestation early. Run monthly AI visibility audits, archive the results, build a dated history. That history is the trust-layer input whatever protocol eventually wins.
3. Track which ATS vendors start opening up. Interoperability moves will become a procurement differentiator in the next 24 months. An ATS that publishes a well-designed write API will pull ahead of closed competitors.
4. Pilot agent-facing workflows. Accept applications from auto-apply platforms. Measure what quality difference you actually see. You'll learn faster than competitors still gate-keeping with human-form-only submissions.

Frequently Asked Questions

Q: Is this really that different from how hiring has always been?

A: Yes — quantitatively. 28 applications per role to 95 applications per role in 4 years is a regime change, not a trend. At 95+, human-in-the-loop fully breaks; agents have to mediate. That forces infrastructure the 28-era didn't need.

Q: Couldn't LinkedIn just become the protocol layer?

A: LinkedIn has the data but not the neutrality. It's a marketplace participant with its own sourcing and matching products; other platforms won't route through it without reluctance. History: the protocol layer has almost never been won by the largest marketplace participant (Visa, not Bank of America; Stripe, not Chase).

Q: Why would an ATS vendor cooperate with an infrastructure player?

A: Because employer customers will increasingly demand it. When candidates start preferring employers who interoperate, ATS vendors whose clients want to stay competitive will be forced to open up. The same dynamic that forced banks to accept Plaid: customers push.

Q: Is this thesis specific to UK/EU, or global?

A: Global, but the UK/EU is structurally well-positioned as an early market because of (a) the EU AI Act forcing compliance infrastructure adoption, (b) GDPR's emphasis on data rights, and (c) a concentrated set of regulators. OpenRole's UK focus is deliberately building in the market where the underlying regulatory tailwind is strongest.

Q: How long until the infrastructure layer crystallises?

A: Our estimate: 18–36 months from now (April 2026), rough candidates become clear by mid-2027, and the dominant player(s) emerge by late 2028. The window to build matters now — the employers and infrastructure actors who are already building have a 12–18-month lead.

Q: What's the single simplest move an employer can make today?

A: Publish Organization and JobPosting schema on your careers pages, allow AI crawlers, and run an AI visibility audit monthly. Free, under a week of technical work, and sets you up for whatever infrastructure layer emerges.

---

Run a free audit — the first step in the path this post describes.

Related reading:

• Agent Readiness Score
• Deepfake Candidates & Employer Verification
• The EU AI Act August 2026 Deadline
• Glossary: Agent Readiness Score