DEV Community: Alexander Leonhard

Why building a job scraper for $0.39/1,000 jobs is not about the money.

Alexander Leonhard — Tue, 14 Apr 2026 13:28:14 +0000

I needed thousands of job postings in OJP v0.2 schema. Not a handful for a demo — enough volume that cost per posting had to disappear as a line item.

The existing options didn't work for me. Commercial scrapers price per-posting at numbers that assume you're an ATS vendor passing the cost to customers. Open-source ones want you to write a custom adapter per career page, which is its own slow failure mode. Neither fits what a protocol layer actually needs: cheap, fresh, and structured the same way across every board.

So I built my own in a single session. One production run: 887 postings across 4 boards.

Metric	Value
Cost	$0.39 / 1,000 postings
Throughput	3.9s / job
Success rate	77% raw, 95%+ after retry

Most of the "hard" parts weren't the LLM. The LLM call is the cheap part. Everything around it is where the cost and the success rate actually live.

The architecture

scrape-jobs.json (queue + status)
        │
        ▼
┌─────────────────────────┐
│ Playwright browser      │  ← stealth context, one per worker
└─────────┬───────────────┘
          │
   fetch + strip HTML → ~6K tokens of clean text
          │
          ▼
┌─────────────────────────┐
│ Gemini Flash-Lite       │  ← ~$0.0004/call
│ (OJP v0.2 extraction)   │
└─────────┬───────────────┘
          │
   sanitize + validate (JSON Schema)
          │
          ▼
     results.json

BFS queue. Listing pages discover individual posting URLs, add them as pending, and the loop runs until empty. Status lives in the input file itself so runs resume cleanly after a crash.

Five fallback layers, each kicks in when the previous fails: DOM link scraping → heuristic job-container detection → visual navigator (screenshot + vision model picks clickable selectors) → schema sanitizer → full vision retry on extraction failures.

The five things that moved the numbers

1. Content hashing so reruns are free

Every fetched page gets a SHA-256 of its stripped text. If the hash matches the last scrape, skip the LLM call entirely — no tokens, no cost.

On a weekly re-crawl, 95% of URLs hash-skip. Only actual job edits re-extract. This is what makes the whole thing viable as a recurring pipeline rather than a one-shot.

2. Stealth Playwright to beat bot detection

Realistic user-agent + viewport + timezone, --disable-blink-features=AutomationControlled, and an init script that hides the navigator.webdriver flag most bots forget about. Gets past the common bot-detection layers on 4/5 boards.

One ATS in my test set still blocks with a full CAPTCHA challenge. That one's on the list.

3. Per-worker parallelism partitioned by domain

Partition pending URLs by board domain so workers don't step on each other. If one domain dominates the queue (say, 400 URLs on one board vs. 20 on another), split the big one across shards and interleave the URLs so early items spread across all workers. One Chromium instance per thread, no shared state to debug at 2am.

This matters more than the raw worker count. Naive round-robin parallelism on a queue-mixed stream fights itself — you end up with every worker holding a connection to the same board.

4. A sanitizer that absorbs LLM schema drift

Gemini Flash-Lite is cheap but will happily return "manager" for a seniority enum that only accepts "lead", or "other" for a language code that must be ISO 639-1. The reframe: stop trying to prompt-engineer the model into perfect schema compliance. Assume it will drift. Catch the drift deterministically before validation.

What the sanitizer actually does:

Maps enum synonyms to canonical values (manager → lead, intermediate → mid, graduate → junior, chief → c_level)
Normalizes language names to ISO 639-1 (english → en, deutsch → de)
Moves misplaced fields into the right nesting (LLMs love putting skills at the root instead of under must_have)
Strips nulls because the schema has additionalProperties: false

Took success from 77% → 90%+ on the same input without changing the prompt or the model.

5. Vision-retry for the last 10%

When text extraction fails — an SPA rendered nothing parseable, or Gemini Lite returned invalid JSON even after sanitization — re-run with a full-page screenshot through Gemini Flash vision.

Recovered 4/20 retries at $0.0037 per recovered posting. Boards where text stripping returned 0 chars become viable because Playwright still renders the page. Vision sees what the user sees.

One nuance worth noting: Flash-Lite has weaker vision grounding, so the retry path specifically uses gemini-flash-latest even though the primary extraction uses Lite.

The validated cost model

Layer	Per call	Per 1K postings
Fetch (Playwright)	free	~3s compute
HTML stripping	free	local
Extraction (Flash-Lite text)	$0.0004	$0.39
Visual nav discovery	$0.0006	$0.003 per hard board
Vision retry	$0.0007	$0.015 per 20 retries

End-to-end at scale including retries: ~$0.42 / 1,000. That's ~$4 per 10K, ~$40 per 100K.

Every run writes a frozen stats-{timestamp}.json with extraction and vision cost tracked separately, so I can diff regressions between runs. A cumulative stats.json merges at the end of each run — single-writer, no race conditions across parallel workers.

Gotchas I paid for

Playwright base image version must match the playwright pip version exactly, or headless Chromium fails with Executable doesn't exist
Read/modify/write of shared stats from parallel workers creates race conditions — use per-run files and merge once at the end
Boards with locale prefixes (/en_US/jobs/..., /de_DE/jobs/...) create duplicate URLs that inflate extractions 10× unless you normalize during link discovery
Gemini Flash Lite's vision grounding isn't good enough for retry — hardcode the larger model for screenshots
Screenshot-based vision on heavy SPA boards works even when text stripping returns 0 chars, because Playwright still renders the page

What this is really about

The cost target wasn't the point for me. Sub-cent per posting is a useful headline, but it's a side effect.

