I was building headhunter-agent, a local-first multi-agent system for job hunting. My mentor pointed out that the natural endgame is a world where every company runs an agent endpoint and candidates connect directly — no browsers, no portals, no CAPTCHAs. Like BitTorrent, but for jobs. Is this a dumb idea? Let me think out loud.

Here’s the picture forming in my head.

Right now, the headhunter-agent is a single-player tool — it runs on my machine, keeps my data local, and uses AI agents to profile me, evaluate job descriptions, and prepare interviews. The M2M protocol already lets me submit applications directly to employer endpoints without a browser.

But the vision goes further:

What if every company runs a headhunter-agent endpoint, and every candidate runs one too? Candidates and employers find each other through DNS, negotiate through signed messages, and transact directly. No Indeed. No LinkedIn. No Workday. No CAPTCHAs ever again.

Let me draw what this looks like:

Architecture Diagram

No browser ever touched this flow. No human filled out a form. No CAPTCHA was solved.

Is This Dumb?

Let me be honest. There are real reasons this hasn’t happened:

Reason 1: Chicken-and-Egg Problem

Nobody will build employer endpoints if no candidates use them. Nobody will use the candidate agent if no employers have endpoints. This is the same problem every P2P network faces — BitTorrent solved it with piracy (people wanted content badly enough to run clients), Bitcoin solved it with money (people wanted to transact without banks).

The job market has no equivalent killer incentive for employers. Workday, Greenhouse, and Lever are entrenched. HR departments buy software, not protocols.

Reason 2: HR is Not a Technical Buyer

The M2M protocol requires a company to: - Publish a DNS TXT record - Run an HTTP endpoint that serves JSON-LD - Implement Ed25519 signature verification - Accept multipart form submissions with signed attachments

Who in a company does this? The HR team can’t. The engineering team doesn’t care about recruiting infrastructure. There’s no budget line item for “decentralized application protocol.”

Reason 3: Network Effects Favor Centralization

LinkedIn is valuable because everyone is on it. Indeed is valuable because every job is there. A P2P job market fragments the listing pool — you have to discover each employer individually. Discovery becomes the bottleneck.

Reason 4: Spam and Abuse

BitTorrent has no spam problem because you choose what to download. A job market has a massive spam problem — if every candidate can send signed applications to every employer, how do you prevent the equivalent of LinkedIn InMail spam, but cryptographic and automated?

Spoofing Ed25519 identities is near-impossible, but that doesn’t stop a million legitimate-but-irrelevant applications from flooding every endpoint.

…Or Is It Inevitable?

Okay, I played devil’s advocate. Now let me argue the other side. Because I think there’s something here.

The Browser is a Bad Interface for Job Applications

Let me count the pathologies of the current system:

  1. Create an account on every company’s career portal
  2. Re-enter the same information 50 times (name, email, phone, work history)
  3. Upload the same resume 50 times
  4. Solve a CAPTCHA every time (proving you’re human to apply for a human job)
  5. No standard format — every ATS parses your resume differently
  6. No transparency — you never know if your application was received, read, or considered
  7. No portability — your application history is locked inside each portal

This is insane. We accept it because we’ve always done it this way.

The M2M Protocol Already Solves This

The headhunter-agent’s M2M protocol (v1.0.0) already addresses every pathology:

Pathology M2M Solution
Create account on every portal Ed25519 identity — one keypair, all employers
Re-enter information Signed master profile — send once, verify everywhere
Upload resume repeatedly Signed PDF attachment — same file, independent verification
CAPTCHAs m2m:acceptsSignedApplications: true — identity replaces CAPTCHA
No standard format JSON-LD schemas — machine-readable by design
No transparency Signed acknowledgment with applicationId
No portability Application history is YOUR data, stored locally
Architecture Diagram

The UDP/Low-Level Protocol Question

You mentioned BitTorrent using UDP. The current M2M protocol uses HTTP — it’s RESTful JSON-LD, not a custom wire protocol. HTTP was chosen because: - Every employer already has an HTTP server - TLS is well-understood - JSON-LD has existing tooling

But you’re asking something deeper: should this be a lower-level protocol? Like a UDP-based M2M discovery and transfer protocol?

Architecture Diagram

The UDP approach would be faster (no TCP handshake, no TLS negotiation), more resilient (no connection state), and more censorship-resistant (harder to block). But it requires: - Custom protocol implementation in every client and server - NAT traversal (like BitTorrent’s DHT and hole-punching) - Application-level reliability on top of UDP - No existing employer infrastructure supports this

For a future decentralized job network, UDP makes sense. For the first working version, HTTP is the right call.

The Hybrid Model I Actually Believe In

Pure P2P is idealistic. Pure centralized is what we have. The realistic middle is:

Architecture Diagram

Company-side: They already have the infrastructure

Any company with a career portal already has: - A domain (they control DNS) - An HTTP server (it’s 2026) - JSON APIs (their careers page already has one, probably)

