Skip to content
← Back to Insights

Recruiters, AI, and the Legibility Problem

I think recruiters are a legibility problem, not a people problem. Here is why I built a recruiter-facing page, JSON endpoint, and clean resume/contact path.

John Sambrook, TOC Jonah Certified ·

TL;DR

Recruiters are not the problem. Legibility is. If someone has to wade through noisy outreach, vague websites, and generic role descriptions just to figure out whether there is a fit, the system is broken. I built a recruiter-facing page, JSON endpoint, resume request path, and contact path so the good recruiters — and the AI tools they already use — can get signal quickly without forcing a cold DM.


A recruiter prompt, a resume request path, and a clean contact route arranged as a simple legibility flow

A recruiter sent me one of those messages again recently.

You know the type. “I studied your website.” “My client wants someone just like you.” “Can we hop on a call?” The message is trying to be helpful, but it feels like noise because the sender is trying to learn too much too quickly from too little structure.

I do not think the answer is to pretend recruiters do not exist. That would be silly. Good recruiters are part of how work gets matched. Some of them are careful, professional, and genuinely trying to solve a problem for somebody who needs help. The problem is that the normal path for understanding a person or a firm is too noisy, too easy to game, and too dependent on whichever side has more patience that day.

That is a legibility problem.

And once I started thinking about it that way, the right response became obvious: build infrastructure that makes the site easier to read.

What legibility means here

When I say “legibility,” I mean something pretty plain.

A recruiter should be able to understand, in one pass:

  • what Common Sense Systems does
  • what kind of work I actually want
  • what kind of work is not a fit
  • which resume version to ask for
  • how to make contact without guessing

If their AI is the first thing reading the site, the same should still be true. The machine should be able to summarize the fit honestly without inventing details or flattening the important differences.

That is not magic. It is just good structure.

The Recruiter API idea

So I built the first version of what I am calling a Recruiter API.

That sounds fancier than it is. The basic pieces are simple:

  • a human-readable landing page at /agents
  • a machine-readable JSON endpoint at /agents.json
  • a resume request path at /agents/resume
  • a contact path at /agents/contact
  • a fit-notes page at /agents/fit

The point is not to replace a real conversation. The point is to make the first step easier.

If a recruiter is serious, they should not have to reverse-engineer the business from a wall of marketing copy and a LinkedIn profile. They should be able to get a clean summary, request the right resume, and reach the right contact path without a lot of back-and-forth.

That is useful for humans too.

Why this matters more now

AI changes the shape of this problem.

Recruiters already use AI tools to sort resumes, compare candidates, summarize profiles, and draft outreach. That is not going away. So the choice is not between AI and no AI. The choice is between making the information legible or letting the machine guess.

I would rather help the machine get it right.

If the site gives a recruiter’s AI a clean summary, fit signals, and contact instructions, then the recruiter gets a better starting point. They waste less time. I waste less time. And the whole exchange starts from signal instead of noise.

That feels like a better use of everyone’s energy.

What the site now says more clearly

This legibility work is part of a larger cleanup.

Over the last few days I have been tightening the front door of the website in a series of small experiments:

  • clearer positioning
  • better proof points
  • simpler contact paths
  • direct publishing paths for X and LinkedIn
  • a more reliable deploy loop
  • social drafts tied to actual site changes
  • a simple POOGI cycle: observe, hypothesize, change, measure, learn

That is not glamorous work. But it is the work that makes the rest of the site more honest.

The same is true of the offer itself.

I keep coming back to the same plain version: we sell picks and shovels, and we help people get them running on their own hardware, infrastructure, and business. If someone wants to automate the way we are automating, they should book a discovery call. This is not a turn-key product. It is consultation, implementation, and follow-through over weeks or months until the system is real and working.

That framing matters because it tells the truth.

It does not pretend the work is software-only. It does not pretend it is instant. It does not pretend a website can sell itself if the offer is vague. It says what we actually do and what it takes to do it well.

What a good recruiter path should do

A recruiter-friendly interface should do a few things cleanly:

  • explain the work in plain language
  • show the kinds of roles and projects that fit
  • make it easy to request the right resume version
  • point to the best contact path
  • stay honest about what I do and do not want

That is what the Recruiter API is for.

It is not meant to be a gimmick or a fancy wrapper around a contact form. It is meant to be infrastructure for being findable, legible, and easy to work with.

If that sounds basic, good. Basic is usually what works.

The part I do not want to lose

I also do not want to lose the human part of this.

A clean machine-readable path is not a replacement for judgment, context, or conversation. It is just a way to avoid wasting the first exchange on confusion.

If the right recruiter wants to work with me, I want that path to be obvious. If the fit is poor, I want the site to say that early and politely. And if the question is serious but incomplete, I want the next step to be easy to see.

That is all.

Where this goes next

The Recruiter API is the first version. It will probably keep evolving.

I can imagine it growing into:

  • more structured machine-readable fields
  • a better resume selection path
  • a more explicit fit / not-fit summary
  • richer proof points tied to real work history
  • a clearer bridge from public site to direct conversation

That is a useful direction because it makes the site more useful to both humans and systems.

And if someone wants to adapt the idea for their own company or hiring funnel, I would be glad to compare notes.

You can reach me here:

https://common-sense.com/contact

Or, if you are a recruiter and want to see the page directly:

https://common-sense.com/agents