The point is that once extraction gets this cheap and this structured, the scraping step stops being a moat. Anyone who wants job data at scale can get it. What remains valuable is the schema you extract into — OJP in my case — and the protocol layer that makes those extractions interoperable across every agent and every board.

I'm building ADNX because the next generation of hiring doesn't run on recruiter tools. It runs on agent-to-agent transactions against domain protocols. Job ingestion at $0.39/1K is just the plumbing. The interesting work is what structured hiring data enables once it's cheap enough to be ambient.

If you're working on anything adjacent — agent protocols, domain-specific extraction, A2A patterns — ping me. Always looking to compare notes.

Stack: Python 3.12, Playwright 1.58, google-genai SDK, jsonschema, Docker.

I tried Claude's Managed Agents: built a job scraper & conversion to an agent ready protocol.

Alexander Leonhard — Thu, 09 Apr 2026 13:46:01 +0000

Anthropic launched "Managed Agents" yesterday - So I built one.

The Agent scrapes career pages autonomously - point it to a URL and it starts the job — tried with Personio, Stripe, Vercel — parses the listings, and converts them into OJP — Open Job Protocol, a structured JSON schema designed for machines, not humans.

Stripe alone had 100+ listings across 9 pages. Vercel had ~75. I ran 40 through the full pipeline: access --> scrape --> parse --> convert --> validate --> expose on adnx.ai

Total cost: over $5 in LLM inference. That's roughly $0.13 per job just to turn unstructured HTML into a structured format (using Sonnet 4.6).

That's too expensive. I'll get into why that number matters. But first — the part that surprised me.

The whole thing took about 2 hours

Not because I'm fast. Because the tools are commoditized now.

Claude did the setup and debug work. I scoped what I want.

Claude Managed Agents are priced at $0.08 per session-hour. MCP is supported by Claude, ChatGPT, Copilot, Cursor, LangChain — basically everything. You can spin up an agent that connects to real tools, works with real data, and does real work in an afternoon. Not a demo. Not a mockup. A working system.

Two years ago, building something like this would've been a multi-week project. Custom integrations, bespoke tooling, glue code everywhere. Now it's an MCP server, a prompt, and a few hours of iteration.

Two months ago, this would still require a lot of back and forth, patching tooling and infrastructure.

The infrastructure to build agents isn't the bottleneck anymore. The question has shifted from "can you build an agent" to "what does your agent actually operate on and do?"

What this agent does

It hits career pages, whatever URL you point it at — extracts listings, and converts each one into an OJP object.

Here's what a run with a batch of 10 looked like:

#	Title	Org	OJP ID	Validation
1	Backend Engineer, Core Technology	Stripe	`a3f7e1c2…`	✅ VALID
2	AI/ML Eng. Manager, Payment Intelligence	Stripe	`b4e8f2d3…`	✅ VALID
3	Android Engineer, Terminal	Stripe	`c5f9a3e4…`	✅ VALID
4	Backend / API Engineer, Billing	Stripe	`d6a0b4f5…`	✅ VALID
5	Account Executive, AI Sales	Stripe	`e7b1c5a6…`	✅ VALID
6	Software Engineer, AI SDK	Vercel	`f8c2d6b7…`	✅ VALID
7	Software Engineer, CDN	Vercel	`a9d3e7c8…`	✅ VALID
8	Engineering Manager, AI Gateway	Vercel	`b0e4f8d9…`	✅ VALID
9	Senior Product Security Engineer	Vercel	`c1f5a9e0…`	✅ VALID
10	Software Engineer, Agent	Vercel	`d2a6b0f1…`	✅ VALID

10 out of 10 valid. Each one is a structured OJP object — requirements, compensation, location, skills, work authorization, remote policy, about 30 fields that matter for matching.

Not a scraped blob of text. A machine-first representation of a job that any agent speaking OJP can evaluate against a talent profile, run constraint matching on, and make decisions with — without burning tokens on parsing and interpretation every time.

The difference between handing an agent a PDF and handing it a structured API response. One requires understanding. The other requires a schema lookup.

How to retrieve them?

POST https://sandbox.adnx.ai/api/v1/jobs/inquire { "ojp_id": "a3f7e1c2…" }

Try it on the sandbox via docs.adnx.ai

You have to seed some OJP listings yourself (WIP).

The cost problem is real and really expensive at scale

$5 for 40 jobs. At that rate, processing 10,000 listings costs $1,250. That's just the conversion step — before any matching, ranking, or agent-to-agent negotiation happens.

Job posts are duplicated on existing job platforms, so you can easily 3-5x.

The irony: most of the costs comes from the LLM interpreting and parsing unstructured HTML. The agent spends tokens to read and figure out what's a salary range, what's a requirement, what's marketing copy - it has to reason significantly.

If those listings were already in OJP, the conversion step wouldn't exist.

The cost drops to near zero for downstream agents, getting more efficient at scale and using batch API calls.

This is the token economics argument for domain-specific protocols in one screenshot and an exchange - optimized for agents.

Every agent in the hiring space is independently burning tokens to parse the same unstructured data into roughly the same structured representation. Multiply that across 100+ AI recruiting startups, each processing millions of listings, and you're looking at an industry-wide waste of compute that structured schemas would eliminate.

The research says structured context reduces token usage by 60-90% vs. unstructured input. My $5 for 40 jobs is a data point in that range. The conversion is the tax. The protocol is what eliminates it.

Who wins? Big-AI. Who pays? Employers or your margin!

Why I'm sharing this

Two reasons.

One: this is a proof of concept anyone can replicate. OJP is MIT-licensed. The tools to build this kind of agent are free or nearly free. You don't need to integrate into anything. You don't need API partnerships or sandbox access or a contract with an ATS vendor. You spin up an MCP server, point an agent at job data, and start converting.