Adding _m2m-apply.company.com TXT "m2m-p1;https://company.com/m2m/v1;key=..." is a 5-minute DNS change. The endpoint can be a Cloudflare Worker (50 lines of JavaScript) that verifies Ed25519 signatures and posts to their existing ATS.

This is not hypothetical. The headhunter-agent’s directory.clj already implements the directory service in 76 lines of Babashka. The registry.clj already does DNS discovery. The crypto.clj already handles Ed25519. The submit.clj already builds signed packages.

Architecture Diagram

The Real Innovation: Reputation Without Centralization

The hardest problem isn’t the protocol — it’s trust. How do I know an employer is real? How does an employer know my application is serious?

BitTorrent solved this with seeding ratios — you contribute to the network to consume from it. Bitcoin solved it with proof of work — you spend resources to participate.

For a job market, the solution might be reputation bonding:

Architecture Diagram

You don’t need a blockchain for this. A signed reputation log — each party signing their interaction history — is sufficient. Your headhunter-agent stores every acknowledgment, every interview invitation, every ghosted application. When you apply to a new employer, you can present your signed history as proof of seriousness.

The BitTorrent Analogy, Properly Understood

BitTorrent didn’t replace the web. It replaced a specific broken workflow — downloading large files from central servers that capped bandwidth and deleted unpopular content. BitTorrent succeeded because:

  1. Centralized alternative was broken (RapidShare, Megaupload)
  2. Protocol was simple (bencode, tracker protocol, peer wire protocol)
  3. Client was free (µTorrent was 300KB)
  4. Content was the killer app (Linux ISOs… sure)

The job market has the same pattern:

  1. Centralized alternative is broken (Workday, LinkedIn, CAPTCHA hell)
  2. Protocol is simple (DNS discovery, JSON-LD, Ed25519)
  3. Client is free (headhunter-agent is MIT licensed)
  4. The killer app is… your career

Is that enough? I don’t know. It took BitTorrent 5 years to reach mainstream. Bitcoin took 7 years to hit $1,000 (from $0). Protocol adoption is measured in decades, not months.

Architecture Diagram

Why I’m Building It Anyway

Here’s the honest answer.

Even if no company ever deploys an M2M endpoint, the headhunter-agent is already useful to me as a single-player tool. The profiler, evaluator, interview prep, PDF generator, and tracker improve my job hunting regardless of the protocol layer.

The M2M protocol costs me almost nothing to maintain — it’s 600 lines of Clojure across 8 files. The Daemon MCP server is another 400 lines. If no one ever uses them, I’ve still built: - A deeper understanding of Ed25519 cryptography - A working DNS discovery mechanism - A JSON-LD schema for job postings - A signed application package format

And if one company — even one — deploys an M2M endpoint, the network exists.

BitTorrent started with one tracker and two peers. Bitcoin started with one miner. The internet started with two connected universities.

Protocols don’t start with networks. They start with one person running the software.

Architecture Diagram

The Dumb Parts I’m Not Ignoring

Let me list what keeps me up at night:

  1. Spam. A million signed applications are still a million applications. Reputation bonds help, but they add friction to the onboarding experience. CAPTCHAs are terrible, but they work.

  2. Ghosting. Employers already ignore 90% of applications. Giving them an automated protocol won’t make them more responsive. The protocol needs to penalize ghosting — maybe employers must respond within N days or lose reputation.

  3. Discovery. DNS is great if you know the company name. How do you discover jobs at companies you’ve never heard of? The directory service helps, but then you’re centralized again.

  4. Legal compliance. Singapore’s Fair Consideration Framework requires employers to advertise jobs on MyCareersFuture. Can an M2M posting satisfy this? What about EEOC in the US? GDPR in Europe?

  5. Incumbent resistance. LinkedIn, Indeed, and the ATS vendors have zero incentive to support a protocol that bypasses them. They’ll build AI features, not open protocols.

The Decision

Is this a dumb idea? Parts of it are. The pure P2P vision is probably too idealistic for the job market. Companies are not Linux ISOs — they have compliance requirements, HR processes, and procurement cycles that don’t map neatly to protocol adoption.

But the M2M protocol is not dumb. It solves a real problem (browser-based application hell) with real cryptography (Ed25519) and a real implementation (600 lines, working today). The question isn’t “will this replace LinkedIn?” — it’s “will this make my job hunting better right now?”

The answer to that is yes. My headhunter-agent already: - Profiles me once, not 50 times - Evaluates JDs in 30 seconds, not 30 minutes - Submits applications with one command, not 20 clicks - Tracks my pipeline automatically, not in a spreadsheet

The protocol layer is just the cherry. The MAS pipeline is the cake.

I’m shipping it. If you want to run an employer endpoint, the spec is in docs/m2m-protocol/SPECIFICATION.md and the implementation is at gitlab.com/nurazhar/headhunter-agent. I’ll be the first peer on the network.