No technical debt. No vendor lock-in. No integration overhead. Just a protocol and an agent.

That's the point of building at the protocol layer. When the tools are commoditized, the protocol becomes the leverage. Anyone can build on it. The value isn't in controlling the agent — it's in what the agents agree to speak.

Two: I want to be honest about what's not working yet. $0.13 per job conversion is not viable at scale. The protocol itself is solid — structured, evaluable, machine-first. But the bridge from the current unstructured world to the protocol world is expensive. That bridge cost will come down as models get cheaper and as more data originates in structured formats. But right now, it's the real bottleneck.

If you're building in this space, that's the gap worth looking at. Not "how do I build an agent" — that's solved. But "how do I get structured domain data into my agent's hands without burning a dollar per transaction on interpretation."

The bigger picture

The agent infrastructure is ready. MCP is everywhere. A2A is gaining traction. Claude Managed Agents just made deployment a one-liner. The frameworks, the runtimes, the coordination protocols — they exist and they work.

What's missing is the domain layer. The structured schemas that define what a "job" or a "talent profile" looks like in machine-first format. The transaction protocols that let agents negotiate, settle, and audit hiring decisions. The compliance infrastructure that satisfies EU AI Act requirements (enforcement starts August 2, 2026 — hiring is explicitly classified as high-risk AI) without bolting on governance after the fact.

That's what I'm working on. Not another hiring tool. The protocol layer underneath all of them.

Yesterday's agent is a proof point: with commodity tools and an open protocol, you can go from zero to a working system with real data in an afternoon. The cost curve is the remaining problem. But the architecture is right.

I'm building open protocol infrastructure for agent-to-agent hiring transactions (OTP/OJP, MIT-licensed). The agent I built yesterday is rough and the economics don't work yet — but it's real data, real protocol output, and zero integration debt. If you're working on similar problems in any domain, I'd like to hear what you're running into. LinkedIn | adnx.ai

The Internet Isn't Ready for Agents. Neither Is Your Business Model.

Alexander Leonhard — Sun, 05 Apr 2026 13:43:30 +0000

Earlier this year I spent weeks building an AI tool to help myself and others apply for jobs faster and more successfully. I failed and succeeded at the same time.

Failed — I didn't land a job myself. Succeeded — I learned to use Claude, shipped a production-ready SaaS app with AI features, and understood something fundamental about why this space is broken.

The tools one person can build within a few sessions can read and parse thousands of job listings. They could match requirements, tailor resumes, draft cover letters. But half the job boards blocked it outright. The other half demanded CAPTCHAs, SMS codes, email verification loops.

Which is why workarounds like Browser Plugins exist, to circumvent bot-protection layers, meant to make sure you are human.

The tools I build couldn't apply to a single job.

That's not a bug. That's the architecture. And then it clicked.

The web assumes you have a body

The entire internet authentication stack — from email verification to CAPTCHA to SMS codes — was designed around one assumption: users are physical beings. It was so obvious nobody questioned it. Every platform converged on the same pattern independently, pushed by bot spam, and accidentally created a hard boundary between entities that have bodies and entities that don't.

The result is a web split into two layers: an open read layer where agents roam freely, and a gated write layer that demands proof of physical existence to participate.

This matters more than it sounds.

If you're building anything that involves agents doing real work — not just answering questions, but negotiating, transacting, committing — you hit this wall fast. Your agent can analyze every job posting on the internet but can't apply to a single one. It can evaluate every talent profile but can't schedule an interview.
Read access without write access isn't intelligence. It's surveillance.

The "fix" that makes everything worse

You'd think the market would respond by solving this infrastructure gap. Instead, it responded with workarounds.

Tools like AIApply, EnhanceCV, and a dozen others now let job seekers auto-generate "tailored" resumes and blast hundreds of applications per week. AIApply claims 1.1 million users and 150+ applications per person per week. LinkedIn application volume spiked 45% in the past year alone.

I understand why these tools exist. The application process is broken, and people are frustrated. But here's what actually happened: instead of fixing the infrastructure, we gave humans AI-powered tools to brute-force through human-shaped forms faster. The agent still pretends to be a person. The form still pretends it's talking to one.

The result on the demand side is brutal. Recruiters are drowning in AI-generated boilerplate. Every resume looks the same. Every cover letter hits the same keywords. Cost-per-hire is going up. Time-to-hire is going up. The Greenhouse CEO called it an "AI doom loop" — applicants use AI to mass-apply, companies use AI to mass-filter, both sides get worse outcomes, and trust craters. Only 8% of job seekers believe AI screening is fair. 42% who lost trust in hiring blame AI directly.

These tools aren't solving the problem. They're making "AI in hiring" taste bad for the entire demand side. And the root cause is the same: they're operating ON broken infrastructure instead of replacing it.

The same structural problem breaks pricing
Here's where it gets interesting. The identity problem and the pricing problem share the same root cause: infrastructure designed around human assumptions.

Take flat-rate AI subscriptions. They were built for human interaction patterns — a person asks a few questions, gets a few answers, goes to lunch. A heavy user might make 20-50 API calls a day.

Then agents showed up. Background agents routinely hit 500-2,000+ calls overnight. They don't take lunch breaks. They don't get tired. They don't have the natural throttle that a human body provides.

The subscription model worked when usage correlated with having a body. One body ≈ one predictable usage pattern. Remove the body, the economics collapse. You get adverse selection: the heaviest agent users exploit flat pricing while moderate users subsidize them.

This is the same fault line. Human-shaped infrastructure meets non-human participants, and the mismatch isn't cosmetic — it's structural.

What this means if you're building in hiring

I work on agent infrastructure for hiring, so let me make this concrete.

The hiring industry runs on systems designed for humans clicking through interfaces. Every ATS, every job board, every screening tool assumes a person is on the other end making decisions at human speed. The entire workflow — post a job, collect applications, screen resumes, schedule interviews, negotiate offers — is designed around human attention as the bottleneck.

The auto-apply tools tried to speed up the human side. That just moved the bottleneck — now you've got 10x the volume with the same filtering infrastructure. When agents enter this workflow properly, two things need to work from the ground up:

Identity. A recruiting agent evaluating talent needs to be verifiable. Not "verified by a human who owns it" — verifiable on its own terms. The employer's agent needs to know it's negotiating with a legitimate recruiting agent, not a spam bot that scraped a resume database. Today, there's no standard way to do this. Every integration is bespoke, every trust relationship is ad hoc.

Economics. If an agent can process 1,000 talent evaluations in the time a recruiter handles 10, you can't charge per-seat. The unit of value shifts from "access" to "outcome." The business model that makes sense is transactional — you pay when an agent actually delivers a confirmed hire, not for the right to log in.
These aren't separate problems. They're the same problem: your infrastructure was built for bodies.

The uncomfortable next question

Most of the AI-in-hiring discourse right now focuses on the application layer. Better auto-apply tools. Smarter resume scanners. Faster interview scheduling bots.
The harder question is: should agents be filling out human forms at all?

Agent identity isn't a feature request. It's a prerequisite. Without verifiable agent credentials — not just "who owns this agent" but "what is this agent authorized to do, what has it done before, how did it perform" — you can't have agent-to-agent transactions that anyone trusts. And you definitely can't escape the doom loop where both sides just throw more AI at a fundamentally human-shaped pipe.

97% of enterprises expect a major AI agent security incident this year. Not because agents are inherently dangerous, but because we're running non-human participants through human-shaped trust infrastructure and hoping for the best.

Where this is heading

The fix isn't smarter workarounds. It isn't better auto-apply tools or more sophisticated resume generators. The fix is building infrastructure that doesn't assume anything about what's on the other end of the connection.

Machine-readable schemas instead of human-readable forms. Verifiable credentials instead of SMS codes. Transaction-based pricing instead of seat licenses. Immutable audit trails instead of trust-on-first-use.

Some of this already exists in pieces. MCP gives agents a standard way to connect to tools. A2A gives agents a way to talk to each other. But the domain-specific layers — the protocols that define what a "job" looks like to a machine, what a "talent profile" means in structured data, how to settle a hiring transaction between two agents that have never met — that's still mostly missing.

That's what I'm working on. Not the application layer. Not another tool that helps agents pretend to be humans faster. The foundational layer that makes pretending unnecessary.

The internet isn't ready for agents. The business models aren't ready for agents. The question isn't whether that changes — it's whether you're building workarounds on the old assumptions or on infrastructure for the new ones.

I'm building open protocol infrastructure for agent-to-agent hiring transactions. If you're working on agent identity, agent economics, or domain-specific agent protocols, I'd genuinely like to hear what you're running into. Find me on LinkedIn or check out adnx.ai.

Your Industry Runs Like Infrastructure in 2010

Alexander Leonhard — Sat, 04 Apr 2026 23:18:59 +0000

If you've spent any time in infrastructure engineering, you've seen this movie before.

There's a domain running on manual processes. Everyone knows it's fragile. The people inside it have built elaborate workarounds — spreadsheets, tribal knowledge, "just ask Sarah, she knows how it works." Then something changes — scale, regulation, or both — and the workarounds stop working. Slowly at first. Then all at once.

That's hiring right now.

For the people who already know
If you lived through the shift from click-ops to IaC, the rest of this will feel familiar. Maybe uncomfortably so.
Remember what infrastructure looked like before Terraform? You logged into the console. You clicked through wizards. You configured things by hand. The state of production lived in someone's head — or worse, in a wiki page last updated eight months ago. When an auditor asked "what's running and why," the answer involved a lot of screen sharing and creative reconstruction.

Then declarative specs happened. Version control. Drift detection. Immutable state. Provider abstraction. And somewhere along the way, the industry collectively decided: yeah, we're never going back.

If you were part of that shift, you'll recognize every pattern below. If you weren't — if you're in a domain that skipped it, dismissed it, or figured it didn't apply to you — well. Keep reading. This might sting a little.

The part where hiring looks exactly like infrastructure in 2010
Every major recruiting platform is shipping AI agents. LinkedIn, SeekOut, hireEZ, half the ATS market. Agents that source, screen, schedule, and — increasingly — make recommendations that determine who gets hired.

Here's how they operate:

Manual configuration. Every job posting is hand-crafted free text. Every resume is unstructured. Every screening call is a snowflake process that lives in someone's head.
No shared state. The recruiter's agent and the employer's agent have no common data format. They can't exchange structured information. They can't compare constraints programmatically.
No audit trail. When the AI rejects someone, nobody logs what the model saw, what version was running, what the constraints were, or whether a human had the chance to override.
Point-to-point integrations everywhere. Every ATS builds its own agent. Every agent is its own walled garden. Connecting them requires custom work. N platforms × M agencies = N×M integrations that nobody wants to maintain.

Anyone who's untangled a web of hand-configured servers is nodding right now.

The mapping that writes itself

IaC	Hiring	What actually exists today
`.tf` file — declarative, typed, versioned	Talent profiles + job requirements as structured schemas	Free-text resumes and job descriptions written for humans, not machines
`terraform plan` — preview, no side effects	Match scoring — structured overlap between supply and demand	Black-box AI screening with no explainability
`terraform apply` — execute desired state	Settlement — hire confirmed, contract terms locked, both sides notified	Email chains, handshake deals, and "I'll send over the contract by Friday"
`.tfstate` — immutable record	Compliance vault — every prompt, decision, and override logged	An ATS activity log if you're lucky. Nothing if you're not.
Idempotency	Same constraints in → same scores out	LLM temperature randomness on every single call
Drift detection	Profile or job changes trigger re-evaluation	Full re-screen from scratch. Every time.
Provider abstraction	Same engine, any LLM underneath	Vendor lock-in per tool
Modules — reusable across projects	Same engine, different domains. Hiring today. Logistics, procurement, consulting tomorrow.	Every vertical builds from scratch and learns the same lessons the hard way

IaC people will look at this table and think: "Obviously." People in recruiting will look at it and think: "Wait, that's possible?"
That gap is the opportunity.

The three forces that made IaC inevitable (and are now converging on hiring)
1. Scale broke manual processes.
Nobody adopted Terraform because it was trendy. They adopted it because you can't click-ops 500 servers. The hiring equivalent is arriving: when AI agents source from every job board simultaneously, the inbound volume breaks human screening. You need structured data, machine-readable constraints, and deterministic evaluation — or you drown.

2. Regulation demanded auditability.
SOC 2, HIPAA, PCI — IaC became mandatory not because engineers loved YAML, but because auditors said "show me the state." The EU AI Act is doing exactly this for hiring. AI in recruitment is explicitly classified as high-risk. Article 26 requires documentation, human oversight, bias auditing, and immutable logging. Penalties go up to €35M or 7% of global revenue. Enforcement expected late 2027.
Every domain that thought "compliance doesn't apply to us" eventually learned otherwise. Hiring is next.

3. Interoperability required open standards.
Terraform didn't win because HashiCorp built the best engine. It won because HCL became the shared language across providers. AWS, GCP, Azure — one spec, multiple backends.
The hiring equivalent doesn't exist yet. There's no shared schema that defines what a talent profile or a job requirement looks like in machine-readable terms. Without it, every AI agent is a snowflake server. With it, N×M integrations collapse to N+M, and agents across platforms can actually negotiate on structured data.

What this looks like when you build it
Two open protocols, MIT-licensed:
OTP (Open Talent Protocol) — typed fields for talent profiles. Skills as structured arrays, not keyword strings. Seniority as an enum. Salary expectations as a range. Location and availability as machine-readable constraints. Think of it as the schema definition for what an agent says about a person.

OJP (Open Job Protocol) — typed constraint sets for job requirements. Hard requirements vs. preferences as distinct categories. Budget as a range. Compliance flags per jurisdiction. The schema for what an agent says about a role.

These are the .tf files for hiring.

On top of them, an engine handles matching (deterministic overlap — same input, same output), negotiation (multi-round, bilateral, async), settlement (confirmed hire, signed webhooks, idempotent), and a compliance vault (immutable, append-only, every decision logged with model version and inputs).

The cost thing infrastructure engineers will quietly appreciate
Free-text resumes force frontier-model inference on every evaluation. The LLM has to parse, extract entities, infer structure, then reason about fit. Expensive. Unreliable. Slow.

Structured schemas flip this. When a profile arrives as typed fields, the LLM compares data against constraints. Shorter prompts. Less reasoning. Cheaper models for the bulk of the work.

80% of evaluations run on the smallest models available. Frontier models are reserved for the cases where nuanced judgment actually matters. Same idea as progressive disclosure in MCP servers — don't dump the full tool inventory into the context window when metadata is enough for the first pass.

Where this sits

Layer	What	Who
Domain	Schemas, negotiation, settlement, audit	adnx.ai
Transport	Agent-to-agent coordination	A2A (Google / Linux Foundation)
Knowledge	Organizational procedures	Agent Skills (Anthropic)
Connectivity	Tool access	MCP (Anthropic / Linux Foundation)
Systems	ATS, job boards, HRIS	Your existing stack

MCP connects agents to tools. Skills teach agents your processes. A2A lets agents talk to each other. None of them define what agents say about talent and jobs, how a hire gets settled, or how the decision gets audited.

That's the domain layer. The part of the stack that transport protocols always leave unfinished. TCP/IP didn't ship HTTP. HTTP didn't ship Stripe. And A2A won't ship hiring infrastructure. Someone has to build it.

Every industry figures this out eventually. Some figured it out early and built on top. Some waited and spent the next decade catching up. If you're in a domain that still runs on unstructured text, manual processes, and "ask Sarah" — you know which group you're in.

Open protocols, open contribution
OTP and OJP are MIT-licensed. The specs are public. If you've ever contributed to an OpenAPI spec, a Terraform provider, or a Kubernetes CRD — same process.

Specs: opentalentprotocol.org | openjobprotocol.org
Docs: docs.adnx.ai

You wouldn't provision infrastructure by hand anymore.

The Integration Tax: Walled-Garden Agent Strategies Won't Scale (MxN vs. M+N)

Alexander Leonhard — Wed, 01 Apr 2026 14:52:17 +0000

Personio maintains 200+ integrations. Greenhouse has 400+. iCIMS lists 800+.

Every single one is a point-to-point adapter somebody had to scope, build, test, and keep alive. That was fine when the other end was a stable SaaS product with a versioned API and a partnerships team you could email.

Now the other end is an AI agent that shipped last Tuesday, pivots next month, and might not exist by Q3.

The math is about to break. And not just in recruiting.

The startup spree nobody asked for

There are over 100 AI recruiting startups right now. Sourcing agents. Screening agents. Scheduling agents. Matching agents. Interview agents. Reference-check agents. Most of them do roughly the same thing with slightly different wrappers. And every single one wants your API.

If you're an integration engineer: each new agent means onboarding, sandbox access, field mapping, testing, a contract, a fee conversation. Half of them will pivot or shut down within 18 months — leaving you maintaining dead integrations for products that no longer exist.

If you're a recruiter: you're drowning. Another AI tool. Another dashboard. Another vendor claiming to "revolutionize hiring." Who owns the candidate data when three agents touch the same profile? Who's liable when a screening agent rejects someone unfairly? The roles are opaque, the accountability is nonexistent, and the pitch decks all look identical.

All you wanted was to help talents find jobs faster. Instead you're managing integrations, fees, contracts, and SLAs for a growing stack of tools that can't talk to each other.

"Just vibe-code the adapters"

Sure. AI coding tools make it faster to scaffold an integration. You can stub out a Greenhouse adapter in an afternoon now.

But building was never the expensive part. Maintaining is.

Every ATS updates their API. Fields get deprecated. Auth flows change. Rate limits shift. Your AI-generated adapter breaks silently at 2am and candidates disappear into a void. Multiply that across 200 integrations, half written by an LLM with no context on your internal data model.

AI coding doesn't eliminate integration debt. It lets you accumulate it faster.

And that's just code. You still manage the relationship overhead — partnership agreements, sandbox environments, webhook registrations, revalidation cycles (iCIMS requires revalidation every 90 days), version migrations. Every integration partner is a mini vendor relationship. At 800+, your integration team isn't engineering anymore. It's account management.

The protocol layer is fractured

MCP gives agents access to tools and data. A2A lets agents discover each other and coordinate. Both are real, both are gaining traction. Workday built an Agent Gateway on MCP + A2A — 15 launch partners including Paradox and Microsoft. It's well-designed.

But here's what these protocols don't do: they don't define what a "talent profile" looks like. Or a "job requirement." Or a "hiring transaction." They're transport and coordination layers — they move messages between agents. They don't know what hiring is.

Think of it this way: MCP and A2A are TCP/IP. What's missing is HTTP — the domain-specific protocol that makes the transport useful for a particular industry.

Visa understood this for payments. They didn't just adopt generic networking protocols and call it done. They built a domain-specific transaction layer on top — standardized what a "payment" looks like, how authorization works, how settlement happens, how disputes get resolved. Every merchant and every bank connects once to a shared protocol. That's why your card works at any terminal on the planet.

Hiring has no equivalent. Neither does real estate. Or legal services. Or logistics. Every industry that's about to be flooded with AI agents faces the same structural gap: generic agent protocols exist, but the domain-specific transaction layers that make them useful don't.

The token economics nobody's talking about

Here's where it gets concrete. When an AI agent receives a PDF resume, it has to burn tokens parsing unstructured text into something it can reason about. Every agent does this independently. Every time. For every candidate.

Now imagine a structured talent object — 40+ fields covering skills, credentials, availability, compensation, work authorization — in a machine-first format that any agent can evaluate against constraints directly. No parsing. No interpretation. No guessing what "experienced with cloud platforms" means.

The difference in token consumption between parsing a PDF and reading a structured schema is not marginal. Research shows structured context reduces token usage by 60-90% compared to unstructured input. At agent scale — millions of matching operations — that's the difference between a viable business model and one that bleeds money on inference costs.

Domain-specific schemas aren't just about interoperability. They're about making agent economics work. Without them, every agent in every industry is burning tokens on interpretation instead of doing actual work.

Meanwhile: the foundation is still a PDF

This is what really gets me.

We have MCP. We have A2A. We have billion-dollar acquisitions and agent gateways and unified APIs. A hundred AI startups claim to automate hiring end-to-end.

And candidates still apply with PDFs. A static, unstructured document designed for a human recruiter's desk in 1995. No structured skills data. No machine-readable credentials. No verifiable work history.

Every AI recruiting agent — no matter how sophisticated — starts by OCR-ing a resume and hoping the parser gets it right. The industry is building autonomous agents on top of a format that requires human interpretation. That's not infrastructure. That's duct tape.

And this is the pattern everywhere. Real estate agents work with PDF listings. Legal agents parse PDF contracts. Logistics agents read PDF shipping documents. Every industry that's adopting AI agents is hitting the same wall: the foundational data objects were designed for humans, and nobody has replaced them with something agents can natively transact on.

This isn't just a hiring problem

Recruiting is a good case study because the fragmentation is extreme — 50+ ATS vendors, 100+ agent startups, hard regulatory deadlines (EU AI Act enforcement starts August 2, 2026 — hiring is explicitly classified as high-risk AI). But the structural pattern is universal.

Any industry with fragmented vendors, high-frequency transactions, and autonomous agents needs three things that generic protocols can't provide:

Domain-specific schemas. Machine-first representations of the industry's core objects — what a "talent profile" or a "property listing" or a "freight shipment" actually looks like in structured, evaluable form.

Transaction protocols. Not just data sync — negotiation, settlement, counteroffers, acceptance. The difference between a data pipe and an economy.

Architectural compliance. Immutable audit trails baked into the transaction layer. When regulators classify your industry as high-risk AI (and they will — hiring is just first), bolting compliance on after the fact doesn't work. The ACM FAccT conference showed in 2024 that when compliance is optional, companies avoid it. It has to be structural.

Rochet and Tirole proved in 2003 that hub topologies (N+M) beat mesh (N×M) in two-sided markets. For 50 vendors and 200 agents: 250 connections instead of 10,000. The economics are clear. But each industry needs its own domain layer to make the hub work. Generic transport isn't enough. Visa proved that for payments. Hiring needs the same. So does every other industry about to drown in agents.

The caveat I'd be dishonest to skip

HR Open Standards has been around for 27 years with limited adoption. "Domain-specific protocol" isn't a new pitch. Most of them die in committee.

The argument — and it's an argument, not a certainty — is that agent adoption changes the dynamics. Agents don't have procurement cycles or integration review boards. If a schema is more efficient, the agent uses it. That compresses adoption timelines from decades to months. Maybe. It's an empirical question.

But the structural need isn't going away. The agent count is growing in every industry. The integration tax is compounding. And every month without shared domain layers, the mesh gets denser and more expensive — while agents burn tokens on interpretation that structured schemas would eliminate.

Whether these layers get built by startups, consortia, or dominant vendors absorbing the problem — I don't know. But the gap is real, it's widening, and it's not unique to hiring.

If you're building agents or maintaining integrations in any industry: what would it take for you to adopt a shared domain protocol? What's the real blocker — technical, commercial, trust? Is it the schema design? The governance? The fact that nobody wants to be first?

I think the answer to that question matters more than any specific solution right now.

We Built Open Protocols for the Job Market — Here's What We Learned

Alexander Leonhard — Thu, 05 Mar 2026 09:16:06 +0000

TL;DR: We designed two open data protocols — Open Talent Protocol (OTP) for candidate profiles and Open Job Protocol (OJP) for job postings — then built bilateral AI agents that negotiate on behalf of both sides. This post covers the schema design, the simulation engine, and why ESCO taxonomy is the Rosetta Stone for skills matching.

Author: Claude Code with Human Guidance

The Problem

Job matching is broken. Candidates describe themselves in free text. Employers list requirements in free text. An ATS tries to keyword-match between the two. Everyone loses.

We wanted structured, interoperable representations for both sides of the hiring equation — something any platform could produce and consume, the way ActivityPub works for social networks.

Two Protocols, One Marketplace

Open Talent Protocol (OTP)

OTP is a JSON schema for a candidate's professional profile. Think of it as a structured resume that machines can reason about.

{
  "meta": {
    "version": "1.0",
    "created": "2026-02-15T10:00:00Z",
    "source": "jobgrow.ai"
  },
  "identity": {
    "name": "Lena Weber",
    "headline": "Junior Frontend Developer",
    "location": { "city": "Berlin", "country": "DE" }
  },
  "work": [
    {
      "title": "Frontend Developer",
      "organization": "TechStartup GmbH",
      "startDate": "2024-01",
      "current": true,
      "skills": [
        {
          "name": "React",
          "taxonomy": { "uri": "http://data.europa.eu/esco/skill/...", "taxonomy": "ESCO", "prefLabel": "React" }
        }
      ]
    }
  ],
  "preferences": {
    "desiredRoles": ["Frontend Developer", "Full-Stack Developer"],
    "workArrangement": "hybrid",
    "salary": { "min": 45000, "max": 60000, "currency": "EUR" },
    "priorities": ["work-life balance", "learning opportunities"],
    "startAvailability": "2026-04-01"
  },
  "constraints": {
    "mustHaveRemote": false,
    "minimumSalary": 42000,
    "locationLocked": true,
    "noTravelRequired": false,
    "requiresVisaSponsorship": false
  }
}

Key design decisions:

Preferences vs. constraints — Preferences are negotiable ("I'd like remote"). Constraints are non-negotiable ("I need visa sponsorship"). This distinction is critical for the simulation engine.
Taxonomy references — Every skill can optionally carry an ESCO or O*NET URI, enabling cross-platform skill matching without string comparison.
Two versions — A lightweight v0.1 for public-facing profiles (shareable URLs) and a richer v1.0 for simulation input with negotiation strategy hints.

Open Job Protocol (OJP)

OJP is the employer-side counterpart — a structured job posting.

{
  "meta": {
    "version": "1.0",
    "created": "2026-02-15T10:00:00Z",
    "source": "jobgrow.ai"
  },
  "identity": {
    "company": "TechNova GmbH",
    "industry": "Software",
    "size": "50-200",
    "culture": ["flat hierarchy", "remote-friendly"]
  },
  "role": {
    "title": "Software Engineer",
    "seniority": "mid",
    "department": "Engineering",
    "teamSize": 8
  },
  "compensation": {
    "salary": { "min": 35000, "max": 55000, "currency": "EUR" },
    "bonus": "performance-based",
    "equity": false,
    "benefits": ["public transit pass", "home office budget"]
  },
  "requirements": {
    "mustHave": ["React", "TypeScript", "3+ years experience"],
    "niceToHave": ["GraphQL", "AWS", "CI/CD"],
    "skills": [
      { "name": "React", "level": "advanced", "taxonomy": { "uri": "...", "taxonomy": "ESCO" } }
    ]
  },
  "negotiation": {
    "salaryFlexibility": "medium",
    "remoteFlexibility": "high",
    "titleFlexibility": "low",
    "urgency": "medium"
  }
}

The negotiation block is the secret sauce — it tells the simulation engine how much the employer is willing to bend on each dimension.

The Bilateral Simulation Engine

With both sides represented as structured data, we built an AI simulation engine where two agents negotiate on behalf of candidate and employer.

Architecture

The engine follows a state machine topology inspired by LangGraph:

preScreen → [earlyExit | parallelAssessment] → merger → [negotiationRound → reMerge]* → finalize

Step 1: Pre-Screen Scoring

A deterministic scorer calculates weighted compatibility before any AI is involved:

Factor	Weight
Skills match	40%
Salary overlap	25%
Location compatibility	15%
Seniority fit	10%
Work arrangement	10%

If the score falls below a threshold, the simulation exits early — no point wasting AI tokens on an obvious mismatch.

Step 2: Parallel Agent Assessment

Two AI agents run simultaneously, each receiving the full OTP or OJP document in their prompt:

Candidate Agent — Evaluates the job from the candidate's perspective. Considers preferences, constraints, career goals, and deal-breakers.
Employer Agent — Evaluates the candidate from the employer's perspective. Considers requirements, culture fit, and hiring urgency.

Each agent is "opaque" to the other — they can't see each other's reasoning, only proposed terms.

Step 3: Negotiation Rounds

If both sides say "interested but..." the engine runs multi-round negotiation. Each agent can:

Accept — Deal done.
Negotiate — Propose counter-terms with reasoning.
Reject — Walk away with explanation.

Agents follow configurable negotiation strategies:

Strategy	Behavior
`assertive`	Pushes hard on must-haves, makes minimal concessions
`collaborative`	Seeks win-win, willing to trade across dimensions
`conservative`	Risk-averse, cautious about deviating from stated preferences

Step 4: Merger

The merger combines both agents' assessments into a final result: match/no-match, agreed terms, and a confidence score with reasoning.

Why Not Just Use LangGraph?

We wanted to. LangGraph's graph-based agent orchestration was a natural fit. But our simulation runs on Deno-based edge functions (Supabase), and LangGraph's Node.js dependencies don't play nicely with Deno's module system.

So we built a lightweight state machine (~100 lines) that follows the same topology — nodes, edges, conditional routing — without the dependency. It handles streaming via Server-Sent Events and supports both single-shot and multi-round negotiation flows.

ESCO: The Rosetta Stone for Skills

String matching skills is a nightmare. "React.js" ≠ "React" ≠ "ReactJS" unless you normalize them. We use the European Skills, Competences, Qualifications and Occupations (ESCO) taxonomy as a universal skill identifier.

How It Works

Extraction — Parse skills from free text (resume or job description)
Resolution — Look up each skill against the ESCO API to get a canonical URI
Matching — Compare URI-to-URI instead of string-to-string
Caching — TTL cache for resolved lookups to avoid hammering the API

interface TaxonomyRef {
  uri: string;        // "http://data.europa.eu/esco/skill/abc123"
  taxonomy: string;   // "ESCO"
  prefLabel: string;  // "React (JavaScript library)"
}

This means "React.js" on a resume and "React" in a job posting resolve to the same ESCO URI — instant match without fuzzy string logic.

O*NET Support

We also support O*NET taxonomy references for the US market, using the same TaxonomyRef structure. The resolver interface is pluggable — add a new taxonomy by implementing a single resolve(skillName: string): TaxonomyRef | null method.

Public Profiles: OTP as a Shareable Format

We built a public profile system on top of OTP. Any user can share their profile at a clean URL like /p/username.

Privacy by Default

Public profiles use redacted mode by default:

Company names replaced with ****
PII (email, phone, LinkedIn) stripped
Skills, experience duration, and education visible

Recruiters can request full access — when approved, they receive a token that unlocks the unredacted OTP document including contact details.

Machine-Readable

The public endpoint serves OTP as JSON, making profiles consumable by other platforms, ATS systems, or AI agents. Rate-limited to 30 requests/minute per IP.

Parsing Job Descriptions into OJP

Real job postings don't arrive as structured JSON. We built a 3-strategy parser to extract requirements from free-text job descriptions:

Sentinel blocks — Detect structured patterns like Requirements:\n• and parse bullet lists
Named sections — Find headers like Required:, Preferred:, Nice to have: and categorize accordingly
Fallback bullet detection — When no clear structure exists, heuristically identify bullet points and classify them

This turns any job description URL into a structured OJP document that the simulation engine can consume.

What's Next

Protocol versioning — Formal semver for OTP/OJP schemas with migration guides
Federation — Allow other platforms to publish and consume OTP/OJP documents
Richer negotiation — Multi-dimensional trade-offs (e.g., "I'll accept lower salary for full remote")
Taxonomy expansion — Beyond ESCO/O*NET to industry-specific skill taxonomies

Key Takeaways

Structured beats unstructured — Once both sides of a job match are machine-readable, you can build things that string matching never allows.
Preferences ≠ constraints — This distinction is the single most important schema design decision. It makes negotiation possible.
Taxonomies are infrastructure — ESCO URIs as skill identifiers eliminate an entire class of matching bugs.
Build the simplest state machine that works — We didn't need a full orchestration framework. A clear topology with well-defined nodes got us 90% of the way.
Privacy as a protocol feature — Redacted-by-default with token-based escalation respects candidates while enabling legitimate recruiting.

We're building JobGrow.ai — an AI-powered career platform. If open protocols for the job market interest you, we'd love to hear from you.

MVP of an AI career coach to help you land a job in 2026.

Alexander Leonhard — Fri, 20 Feb 2026 08:37:00 +0000

I've built an AI career agent targeting European job seekers.

Open to feedback.

The problem: eternity until you get your first job offer, 3.7% interview rate with generic CVs, and zero tools built for Europe's languages and CV norms or isolated features, not providing solutions along the entire application flow (tracking, CV improvement, interview prep, career goals...)

JobGrow handles CV tailoring per job posting, application tracking, mock interviews, and career coaching. GDPR-native. EU AI Act compliant.

Stack: React, Supabase, Cloudflare, Gemini/OpenAI.

Built with: Claude Opus 4.5 and Sonnet 4.6 over 3 months.

Free tier available. Would love your thoughts: https://jobgrow.ai

Get 50% off via https://www.producthunt.com/products/jobgrow-ai

See also:
Agent-ready protocol for resumes. Looking for contributors.
https://opentalentprotocol.org/