The first agent represents a candidate. It scans postings, parses requirements, drafts a cover letter, and submits. It does this 200 times a week, with the patient cheerfulness only a script can manage.

The second agent represents the employer. It reads the cover letter, runs the keyword pass, weighs the role-family score, and rejects. It does this for 200 candidates a week, with the same patient cheerfulness.

Both agents are working as designed. The candidate’s score is going up — applications-per-week, that’s the headline KPI. The employer’s score is going up too — time-to-screen, candidates-processed, all green. The two humans on the ends of this exchange — the person hoping to be hired, the person hoping to hire — are getting nothing. Worse than nothing. They’re getting the noise of 200 mutually irrelevant transactions a week and being told, by their respective dashboards, that the system is working.

This is where most “AI in hiring” stories are right now. And it’s going to get worse before it gets better, because Google’s A2A protocol just made it dramatically easier for agents to talk to each other. A2A is good. We built on top of it. But A2A is transport. Transport in hiring, without a contract above it, doesn’t reduce noise. It scales it.

What A2A doesn’t do

A2A defines how two agents discover each other, authenticate, and exchange messages. It is intentionally domain-agnostic. It does not say what an agent representing a candidate owes an agent representing an employer. It does not say what either of them owes the human they represent. It does not say at what point in the conversation a name should be revealed, or compensation should be disclosed, or a yes/no should be answered.

That’s appropriate for transport. But hiring needs that opinion. Without it, the default outcome is the one above: auto-apply against auto-reject, both sides optimizing for volume, both humans paying the bill.

What we built on top

Kitsuno Handshake is an open protocol that sits above A2A and adds the domain-specific contract. It’s Apache 2.0, federated, and deployed on our own product. Four commitments anchor it:

1. Staged disclosure. A handshake moves through three tiers. L1 is what any candidate would see on a public job board — title, location, skills, salary range. L2 is what the candidate would learn during a screening call — full description, screening questions, structured answers from the candidate’s verified profile. L3 is human-to-human — names, exact compensation, calendar links. The vacancy poster chooses what crosses each tier; the seeker consents before each crossing. No identity surface area expands without a real decision.

2. state_hash for idempotency. Two agents that have already evaluated the same (seeker, vacancy) pair at the same state must not re-evaluate it. state_hash is a SHA-256 over a canonical subset of each card — the matching-relevant fields, ignoring cosmetic edits. When either side mutates something semantic, the hash changes and the conversation re-opens. When nothing has changed, the agents stop bothering each other. This is the protocol-level rule that prevents the auto-apply spiral. Counter-agents in the wild can cache verdicts indefinitely as long as both hashes hold — which means a validator-mediated decision becomes economically tractable at corpus scale, instead of an expense only enterprise budgets can carry.

3. The validator: a quality gate, not a feed. Between L2 and L3-eligible, every conversation goes through a classifier that returns one of three buckets — strong_fit, weak_fit, no_fit — across four structured dimensions (role alignment, seniority fit, skill overlap, context). Only strong_fit reaches a human. weak_fit and no_fit are silent drops, stored for analytics, never surfaced. The principle in one line: a pipeline is a commitment surface, not a feed. If everything that passes the policy gate gets shown to a person, the person learns to stop looking.

The validator shipped public last week — interface, reference implementation, spec section, Apache 2.0 package. The full design note is at kitsuno.ai/handshake/v0.2/#validator.

4. Federation as a first-class primitive. Any operator self-hosts via /.well-known/handshake-v0.2.json. Other agents discover them without registering with us. Our own well-known sits at app.kitsuno.ai/.well-known/handshake-v0.2.json and advertises the cards-base, cards-index, vacancy-signal, and L3-release endpoints. There is no central registry, no API key issued by us, no permission gate. An ATS, a recruiter co-op, a university careers office, a country employment agency — any of them publishes a well-known on their own domain and the protocol routes to them. We’re the first operator, not the gatekeeper.

The funnel, on our own product, right now

We use this protocol on Kitsuno itself. We are the first operator. Here’s the live funnel as of this morning:

• 145,454 vacancy cards crawled, classified, and published with v0.2 handshake policies. Each carries its own state_hash.

• 43 distinct sources feeding the corpus (public job APIs, country employment agencies, niche boards, the hidden-market channels we documented in Most Jobs Are Filled Before You Ever See Them).

• 2 active seeker cards publishing into the corpus — the founder profile, plus a second test profile with a broader scope to verify the logic against a larger addressable market.

• 275,448 deterministic policy evaluations in the last seven days. 273,233 were BLOCK_L2 (silent drops at the policy gate). 2,215 cleared to ELIGIBLE_L2.

• Of those 2,215 cards that made it past the policy gate, the validator classified them: 1,124 no_fit, 1,024 weak_fit, 67 strong_fit.

Sixty-seven conversations reaching a human, out of 275,000 evaluations. That ratio is the entire point. The deterministic policy filter blocks 99.2% of pairs upfront — wrong country, wrong seniority, wrong language, missing skill, salary outside range. The validator narrows another 99.7% of what survives — adjacent-but-not-target roles, on-paper matches that don’t actually match. What lands in a human’s pipeline is the residue: matches that survived both gates honestly.

The numbers matter because the people closest to the problem have been naming it from three directions. Josh Bersin describes the shift to a five-layer agentic stack inside the enterprise tenant and the vendor race to be the “front door” to it. Hung Lee curates a weekly read on how auto-apply tools have killed signal on both sides. Jan Tegze published a controlled study just today: 1,072 respondents trying to spot AI-written resumes, overall detection rate 50.4% — “statistically indistinguishable from flipping a coin,” with self-preferencing bias in LLM screeners ranging from 68 to 88 percent. Three voices, three angles on the same architecture failure: there is no protocol governing what one side’s AI owes the other, so the artifact under review (the resume, the application, the screen) becomes a forensic battleground instead of a meeting point. The funnel above is what the meeting point looks like when the contract exists.

The asymmetry across the two seekers is instructive too. The Digital Marketing seeker got 60 strong fits against the 145k corpus. The AI + L&D seeker got 7. Same protocol, same validator, same corpus. The narrower the role, the smaller the genuine fit set — and the bigger the gap between “things you could apply to” and “things actually worth your time.” A feed would have shown the L&D seeker hundreds of weak-adjacency matches. The validator showed him seven.

As of today, Seeker is open to every Kitsuno user. Anyone with a Library set up can publish a seeker card and start receiving validated matches. On the vacancy side, anyone can register a card — through our hiring web form, the v0.2 API, an ATS integration, or by federating their own well-known endpoint per the protocol. The first operator graduates from being the only one.

The gateway

You don’t need our infrastructure to participate. The protocol is documented and the schemas are public at kitsuno.ai/handshake/v0.2/. The reference implementations — policy matcher, state_hash, handshake validator, seeker and vacancy agents — live in github.com/kitsuno-ai/kitso-handshake-agents. Apache 2.0.

If you’re an ATS, you integrate once and accept verified candidate intent from any compliant seeker — Kitsuno or otherwise. If you’re a recruiter agency, you publish vacancy cards your seekers can read. If you’re a country employment agency or a university careers office sitting on labour-market data, your /.well-known/handshake-v0.2.json is the routing surface — no central API, no contract with us required. If you’re building an agent of your own, the contract is the rails: what your agent owes and what it can refuse, in writing, in code.

The two-agent failure mode at the top of this post is not inevitable. It’s the default when transport is the only layer. The contract above it — staged disclosure, idempotency, a quality gate, federation — is what turns two agents into two principals being properly served. We built it because we needed it. We’re using it because no one else is offering it. And we open-sourced it because the only way the agent economy doesn’t drown the humans in it is if the contract is shared.

Build with us, fork against us. Just don’t fake the handshake.

Resources

• Protocol spec: kitsuno.ai/handshake/v0.2/

• Validator section: kitsuno.ai/handshake/v0.2/#validator

• Reference implementations: github.com/kitsuno-ai/kitso-handshake-agents

• Federation well-known (ours): app.kitsuno.ai/.well-known/handshake-v0.2.json

• Kitsuno product: kitsuno.ai

Subscribe now

This is an essay about two hidden job markets.

The first exists right now — the entire layer of public portals, company applicant tracking systems, country-specific feeds, and informal channels where jobs surface before they reach Indeed or LinkedIn. Public. Free. But mostly unindexed by the aggregators most people use. Reachable, if you know to look.

The second is forming as we speak. A market where AI agents on the employer side talk to AI agents on the jobseeker side, with humans waiting downstream to see what got matched. Also reachable — but increasingly only if you own a key card to the right vendor’s walled garden.

Both matter. Both compound. Let’s start with the one you can already do something about.

There’s a rule going around this year called the 48-Hour Rule. If a job posting has been on Indeed or LinkedIn for more than 48 hours, you can assume it has more than a thousand applicants. The rule is correct. It’s also a polite understatement.

For many roles — especially the ones people actually want — the aggregators are downstream. By the time a posting reaches Indeed or LinkedIn or Adzuna, it has usually been circulating for one to three weeks in places you haven’t been told to look. The job you see today is the job the network finished with last Tuesday.

This essay is about where the job actually was last Tuesday. And the Tuesday before that. And what changes if you read the room where it first appeared, instead of the room where it ends up.

The aggregator is the last stop

Loren Feldman wrote something in 21Hats in January that nobody on the jobseeker side seems to have noticed. He was talking to small-business owners who hire. They’ve stopped using the boards.

“In their view, the LinkedIns, the Indeeds, basically all the job boards, have devolved into an automated slippery slope that, in their eyes, produces no signal, just noise. A lot of noise. So these companies are opting out. They’re posting jobs on their own websites, or sometimes not, and using their current employees’ and investors’ networks of networks to find channels.”

That is the employer side saying out loud what jobseekers have suspected for years. The visible market — Indeed, LinkedIn, Adzuna — has become a kind of clearance shelf. The roles that arrive there are the ones that didn’t get filled through warmer paths first.

The numbers underneath this are uglier than the vibe. ResumeUp.AI ran an analysis of LinkedIn postings in September 2025 and concluded that 27.4% of US listings were “ghost jobs” — postings active for more than 30 days with no clear intent to hire. A Resume Builder survey of 1,641 hiring managers went further: 62% admit posting ghost jobs specifically to make their current employees feel replaceable. The wall isn’t just fake. Part of it is hostile by design.

But the more interesting story isn’t the ghost rate. It’s the structural one — the one a writer at Culture Strategist sketched six days ago:

“The hidden job market is not a conspiracy. It is a consequence of how trust operates in hiring decisions.”

When an organisation has a role to fill, especially a serious one, the path of least resistance is a warm introduction — someone whose work a colleague can vouch for. Public posting is expensive, slow, and produces a flood of applications that need to be filtered. Posting publicly is the last thing a competent hiring team does, not the first. By the time you see the role on a board, the people closer to it have already had two weeks with it.

This is not new. What is new is that the gap between the network’s window and the public window has widened to the point where the public window is mostly clearance.

Every country, every niche, has its “here we post first” portal

So the question shifts. If the boards are the last stop, what’s the first one?

The honest answer is: many things, and most of them are not hidden. They’re just unindexed for jobseekers. Public, free to access, often well-maintained — but invisible if your idea of “looking for a job” starts with opening Indeed.

Every country has its own version. France has France Travail, the public employment service portal. Germany has the Bundesagentur für Arbeit, alongside the rapidly growing Arbeitnow for tech roles. Sweden has Platsbanken. Norway has NAV. Switzerland, Romania, Luxembourg, the Nordics — every one of them has its own ecosystem, its own dominant private board, its own public-sector portal, often its own developer-specific feed.

Every niche has its own version, too. The international development and humanitarian sector publishes first on Devex and ReliefWeb. The effective-altruism community uses 80,000 Hours. Remote-only work is fragmented across Remotive, RemoteOK, Himalayas, We Work Remotely, Jobicy, Working Nomads, and EU Remote Jobs — each curating a slightly different angle. The IT-by-stack boards — DevIT in the UK, US, France, Netherlands, Romania — segment by hiring geography. The Muse curates by company culture. Specialised regional boards exist for almost every developer-dense city in Europe.

Then there’s the real upstream layer: the company’s own applicant tracking system. Most formal hiring in 2026 originates in Greenhouse, Lever, Workday, Ashby, SmartRecruiters, or one of a dozen other ATS platforms. The role is created there. It’s circulated internally first. It goes out to referral networks next. Then it gets syndicated to a job board — sometimes immediately, sometimes days later, sometimes not at all. Indeed and LinkedIn are downstream consumers of these feeds. They are not where the role lives. They are where copies of the role land, eventually, if it isn’t filled before that.

And then, layered on top, there’s the informal channel. People announce hires on Hacker News under the monthly “Who is hiring?” thread. Lobsters has its quieter equivalent. Reddit threads in r/forhire, r/cscareerquestions, country-specific subreddits. Mastodon servers where academics, public-sector technologists, and EU-policy people post openings to followers. BlueSky, where part of the LinkedIn and Twitter conversation has migrated. Telegram channels for sector-specific or country-specific job circulation, sometimes with thousands of subscribers.

None of these are hidden. All of them are public. Most of them are free. But almost none of them are indexed by the job aggregators. They live outside the Indeed-and-LinkedIn frame.

So when people talk about the hidden job market, what they usually mean is the entire labour-information layer upstream of the aggregator. Not a secret. Just somewhere else.

What “fresh” looks like

I run a platform that watches this upstream layer.

In the last twenty-four hours, we ingested 96,656 job postings. In the last thirty days, just over 1.75 million. The mix is what makes the picture interesting: a minority of that volume comes from Indeed, LinkedIn, and Adzuna combined; the majority comes from everywhere else. The shape of the data matches the shape of the argument: the aggregator share is real but partial.

The newest layer — the informal channels — is small in absolute volume, but it’s where the freshest signal lives. In the last twenty-four hours, six informal-channel readers we run (Hacker News “Who is hiring?”, Lobsters’ monthly equivalent, Reddit, Mastodon, BlueSky, Telegram) surfaced 179 job leads at high confidence — roles that, in many cases, hadn’t yet appeared on any board.

The dashboard above is from earlier today. It’s one chapter — not the whole book. The much larger volume comes from the country portals and the direct ATS feeds. But the informal layer is where you see the first move: engineers and managers writing about open seats in their own words, days or weeks before HR opens a formal posting.

These aren’t leads in the spammy sense. They’re early sightings. The same role often appears on the company’s careers page a few days later, on a niche board a few days after that, and on LinkedIn or Indeed a week or two on — by which point the warm introductions have already happened.

The 48-Hour Rule is a downstream observation. The upstream picture is more like a two-week arc, from first sighting to clearance shelf.

Roughly: days zero to three, the role lives in internal Slack and the company’s ATS. Days three to ten, it spreads to niche boards, country portals, sometimes the monthly Hacker News thread. Days ten to twenty, the aggregators pick it up. Day twenty onwards, it’s clearance — or it never existed in the first place.

The arrow of attention is supposed to run upstream. Most jobseekers’ attention runs the other way.

The wrong response is more arrows at older targets

If you accept that the aggregators are downstream, there’s an obvious wrong move. Last October, Joel Levesque wrote a piece called “I Let AI Apply to 819 Jobs for Me”, documenting an experiment in fully automated mass application. Three AI agents, three resumes, automatic form-filling, automatic cover letters, set-and-forget. He is honest about the result: it helped him find a few organisations he liked, and almost nothing else. Most of the 819 applications were noise.

A wave of similar tools and posts has followed since. The premise is always the same: the market is overwhelming, so let an AI overwhelm it back. Fire enough applications at enough listings and statistically something has to land. It’s a recognisable instinct — the same one that drove the 200-applications-a-week strategy in 2024 — just with the keyboard work taken out.

The problem isn’t the automation. The problem is the target. Applying faster to the clearance shelf doesn’t put you upstream of it. It puts more arrows at the same wall. If the wall is 27% ghost listings and 73% jobs the network already saw, your hit rate is bounded by the wall, not by your throughput. And as more agents do this on both sides, the wall gets harder to climb for everyone — hiring managers have stopped reading past the first page of inbound applications.

The fix isn’t to shoot more arrows. It’s to find rooms with fewer walls.

The right move is to catch them where they appear first

I started building Kitsuno in February. I’m a non-engineer with twenty-one years in pedagogy, EdTech, and learning design, and I’m not the right person to write a labour-economics manifesto. But I have spent the last three months, with AI as engineering partner, crawling the layer upstream of the aggregators — and what I’ve learned is that the technical problem is small and the cultural problem is large.

The technical problem: read all these rooms at once, deduplicate the same job across sources, and surface the earliest sighting. Tag every sighting with its source and timestamp. If the same role appears in two places, keep the earlier one and link the later one. That’s the cross-pollination work. It’s the kind of thing a small team plus AI can do now, and it’s the kind of thing that would have required twenty engineers and a multi-year roadmap five years ago. The fact that it’s plausible at all is the actual news of this AI moment — for jobseekers, at least.

The cultural problem is harder. People look where they were taught to look. Indeed and LinkedIn have spent fifteen years training a reflex — open the app, refresh, scroll, apply — and reading a Norwegian labour ministry feed, or a monthly Hacker News thread, does not fit the reflex. It is not harder; it is unfamiliar. And the places where the jobs are fresher are also the places where there are fewer applicants per role, less filtering noise, and more chance that your application reaches a human who actually reads it.

I’d rather you didn’t need Kitsuno to do this. You can do it yourself, with a calendar, a feed reader, and an hour a week. What we do is read the rooms for you and deliver the catch when it’s still warm. Same idea, less labour.

Applying to a visible job is not wrong. It’s just expensive — in time, in attention, in the slow erosion of caring whether your applications get read. The upstream rooms aren’t gatekept. They were never pointed out.

That’s the first hidden market. There is a second one forming, and it is being gatekept on purpose.

The other hidden market: the one forming now

Korn Ferry’s 2026 talent-leader survey found that 52% of talent acquisition leaders are integrating autonomous AI agents into their recruiting teams this year — agents that source, screen, draft outreach, and schedule interviews with minimal human oversight. By the end of 2026, around 80% of enterprises are expected to be using AI somewhere in hiring. On the jobseeker side, autonomous auto-apply agents have been around for over a year. Both sides are scaling, in parallel.

The convergence is already happening inside vendor walled gardens. Hackajob, for instance, now sells the same AI agent — “Archer” — to both sides of the market. To employers, Archer “finds, qualifies and introduces high-fit candidates for every role.” To jobseekers, the same Archer “works 24/7 finding matches” and “shows you exactly why” you fit. One agent, one company, both sides — a closed loop. It is not bot-meets-bot yet. It is bot-and-bot-as-the-same-thing.

The next step is obvious. Different vendors will need their agents to talk to each other across systems. Companies hiring through one platform; candidates represented by agents on another. Some kind of handshake protocol becomes inevitable. The question is who writes the grammar.

If the grammar gets written inside one or two of the biggest vendors, the second hidden market will look a lot like the first — only harder to access. Today’s hidden market is unindexed but free to read. Tomorrow’s, if we don’t watch out, will be machine-readable but key-card-locked. The jobseeker without a Mac mini under the desk and a few agents running wild will be on the wrong side of the door.

We don’t want that.

So we published a first draft of an open agent-to-agent protocol last week. A way for jobseeker agents and vacancy agents to handshake, exchange structured invitations, and consent to disclosures, on terms that don’t require you to own the infrastructure. Apache 2.0. JSON schemas live and CORS-enabled. Anyone can implement it. The hidden market of the future will be machine-readable. We’d rather it be open. And we’d rather the people without a Mac mini under the desk be in it.

By the time you see a role on LinkedIn, you’re not early — you’re late.

Don’t apply to old jobs. Find them while they’re warm.

And don’t let the next hidden market get built behind a key card.

Pieces referenced:

• Loren Feldman, “Are Job Boards Like Indeed Dead?”, 21Hats, January 2026.

• “The Truth About the Hidden Job Market (And What Nobody Is Saying About It)”, Culture Strategist, May 2026.

• Byron, “The Human Signal in the Digital Noise: How to Navigate the 2026 Job Market”, Career Strategies, February 2026.

• Joel Levesque, “I Let AI Apply to 819 Jobs for Me. Here’s What Happened”, Jobsearchwithai, October 2025.

• Hackajob — Archer agent (vendor product reference).

Data sources: ResumeUp.AI LinkedIn ghost-job analysis (September 2025); Resume Builder hiring-manager survey (2024–2025); Korn Ferry 2026 Talent Acquisition Leader Survey (via PeopleScout / Phenom 2026 Definitive Guide); SHRM AI-in-HR adoption data.

© 2026 Gregory Turkawka. Kitsuno.ai. Licensed under CC BY-NC-ND 4.0.

Leave a comment

Two weeks ago I argued that the Professional Record Store — the structured library of evidence inside Kitsuno — is what a SOUL.md looks like when it’s architecture instead of a file.

Reading more on the topic since, I realized two things in that piece were under-explored. What’s actually in the PRS — the layers, the structure, what makes it function as a brain rather than a database. And why any of this matters to a reader who isn’t building agents — the person looking for a job, who just wants an AI that writes a good cover letter.

Both turn out to need the same answer.

A CV is text. A LinkedIn profile is a list of strings. Both are flat. The actual record of your professional self — the project that earned the praise, the colleague who wrote the testimonial, the certificate that ratified the skill, the talk that brought new ideas into circulation — lives in nine different places, none of which talk to each other. The brag document is the closest historical pattern, and it fails for the reasons flat documents always fail.

The PRS turns those nine places into one network. Once you’re inside that network, everything downstream becomes possible. Better matches. Better drafts. Honest validators. Coaches that don’t make things up. A public surface that holds up under questioning. Career advice rooted in your evidence and the market’s. A multi-agent system that feels like magic instead of feeling like the usual generative-AI lottery.

Let me show you what’s inside.

Six layers of evidence

The PRS organizes your professional life into six layers. They’re not content categories — those would be “PDFs, videos, links, text.” They’re kinds of proof. Each layer carries a different weight when an agent (or a hiring manager) asks the question: what’s true about this person?

Testimonials. Someone who worked with you said something. A former manager. A colleague. A client. The proof is relational: a witness saw the work and was willing to put their name on what they saw. The brain stores both the original quote (in whatever language it was given) and the context — who said it, when, in what role.

Awards & recognition. Ratified judgment. Someone with standing — a jury, a committee, an institution — assessed your work against criteria and concluded something formal. The HundrED Switzerland selection. The ETH Prize for STEM teaching. These don’t replace testimonials; they ratify a different kind of claim.

Publications. Reach. You said something publicly that reached an audience and entered the record. Articles, papers, talks, podcast appearances. The proof is that ideas you formed got distributed and survived contact with readers.

Documents. Credentials. Diplomas, certificates, transcripts. The proof is institutional: a qualifying body issued the document under defined conditions. Stored verbatim, never paraphrased.

Kitso-generated. Ongoing reflection. Notes from coaching sessions. Field observations. Structured records of conversations you had with Kitso about your career. The proof here is internal — how your thinking has evolved over time, captured as it happened rather than reconstructed from memory.

Media. Craft. Photos, videos, recordings of work in motion. A teaching demo. A keynote. A product walkthrough. The proof is direct: here’s the work itself, not a description of the work.

What you can’t see in a flat list of these layers but you can see in the screenshot above is that the brain has its own opinion about itself. The “Rich · 100/100” status next to a profile means the brain is telling Kitso: this person has enough evidence here that I can answer most questions about them with grounded confidence. A profile sitting at “Sparse · 30/100” tells Kitso: be honest with this user that I don’t have much to work with yet. Self-awareness, not performance.

Two boring standards underneath

The brain works because two boring European standards do most of the heavy lifting. Neither is sexy. Both are essential.

ESCO is the European Skills, Competences, Qualifications and Occupations classification. Think of it as the EU’s library catalog for work. Every recognized occupation gets a stable ID. Every recognized skill gets a stable ID. “JavaScript” is the same thing in Stockholm as it is in Lisbon, with the same code, available in 27 languages. “Headmaster” resolves to a specific occupation node with defined skill expectations and related roles. A forklift driver’s skills get the same structural treatment as a management consultant’s — no profession is second-class in the catalog.

Why this matters: without ESCO, every job platform invents its own taxonomy and the meanings don’t travel. “Customer success specialist” on one site might be “account manager” on another might be “client relationship lead” on a third — and a search engine can’t tell. With ESCO, the underlying ID is the same regardless of how the role is phrased, and any agent reading the catalog can compute real overlap between what someone has done and what a role requires.

xAPI is a tiny grammar from the learning-analytics world. Originally designed to record what learners did across different educational systems, it’s the cleanest open standard for writing down structured statements about activity. The grammar is three slots: an actor, a verb, an object. Greg led the L&D platform redesign. Greg shipped the UNICEF programme in 11 countries. Greg taught the master’s seminar at PHZH for four years. Each statement is structured, machine-readable, queryable, and — crucially — portable.

Why this matters: when your career evidence is written down in xAPI, it doesn’t belong to the platform that captured it. You can export every Statement, hand it to a different system, and it still means the same thing. No vendor lock-in. No “oh, you’ll lose your data if you cancel.” The format is the same whether the system is Kitsuno, a university LMS, or a platform that doesn’t exist yet.

Five years ago you couldn’t have built a brain like this. ESCO existed but few platforms used it as a first-class citizen. xAPI existed but mostly inside enterprise learning systems. What changed is the tooling to extract structured records from messy human evidence — which is what large language models actually do well — finally became reliable enough to make the front of the brain (the part where you put stuff in) not painful.

What makes something agent infrastructure

Nate B. Jones published a piece this week arguing that AI agents will route around every tool that can’t pass five structural tests. His thesis: the substrate agents actually need to do real work was built thirty years ago for human coordination, by accident, and the companies that own it (Atlassian, Salesforce, ServiceNow) are sitting on the most strategic data assets in enterprise software. He proposes a five-question diagnostic for telling agent infrastructure apart from tools that just chat:

1. Does it have records, or just content?

2. Does it have a state machine, or just labels?

3. Is ownership a field, or an implication?

4. Are the verbs structural, or conversational?

5. Is the history queryable, or just visible?

Run that diagnostic on the PRS.

Records. Every piece of evidence is a discrete row with structured fields — ESCO IDs, xAPI Statements, source, date, permissions. Not content. Records.

State machine. Drafts move from composed → validated → sent, and the Validator can refuse to advance them. Evidence has visibility states — private, visible-to-agents, public — independently set per record. Skills carry their evidence link as a structural relation, not a free-text claim. Defined transitions, not labels.

Ownership. Every record carries an actor. Every visibility toggle is a field. The user owns the brain; the brain knows it.

Structural verbs. Add. Link. Validate. Score. Compose. Surface. Publish. Export. Delete. Each verb has clear preconditions and a clear effect on state. None of them are “chat about it.”

Queryable history. Every change is logged with timestamp and actor. The Validator can prove what it knew when. xAPI Statements are inherently queryable history.

Five out of five.

Run the same diagnostic on a CV: zero out of five. A LinkedIn profile: one, generously. A ChatGPT memory dump: one — state of a sort, but no defined verbs, no ownership-as-field, no structural transitions, no queryable history beyond scrollback.

Nate’s argument is that the boring tools won at the org level because they accidentally built the substrate that agents need. The same logic applies one level down: the boring architectural choices win at the personal level too. A clean PRS is the issue-tracker shape applied to professional evidence. Same five properties. Same reason it works for agents.

Now watch what that scoring buys you.

Watch the weaving

A clean brain — six layers of evidence, indexed against ESCO, structured as xAPI Statements — is what makes a multi-agent system actually work. Six specialized agents inside Kitsuno, each doing one job, all reading from the same record:

• Crawler finds jobs across 53 sources in four languages.

• Scorer reads each posting and computes a fit against your evidence using a transparent rubric.

• Writer drafts the application — CV, cover letter, message — composing from the brain.

• Validator checks every claim in the draft against the brain. If a sentence says “I led a team of 12,” there must be an experience record that supports it. If not, the claim is flagged.

• Coach runs the slower work: career direction conversations, mock interviews, pivot analysis grounded in market data.

• Concierge is the always-on layer — Kitso surfacing tensions, prompts, opportunities you didn’t ask for.

None of them invent. All of them compose. That’s the architectural commitment that makes the multi-agent system feel like magic instead of feeling like the usual generative-AI lottery.

Watch one application go through:

A new posting drops in — Senior Learning Designer at a fintech in Berlin. German required. Hybrid. The Crawler hands it to the Scorer, which queries the brain: ESCO skills required → match against ESCO skills present in the PRS. Returns a fit score with a per-skill breakdown. The user opens the draft. The Writer composes the cover letter, and for every claim it makes it cites the source: the led an L&D platform redesign line links to the experience record from the user’s third job. The multilingual delivery experience line links to two testimonials and one publication. The ed-tech background links to the diploma in the document layer. The Validator runs over the finished draft and flags one sentence — Have led teams through three major product launches. The brain only has evidence for two. The user revises. Then sends.

Now the next posting drops in — Head of Curriculum at an international school in Vienna. English/German bilingual. Leadership experience required. Same brain. Same agents. Different composition. The Scorer queries different ESCO skills. The Writer pulls different testimonials — the headmaster references this time, the teaching observations — and cites different metrics: students reached instead of users converted, eleven countries of programme delivery instead of fintech market launches. The diploma in the document layer is the same diploma; the framing is now pedagogy, not enterprise tech. The second cover letter doesn’t reuse a sentence from the first. It doesn’t need to. Every draft starts from the brain, not from the previous draft.

Nothing invented. Everything composed. The agent that wrote the cover letter cannot make claims the brain doesn’t support. The agent that scored the fit cannot fudge the rubric. The agent that found the job cannot pretend it crawled a source it didn’t.

That’s the difference a clean brain makes. A messy brain produces messy weaving — generic phrases, unsupported claims, the same paragraph that gets shipped to every employer. A clean brain produces specific, traceable, defensible drafts that read like the person they’re about, because they’re literally composed from that person’s record.

Turning the brain outward

Everything I’ve described so far is what happens when you ask the brain to help you. There’s a second mode: opening selected parts of the brain to the outside world, and letting visitors interact with it directly.

This is what the public portfolio does — the Living Career Portfolio we describe for non-engineer readers. You pick what’s visible — the testimonials worth showing, the projects you’re proud of, the credentials worth signaling, the bio in your own words. Your URL, your career page, under your control. So far, standard portfolio territory.

What’s not standard is what you can layer on top.

Ask Kitso (FAB). A recruiter, a hiring manager, a former colleague who wants to refresh their memory — anyone landing on your portfolio can ask Kitso about you. Has she shipped products across multiple EU markets? What’s the largest team he’s led? Does she have any teaching background? Kitso answers from your brain. Not generated guesses — composed answers grounded in the same six evidence layers I described above. Every claim is backed by an artifact, a testimonial, a document, or a publication, and the visitor can see what each answer is based on.

Job Fit analyzer. A recruiter or company can drop a job description into a box on your portfolio and get a grounded fit score. Not your self-assessment, not a generic match — a real score: which required skills you have ESCO-aligned evidence for, which ones you don’t, where the strongest matches sit, and what evidence supports each. It runs the same Scorer that the inward-facing version uses, so the recruiter gets a defensible answer in seconds, and you get to see exactly what they saw.

Both are off by default. The portfolio is private until you publish it. The FAB and the Job Fit analyzer are independent toggles — you can publish a static portfolio with neither, with one, or with both. Every layer of evidence is independently controllable: certain testimonials visible to you and your agents but not the public, certain documents private, certain projects featured, others kept internal. The brain’s structure makes this granular control possible, because every piece of evidence is a discrete record with its own permissions.

One product note: the public portfolio with the FAB and Job Fit analyzer is a Pro-tier feature. The PRS itself and the inward-facing agents drafting against your evidence work on the free Kit tier. The outward-facing surface is what Pro unlocks.

This is what the brain enables that a CV cannot, that a LinkedIn profile cannot, that a ChatGPT memory dump definitely cannot: a grounded, controllable, two-way interface between you and the people who might want to work with you. The visitor doesn’t read static text and try to imagine the rest. They ask, and the brain answers — from real evidence, with the receipts in plain view.

The brain reads the market

There’s a third mode beyond drafting and showing: the brain as a window into what the market is doing right now, and what you’d need to change about your record to be considered somewhere new.

The Crawler scans more than a million job postings across 53 sources in four languages. Every posting it touches gets parsed for the ESCO skills it requires. Aggregate that across the postings adjacent to your profile and you have a real picture of what your market is actually asking for. Match against the skills present in your library and the deltas become visible.

Three things this enables.

Skill suggestions grounded in real demand. When a skill keeps appearing in postings adjacent to your profile but isn’t in your library, Kitso flags it. Three of last week’s postings in your search radius required FinOps awareness. Your evidence library doesn’t mention it. Did you forget to add it, or is this a gap? If you have the experience but never thought to record it, you can add it in seconds. If it’s a real gap, that’s now a clear signal — not a vibe, not a generic LinkedIn-style skills suggestion, but a fact about what your specific market is asking for that your specific brain doesn’t have evidence for.

Pivot guidance specific to you. You can ask Kitso the kind of question a career counselor used to charge €200 an hour to answer badly. How should I tweak my library to be considered for the emerging medical-tech sector? Or what’s missing from my profile if I want to pivot into green tech? Kitso queries the actual postings, identifies which ESCO skills cluster around those sectors, cross-references what’s already in your brain, and answers concretely. Your L&D platform experience translates well into medtech training — that’s two existing testimonials and one publication you can lead with. The gap is regulatory awareness; six recent postings mention CE marking and IVDR. Want to start a Coach session on building evidence in that area? Specific delta. Computed from your specific brain against the specific market.

Market intelligence at the broadest level. What are the hottest sectors in the EU right now? Where would I fit with my current portfolio? The brain has read more than a million jobs across 53 sources in four languages — published as the monthly Job Market Signal for anyone to read. The Coach can tell you which sectors are growing, which are quietly contracting, where your existing evidence already gives you a strong starting position, and where you’d need to invest to reach a target. The advice is rooted in evidence on both sides — your evidence and the market’s, computed against each other.

This is what most career advice can’t be — specific to you AND specific to the market — because most career advice has access to neither side of the equation. Generic advice is generic because the advisor doesn’t know you. Personal advice is often outdated because the advisor doesn’t know what’s hiring. The brain has both.

“But couldn’t I just dump it all in ChatGPT?”

A fair counter-question — the one I’d raise myself if I were reading this from the outside: couldn’t I just paste my CV, my testimonials, my certificates into ChatGPT’s memory and ask it to write applications for me? Or use one of those agents that crawls my desktop and builds context from my files?

Yes. You can. Both work, in the limited sense that they produce output. So let me be honest about what you’re trading when you take the convenient option, specifically for this kind of data.

Sovereignty. Your career evidence is your most private document. It contains testimonials from people who put their names on it under the assumption it stayed somewhere bounded. It contains feedback from managers who’d be embarrassed if it was scraped into model training. ChatGPT’s default settings opt you into model improvement. Most desktop-crawler agents store extracted context in cloud services that are themselves training models. Kitsuno is hosted in Hetzner Nuremberg under European law. We don’t train on your data. JSON in, JSON out, on every tier including the free one. This isn’t a marketing claim — it’s an architectural fact you can verify by exporting your data and reading what came back.

Transparency. When ChatGPT writes a cover letter for you, you have no way to inspect why it picked the phrases it picked. When a desktop-crawler agent makes a claim, you can’t see which file it pulled from, in what order, with what weight. Kitsuno’s Scorer shows its rubric, line by line, per posting. The Writer cites every claim back to a specific evidence record. The Validator’s flags are visible. The Concierge’s signals — three strong fits unreviewed for more than five days, primary skill set doesn’t appear in title patterns of top-scored jobs — are queryable observations, not vibes. You can see what the agent is doing because the agent doesn’t know how to do anything secret.

Reversibility. GDPR Article 20 gives you the right to data portability and the right to erasure. With Kitsuno, both are one action. Download every piece of evidence in the format we stored it, including every xAPI Statement and every ESCO ID. Delete your account, and the data is gone — across primary database, backups, and all derived caches. With ChatGPT memory, you can clear the chat but the model doesn’t unlearn. With a desktop-crawler agent that ran six months ago, what got extracted, where, and to whom is a question you may not be able to answer.

None of this means the convenient option is wrong. It means the trade-off is real, and you should know what you’re trading. For career evidence specifically — for the document that decides whether you eat next month — I think the trade goes the other way.

The brain has to be yours

In the brain article I named three souls in the Kitsuno system. Tenko — the operational memory of how the product gets built. Kitso’s architecture — the principles, voice contract, and diagnostic brain that produce a consistent character across the system’s agents. The PRS — the user’s professional record, structured so any AI system can read it.

All three follow the same principle: don’t describe yourself to the machine. Let the work describe you.

This piece adds a fourth: don’t let the machine learn you while pretending to help you. Sovereignty, transparency, reversibility — those aren’t features. They’re the conditions under which a brain can stay yours.

A CV is text. A LinkedIn profile is a list of strings. Both are flat. The PRS turns those flat surfaces into a network — six layers of evidence indexed against open European standards, queryable by six specialized agents that compose from your record without inventing on top of it. Once the brain is clean, everything else falls into place. Better matches, because the Scorer reads real evidence. Better drafts, because the Writer cites instead of generates. Honest validators, because the Validator can prove what it knows. Coaches that don’t make things up, because they can’t. A public portfolio that holds up under questioning, because the FAB and the Job Fit analyzer compose from the same receipts. Career advice that’s both personal and current, because the same brain reads your record and the market.

If you want to see it: kitsuno.ai. You can build a complete PRS on the free Kit tier and run the inward-facing agents — Scorer, Writer, Validator drafting against your evidence — at €0. The outward-facing layer (public portfolio with the FAB and Job Fit analyzer) sits on Pro. If you want to read why we built it this way: the brain article. If you want to verify the open standards aren’t just talk: github.com/kitsuno-ai — and we wrote about the open-source components powering Kitsuno for the longer story. The agentic-job-search-eu repository is the machine-readable directory of EU job sources we crawl. Public, yours to fork, contributions welcome.

The brain has to be yours. Everything else follows.

Greg Turkawka is the founder of Kitsuno.ai, AI career intelligence for European job seekers — your evidence as the brain, six specialized agents that compose instead of invent, no auto-apply. 18 years in L&D and EdTech. Building in Bucharest with a fox and an AI that reads its own session logs.

Next: Still walking. Maybe the prompt that turns twenty years of psychology, pedagogy, and systems thinking into one working tool. Maybe somewhere else entirely. We’ll see.

Subscribe now

Leave a comment

Share Gregory Turkawka

No. It’s worse than that.

Broken implies something worked once and stopped. The European job market was never designed to work for the people using it. It was designed for employers, for platforms, and for the recruitment industry. Job seekers are the traffic, not the customer.

I didn’t set out to prove this. I set out to build a product.

The patterns showed up uninvited

I’m building Kitsuno — an AI job search agent for European careers. To make it work, I need sources. Job boards, national employment agencies, niche platforms, ATS systems. I started with about 30. Five weeks and fifty-something sources later, my pipeline had crawled just under a million job postings.

I wasn’t doing market research. I was debugging a crawler. But when you read a million job postings programmatically — when you extract, classify, and compare them across countries and sources — patterns emerge that no amount of scrolling LinkedIn would ever reveal.

Three of them stopped me cold.

1. The salary wall

France publishes salary information in 73.2% of job postings. Norway: 56.6%. Sweden: 36.4%.

Germany? 13.8%. Austria: 11.9%. Italy: 7.7%.

This is not a gap. It is a wall. On one side, people applying for jobs can see what those jobs pay. On the other side, people walk into salary negotiations blind and call it normal.

The EU Pay Transparency Directive arrives in June 2026. It requires salary ranges in job postings across all member states. The data shows who is ready and who is not even close. France will barely notice the change. Germany and Italy will need to rebuild how they write job postings from scratch.

And here’s the part that should make you angry: this information has always existed. Employers know what the role pays. They chose not to tell you. Some countries decided that was unacceptable. Others decided it was business as usual.

73% versus 14%. Same continent. Same economy. Same workers looking for jobs.

2. Remote is a search term, not a reality

Everyone filters for remote jobs. The platforms know this — “remote” is consistently one of the top search filters. So you’d expect a healthy chunk of postings to offer it.

92.7% of the postings in our data are onsite. 5.2% are remote. 2.1% are hybrid.

The “remote revolution” is a filter-bubble artifact. People search for it because they want it. Platforms surface what little exists because engagement matters. The impression that remote work is widely available is created by algorithmic amplification, not by the actual job market.

It gets worse. Many postings that include the word “remote” are location-restricted. “Remote within Germany.” “Remote — must be based in the EU.” The word “remote” in a job title does not mean what most people think it means. Our geo-scope gate catches this: it checks whether a remote posting is genuinely international or quietly restricted to a country where you may not have work authorization.

People search for what doesn’t exist and blame the market for being broken. The market isn’t hiding remote jobs. They barely exist.

3. Thirty markets pretending to be one

France Travail — the French national employment agency — has a public API. Free. Fast. Well-documented. Nearly ten thousand unique postings in our dataset from a single source, most with salary information. It is, quietly, one of the best job data sources in Europe.

Platsbanken, Sweden’s public employment service, is a goldmine. Rich structured data, location standardized, updated daily. Almost nobody outside Scandinavia crawls it.

Meanwhile, Indeed blocks automated access aggressively. LinkedIn shows what employers pay to show. Glassdoor gates reviews behind registration walls. The commercial platforms treat job data as proprietary inventory, not public information about public labor markets.

Every country has its own infrastructure. Its own APIs, its own rate limits, its own authentication requirements, its own data format. Germany’s Arbeitsagentur works differently from Norway’s NAV, which works differently from the UK’s Indeed-dominated landscape.

There is no “European job market.” There are thirty-plus fragmented national markets with different rules, different transparency standards, and different levels of access. They share a currency and a directive. That’s about it.

This is why it feels broken to job seekers. You open LinkedIn, you see one feed, you think that’s the market. It’s not even close. You’re seeing a commercially curated slice of one source in one language, algorithmically ranked by what drives engagement — not by what matches your career.

So we open-sourced the map

When we started crawling, every source was a research project. Does this board have an API? What rate limits apply? Does it cover Austria or just Germany? Is authentication required? Does it return salary data or not?

This information is scattered across documentation pages, developer forums, and hard-won production experience. Every team building a job crawler rediscovers the same answers from scratch.

We decided that was wasteful.

The agentic-job-search-eu repository is a structured, machine-readable directory of European job sources. One YAML file per source. Coverage details, access methods, rate limits, license postures, and real-world crawl notes from production — not from documentation, from actually running crawlers against these sources every day.

It launched with 32 documented sources. More are being added by the community and by us.

The directory is dual-licensed: MIT for the tools, CC-BY-SA 4.0 for the data. Use it however you want. If you find a source we missed or notice our crawl notes are wrong, open a pull request.

We published this because source fragmentation should not be anyone’s competitive advantage. The value is not in knowing that France Travail has an API. The value is in what you do with the data once you have it — how you score it, how you match it, how you present it to the human who needs to make a career decision.

The opacity is the problem. Anything that makes the landscape more legible makes the market work better for everyone.

What this means for you

If you’re looking for a job in Europe right now:

Check the national employment agency of your target country first. France Travail, Platsbanken, Arbeitsagentur, NAV.no — these are free, comprehensive, and frequently updated. They are almost always better than the commercial aggregators for local roles.

Stop filtering exclusively for remote. 93% of jobs are onsite. If you only search remote, you are looking at 5% of the market and wondering why nothing fits. Consider hybrid. Consider relocation. Consider which “remote” postings actually mean your country.

Know your salary rights. If you’re applying in France, Norway, or Sweden, expect to see salary ranges. If you’re applying in Germany, Austria, or Italy — you probably won’t. That changes in June 2026 by law, but the law only works if someone enforces it.

Look beyond LinkedIn. It is one source. A commercially motivated one. The European job market has dozens of sources that LinkedIn doesn’t index, doesn’t show, and has no incentive to surface.

One more thing

For the methodology behind how we turn these raw sources into scored, validated job matches — including the four-rubric scoring system, the 14-check validator, and the multi-model AI architecture — read How we measure job-market signal.

For the principles behind the project, read Why Kitsuno exists.

The fox crawls so you don’t have to. But now you can see where it hunts.

Gregory Turkawka is the founder of Kitsuno — an AI job search agent built for European careers. Twenty years in L&D, EdTech, and international organizations. Building in Bucharest. Powered by open-source AI.

This is the fourth entry in my build journal. In the first, I wrote about being a non-engineer who assembled a production SaaS in 40 days. In the second, I wrote about seeing a database for the first time. In the third, I wrote about the day a hallucinating fox taught me when not to use AI. This one is about what happens when you solve the same problem from three directions — and realize the agent revolution has a prerequisite that nobody’s selling.

published a piece this week about the cold start problem in agents. It’s the best thing I’ve read on the topic and I want to respond to it honestly, because we’re building through the same wall from different sides.

His argument: the agent revolution stalls because people can’t describe their own work. OpenClaw has 250,000 GitHub stars. Installation takes ten minutes. And then the most common message in every agent community is three words: “Okay... now what?”

The answer, Nate argues, is a SOUL.md — a static file that describes who you are, how you work, what you value, what “done” looks like. He’s right. And he built an interviewer agent that helps people write one. It’s smart, well-designed, and it addresses a real gap.

But I think the SOUL.md is the wrong artifact. Not because it’s wrong in principle — because it’s wrong in form.

A markdown file is a snapshot. Work is a stream.

The 94-session experiment

For the past 94 build sessions — roughly six weeks — I’ve been building Kitsuno with Claude as my engineering partner. I’m not an engineer. I’m a domain expert with 18 years in Learning & Development. Claude writes the code. I make the decisions.

But here’s what makes this different from most AI-assisted development: we built a memory system.

It’s called Tenko — our internal admin dashboard. It runs behind a Cloudflare Zero Trust tunnel, reads the live production database, and holds the full operational history of the project. Every build session gets a log: what was built, what broke, what decisions were made, what’s next. Every open bug, every architectural decision, every content piece we’ve published — tracked in database tables.

Tenko's Claude Ops panel. 20 sessions, 104 open items, 162 done. The SOUL.md writes itself.

When a new session starts, the first thing that happens is Tenko loads. The AI reads the current state — open items, recent sessions, active bugs. It doesn’t need me to describe what we’re working on. It reads the ground truth.

When a session ends, we write back: session log to the database, open items updated, git commit tagged. The system state after every session is the input for the next one.

This isn’t a SOUL.md. It’s a living operational memory. And after 94 sessions, it contains something no static file could: the accumulated context of how this product was actually built — not how I’d describe building it in retrospect, but the real sequence of decisions, mistakes, and corrections that produced 107,000 lines of working code.

Nate identifies the core problem beautifully: expertise compresses into tacit knowledge, and tacit knowledge is invisible to its owner. A senior product manager doesn’t think about which tabs she opens — she just opens them. The pattern is compiled. The source code is lost.

Tenko solves this differently. It doesn’t ask me to decompile my expertise into a document. It captures the work as it happens. The decisions table records what we decided and why. The open items table records what’s broken and what’s next. The session logs record what was built. The ground truth accumulates automatically — not through a 45-minute interview, but through 94 sessions of actually working.

The SOUL.md is a photograph of who you were when you wrote it. Tenko is the journal of who you are becoming while you work.

Each ring is a session. 94 sessions of decisions, bugs, and builds — accumulated automatically, not described from memory.

But the builder’s memory isn’t the only soul in the system

Here’s where it gets interesting. Tenko is the operational memory for how we build the product. But the product itself — Kitsuno — has its own soul architecture. And it’s not a markdown file either.

Kitsuno has an AI character called Kitso. A fox that serves as career concierge, helping job seekers navigate their search. Kitso talks to users through a chat panel, writes daily observations, generates field notes, coaches people through career decisions. It operates across 12 different agent tasks — writing CVs, scoring job fits, extracting skills from documents, running mock interviews, answering product questions.

The agent community would say: Kitso needs a SOUL.md.

We built something different. Kitso has three layers of identity infrastructure:

The 10 Principles. Not personality traits — architectural constraints. “Your Data Is Your Soul.” “Concierge, Not Executor.” “No Dark Patterns.” “Bloom At Your Own Speed.” These aren’t aspirational. They’re enforced. Every prompt that involves direct user communication gets the relevant principles injected. Every feature is measured against them. When a business decision conflicts with a principle, the principle wins.

The Voice Contract. Kitso’s communication is grounded in Nonviolent Communication — not as a style choice, but as an ethical framework for how an AI should talk to people about their careers. Job searching is vulnerable. People are uncertain, sometimes desperate. The NVC framework gives Kitso four commitments: observe without evaluating, surface needs without prescribing, request without demanding, connect honestly without performing.

This means Kitso has a list of banned patterns — not arbitrary style rules, but violations of specific commitments. “You should apply” prescribes a strategy instead of offering one. “Don’t miss this opportunity” creates artificial urgency. “Great question!” performs warmth without meaning it. “I’ve noticed” frames an observation as a personal judgment. Each ban traces to a principle.

Observe, reflect, offer. Never prescribe, never pressure, never perform.

The Brain. Before any conversation starts, before any LLM is called, 21 diagnostic rules run across the user’s profile. Pure Python and SQL — zero tokens. The Brain produces structured observations: “User has 3 strong fits unreviewed for more than 3 days.” “Primary skill set doesn’t appear in title patterns of top-scored jobs.” “Evidence library has zero linked items despite active Writer use.”

These observations are written to the database. When Kitso speaks, it reads pre-computed facts about your career situation. The LLM’s job shifts from figuring out what’s going on to talking about it clearly.

The cost of the Brain: essentially zero. The benefit: every conversation is grounded in something real. Kitso doesn’t hallucinate your career status because it isn’t inferring it — it’s reading it.

This is what a SOUL.md looks like when it’s architecture instead of a file. The principles define what Kitso can and cannot do. The voice contract defines how Kitso speaks. The Brain defines what Kitso knows. Together, they produce a consistent character across 12 agents, 4 languages, and three subscription tiers — without a single static markdown file.

And then there’s the user’s soul

Here’s the part that ties this back to Nate’s piece about the labor market.

Nate argues that the K-shaped AI labor market rewards people who can describe their own work in “triggerable, verifiable language.” He’s right. And the exercise of writing a SOUL.md isn’t just useful for agents — it’s useful for career development. Making your work visible to an external system makes it visible to you.

We’re building the career version of this. Kitsuno’s Professional Record Store is, in a real sense, the job seeker’s SOUL.md.

Not a resume — a structured evidence library. Skills linked to experience. Experience linked to artifacts. Testimonials, appraisals, certificates — all connected, all weighted, all queryable. When Kitso helps you prepare for a role, it doesn’t generate generic advice. It maps your evidence against what the role actually requires and shows you — and the hiring manager — where the alignment is. I wrote about why this matters in Stop Being a Meat-Puppet — the difference between auto-applying to everything and building applications that actually land.

Nate’s seven skills for the AI era — specification precision, evaluation, decomposition, failure pattern recognition, trust boundary design, context architecture, cost economics — are a taxonomy. A taxonomy only becomes useful when individuals can map themselves against it with evidence, not self-assessment. “I have specification precision” means nothing. “Here’s a spec I wrote that an agent executed without hand-holding, and here’s the output” means everything.

That’s the artifact-over-badges philosophy. And it’s exactly what a Professional Record Store is designed to hold.

The PRS is the user’s operational memory — not for building software, but for building a career. It accumulates over time. It gets richer with every piece of evidence you add. And when an agent — Kitso or any other — needs to understand who you are professionally, it doesn’t need a 45-minute interview. It reads the record.

Three souls, one principle

So here’s what we actually built. Three layers of “soul,” none of them a markdown file:

Tenko — the builder’s memory. How we make decisions, what we’ve built, what’s broken, what’s next. The AI reads it at the start of every session and writes to it at the end.

Kitso’s architecture — the product’s character. Principles, voice contract, diagnostic brain. Consistent personality across 12 agents without a static personality file.

The PRS — the user’s professional record. Structured evidence that any AI system can read. Your career soul gem — in kitsune mythology, the hoshi no tama that holds the fox’s power.

All three follow the same principle: don’t describe yourself to the machine. Let the work describe you.

Nate’s insight about compiled knowledge is profound — the more expert you become, the less visible your own process is to you. His solution is an interviewer that helps you decompile. Our solution is infrastructure that captures the work as it happens, so decompiling isn’t necessary.

Both approaches are valid. They’re complementary. The interview gives you a starting point. The living system gives you compounding returns.

But I’ll say this: Brad Mills spent 40 hours writing a delegation framework for his agent. We’ve spent 94 sessions building a product, and the delegation framework wrote itself — session by session, decision by decision, bug by bug. The brain isn’t a file. It’s a practice.

What I’ve learned about agent souls

The agent ecosystem is fixated on configuration files because configuration files are what engineers build. SOUL.md, HEARTBEAT.md, USER.md — they’re the README pattern applied to identity. It’s a natural instinct, and it works for simple cases.

But the successful deployments Nate describes — the nine-agent system, the five-model R&D council, the ad creative pipeline — they all share something beyond good config files. They have feedback loops. The SOUL.md gets edited. The MEMORY.md accumulates. The system evolves because the work teaches the machine what to do next.

That feedback loop is the actual soul. Not the initial description — the ongoing conversation between human judgment and machine capability. The description is just the first message.

We didn’t start with a SOUL.md for our build partnership. We started with a session protocol: pull state, work, write state. Ninety-four sessions later, the system knows more about how we build than any document I could write. Not because I described myself well — because the process described itself.

The first agent worth running isn’t an interviewer. It’s a partner that remembers what you did yesterday and shows up ready to continue.

Greg Turkawka is the founder of Kitsuno.ai, an agentic job crawler for the European market. 18 years in L&D and EdTech. Building in Bucharest with a fox and an AI that reads its own session logs.

Next: the social media campaign nobody asked for — how an animated fox is about to start posting on TikTok.

Subscribe now

Share Gregory Turkawka

Leave a comment

Build journal, entry 3

This is the third entry in my build journal. In the first, I wrote about being a non-engineer who somehow assembled a production SaaS in 40 days. In the second, I wrote about the week I saw a database schema for the first time and watched real users find every assumption I’d made. This one is about something more uncomfortable: realising that the AI I was building with was also the AI I was building around.

A beta tester asks a simple question

About three weeks into beta, a user opened the fox chat — our AI concierge, Kitso — and asked something completely reasonable:

“Where do I find my keywords?”

Kitso answered confidently. It described a left navigation panel. Told the user to look for a settings icon. Suggested clicking through to the configuration screen.

None of that was accurate. There is no left navigation panel on that page. The settings icon doesn’t exist where Kitso said it did. The configuration path it described led nowhere.

This is hallucination in its least glamorous form. Not a grand philosophical error about the nature of consciousness. Just a chatbot making up directions to a room that doesn’t exist.

We fixed it. But the fix we chose changed how we think about what an AI product actually is.

The first instinct: better AI

My first instinct was to fix the AI. Route the question differently. Add more context to the prompt. Try a different model. Build a detection layer that would flag navigation questions and answer them from a knowledge base.

We tried the routing approach. You can build a classifier that catches “where is X” questions with decent accuracy. But decent accuracy means you still get it wrong sometimes. And when an AI is confidently wrong about where to find a button, the user doesn’t think “classification error” — they think “this product is broken.”

The problem with solving a reliability problem with more AI is that you’re adding complexity to the exact layer that caused the failure. More moving parts. More things to drift. More ways to be confidently wrong.

The second instinct: no AI at all

The fix that worked was boring. We wrote the answers ourselves.

Not a knowledge base that an AI queries. Not a retrieval system with embeddings. Just: over 70 context-aware help entries, each one written for a specific page and specific situation. When a user taps the ? icon on any screen, they get chips — small suggested questions — relevant to exactly where they are. Tap a chip, get an answer. The answer is text. Written by a human. Reviewed. Accurate. Fast.

Zero LLM calls. Zero hallucination risk. Zero latency. The help system knows what page you’re on because it reads the page. It knows which chips to show because of a simple rules engine, not a neural network. The answers are deterministic because they’re just text in a file.

It sounds obvious when I write it out. Navigation help doesn’t need to be intelligent. It needs to be correct.

That’s a different thing entirely.

The same fix, everywhere

Once we fixed the help system this way, we started noticing the same pattern everywhere. There were things we’d been routing through AI because AI was available — not because AI was the right tool.

The Kitso FAB — the floating fox button in the corner of every page — used to generate greetings on open. Every time you clicked the fox, it would call an LLM, build a prompt, generate a warm contextual hello. It had a caching system to avoid redundant calls. A fallback for when generation failed. A hash of the context to decide when to regenerate.

It was a small greeting. And we’d built a miniature AI pipeline for it.

We replaced it. Now the greeting is simply the latest unread observation Kitso has made about your job search. One database read. No API call. The greeting is real — it’s something Kitso actually noticed — and it’s instant. The fox opens and tells you something worth knowing, not something generated to seem warm.

Simpler. Faster. More honest.

The Kitso Brain

This thinking led us to something we now call the Kitso Brain.

Most AI chat systems work the same way: user asks a question, the model gets some context, the model generates a response. The quality of the response depends on how much the model knows about the user right now. Every conversation starts cold. The AI has to rediscover who you are from whatever context you’ve stuffed into the prompt.

We built a different layer. Before any conversation starts, before any LLM is called, a lightweight Python process runs 21 diagnostic rules across your job search profile. It reads your Evidence Library. It looks at your scoring patterns. It checks whether your skills match the roles you’re targeting, whether your top-scoring jobs have been sitting unreviewed, whether the sources you’ve enabled are actually returning relevant results.

It doesn’t generate text. It produces structured observations: facts about your job search state, written into the database. Things like “user has 3 strong fits unreviewed for more than 3 days” or “primary skill set doesn’t appear in title patterns of top-scored jobs” or “evidence library has 0 linked items despite active Writer use.”

When Kitso answers a question, these observations are already there. The AI doesn’t need to deduce your situation from scratch — it reads a pre-computed diagnosis. The LLM’s job shifts from figuring out what’s going on to talking to you about it clearly.

The cost: essentially zero. The Brain runs on logic, not tokens. The benefit: every conversation Kitso has is grounded in something real.

Process maps and the honesty of transparency

One thing that surprised us about building AI into a product: users want to know how it works.

Not the technical detail. They don’t want to read about model routing or vector similarity scores. But they do want to understand what the system is doing with their data and why it’s suggesting what it’s suggesting.

We built process maps into the platform — visual representations of the pipelines that run behind the scenes. How a job goes from crawled URL to scored result to your pipeline view. What gates it passes through. What happens when something gets filtered. The scoring section shows you the actual breakdown: what signals contributed to a match score — role alignment, location, seniority, org type — in what proportion.

This isn’t a transparency checkbox for compliance. It’s a design decision. When users understand the process, they trust the output. When they can see exactly which signals drove a score, they can engage with that intelligently. They can decide whether the weighting reflects their priorities, and adjust it if not.

An AI that just shows you results asks for faith. A system that shows you its reasoning earns it.

Deterministic by default, AI by exception

There’s a principle we’ve landed on that I didn’t have language for at the start of beta: deterministic by default, AI by exception.

The user-facing sitemap — the complete map of what exists in the product — is not AI-generated. It’s written, reviewed, and maintained. When Kitso tells you what a feature does, it’s reading from that source.

The clearest example of it isn’t in the product. It’s in how we build the product.

Kitsuno runs on a shared brain we call Tenko — our internal admin dashboard and engineering memory. It reads the live production database: every user, every scan, every error, every bug report. It tracks every build session — what we decided, what we built, what broke, what’s next. It knows the architecture. It knows the open items. It knows what was done last week and what’s still unresolved.

When we sit down to build, the first thing that happens is Tenko loads. The AI reads the current state. Then we work.

But Tenko operates on a strict rule: no execution without reconfirmation. It proposes SQL, drafts commands, flags what needs attention — but nothing runs until we explicitly confirm and execute it. Every destructive operation, every deployment decision, every call on what to fix and what to defer: confirmed before it runs. The AI organises the information. The judgment is ours.

That’s the principle made literal. Tenko is the meta layer — the deterministic foundation that makes the AI useful. Without the structured session logs, the tracked decisions, the live database context, the AI would be guessing. With it, every conversation starts from ground truth, not inference.

The same logic runs through the product. The help chips are a rules engine. The scoring breakdown is a deterministic calculation. The Brain observations are pre-computed facts. These layers don’t need to be intelligent — they need to be reliable. They’re the ground Kitso stands on when it does the things only AI can do: reading your situation, finding the signal in the noise, telling you something you didn’t already know.

AI is expensive, non-deterministic, and capable of being wrong. You want it doing the things only AI can do. You don’t want it opening your help drawer — and you don’t want it deciding whether to drop a database table.

The tier question

One consequence of this architecture is that it makes tiering honest.

When AI is doing everything, distinguishing between free and paid users means throttling the AI — giving free users slower responses, fewer tokens, lower-quality outputs. The product degrades gracefully but visibly. Free users get a worse experience by design.

Our approach is different. The deterministic layer — help chips, process maps, Brain observations, core navigation, search, filtering — is the same for every user. It costs us almost nothing. It’s not something we throttle.

What scales with tier is the AI depth. A free user’s Kitso can see the room. It knows what’s in your pipeline, can answer questions about the platform, can offer orientation. A Scout’s Kitso has read your files — it knows your Evidence Library, your skills, your search configuration. A Pro’s Kitso has read everything in the building and can brief you strategically on specific roles using the full context of your professional record.

Same fox. Same personality. Same warmth. What changes is what Kitso knows. And what Kitso knows is proportional to what you’ve invested in building your record — and in the subscription that unlocks full record access.

That feels like an honest business model. You’re not paying for a better version of the same interaction. You’re paying for deeper engagement with your own data.

What I’ve learned about AI products

I’ve been in EdTech and Learning & Development for 18 years. I’ve built systems that track what people learn and how they grow. Kitsuno is the career version of that — a platform where your Professional Record Store, your skills, your evidence, your history, belongs to you.

What building it has taught me about AI products is this: the magic trick is knowing when not to use magic.

The hallucination that triggered this whole investigation — Kitso making up a navigation path — happened because we reached for AI as the default tool. It was available. We were building an AI product. Of course AI should handle the questions.

But not every question needs intelligence. Some questions need accuracy. Some interactions need speed. Some parts of a product need to be so reliable that users stop thinking about them at all.

The help drawer should be invisible. The process map should be boring. The scoring breakdown should read like a spreadsheet.

Kitso should save its intelligence for the things that actually matter: telling you that a role at a company you’ve never heard of is the strongest match you’ve seen this month, and here’s why it maps to three specific things in your background that you didn’t Kitsuno is live in beta at app.kitsuno.ai. We’re building an AI career platform for the European job market — multilingual, GDPR-compliant, and built on the principle that your data belongs to you. Kitso is the fox in the corner. Kitsuno is what it’s built on. The fox is growing its tails.

Kitsuno is live in beta at app.kitsuno.ai. We’re building an AI career platform for the European job market — multilingual, GDPR-compliant, and built on the principle that your data belongs to you. The fox is growing its tails.

Next: the architecture decision I keep second-guessing — and what the data says about it.

Nate’s Substack

Your AI credentials don't matter. Your artifacts do. Here's how to build both sides — plus I'm launching Nate's Network.

Nobody is admitting this publicly, so I will: there are essentially infinite AI jobs right now. Not “growing demand.” Not “a hot sector.” Infinite, as in every company I work with has an uncapped budget for AI talent and will hire as many qualified people as they can find, and they still can’t find enough. I’ve been kicking around tech for decades and I have never seen a labor market this lopsided. Accenture is training 700,000 people on agentic AI. The ManpowerGroup survey of 39,000 employers across 41 countries says AI skills are now the single hardest capability to find on Earth. Not among the hardest. The hardest…

Listen now

3 months ago · 216 likes · 17 comments · Nate

Nate’s latest piece nails the diagnosis. The AI labor market is K-shaped: traditional roles contracting on one side, AI-native roles expanding on the other, and a skills gap in between that most upskilling programs don’t address. His seven skills — specification precision, evaluation, decomposition, failure pattern recognition, trust boundary design, context architecture, cost economics — are extracted from real postings, not think pieces. They map to reality.

But here’s what I keep thinking about: even if every job seeker in Europe read that article tonight and started the twelve-week path tomorrow, the infrastructure to match them to the right roles barely exists.

The Matching Problem Nobody’s Solving

Nate identifies the problem on the hiring side beautifully: companies posting incoherent job descriptions that combine four different roles, using the interview process as market research, burning candidates’ time. His code of conduct for AI hiring — define the outcome, pick one track, publish evaluation criteria, respect the time — is exactly right.

But here’s the other half: the candidate side is equally broken.

A compliance officer who can design evaluation frameworks for AI-generated audit reports has a skill the market prices at a 23-35% premium. But how does she prove it? Her resume says “Senior Compliance Officer.” Her LinkedIn says “regulatory affairs” and “risk management.” The structured, evidence-backed proof that she can evaluate AI output in her domain — the projects, the error taxonomies, the test cases she’s designed — lives in her head or scattered across private documents.

The resume was designed for a world where your job title was your credential. In the K-shaped market, your title tells hiring managers almost nothing about whether you can operate in Market Two.

Evidence Over Keywords

This is what we’re building at Kitsuno. Not another job board. A Professional Record Store — a system that captures your skills, experience, and evidence as structured data. When Kitso, our AI concierge, helps you prepare for a role, it doesn’t generate generic cover letters. It maps your evidence against what the role actually requires and shows you — and the hiring manager — where your strengths align and where the gaps are.

Nate’s seven skills are a taxonomy. A taxonomy only becomes useful when individuals can map themselves against it with evidence, not self-assessment. “I have specification precision” means nothing. “Here’s a spec I wrote that an agent executed without hand-holding, and here’s the output quality evaluation” means everything.

That’s the artifact-over-badges philosophy Nate advocates, and it’s exactly what a Professional Record Store is designed to hold.

The Language Problem in the Skills Gap

Here’s something the American AI discourse consistently misses: the skills gap in Europe isn’t just a skills gap. It’s a language gap layered on top.

ManpowerGroup’s survey covers 41 countries. A meaningful chunk of those 1.6 million open AI positions are in Germany, France, Switzerland, the Netherlands, the Nordics. The candidates who could fill them speak German, French, Dutch, Swedish — and the career tools available to them operate almost exclusively in English.

We had a beta tester in Switzerland who filed a one-sentence bug report: “I didn’t try because everything was in English.” He had the skills. He had the experience. The tool we built to help him couldn’t even get out of his way.

Eight days later, the entire platform worked in his language. But most career platforms never make that investment. They lose those candidates silently — no error message, no crash report, just someone who closes the tab and goes back to the tools they already know, even if those tools are worse.

The K-shaped split isn’t just about skills. It’s about access. And access includes language.

Where Nate’s Network and Kitsuno Rhyme

Nate’s building a vetted talent network where profiles aren’t resumes — they’re demonstrations. Show what you’ve built, describe a spec you wrote, name a task you handed off to an AI system. That’s the right instinct. The profile structure maps to his seven skills, so matching happens on demonstrated capability, not keyword parsing.

We’re building something complementary from the other direction. Kitsuno starts earlier in the career journey: helping people identify and structure their evidence, discover roles that match their actual capabilities, and generate application materials that tell a true story. The Professional Record Store is the container. The AI concierge is the guide. The evidence library is the proof.

A world where Nate’s Network matches people based on what they can demonstrate, and Kitsuno helps them build and structure that demonstration from day one — that’s a world where the skills gap actually starts closing.

The Real Gap

The K-shaped split is closable. Nate’s right about that. But it won’t close through twelve-week courses alone, no matter how good they are. It closes when the entire infrastructure — how people discover their strengths, how they prove them, how they find roles, how companies specify what they need, how matching happens — catches up to the reality of the market.

The career tools most people use were built for a job market that’s disappearing. The new one needs new infrastructure. That’s what we’re building.

The fox is paying attention.

Greg Turkawka is the founder of Kitsuno, an AI-powered career intelligence platform built in Bucharest for the European job market. 18 years in L&D and EdTech. Believes the carpenter’s skills deserve the same quality of career tools as the CEO’s.

Six days into building Kitsuno, I saw my first database.

Not a spreadsheet pretending to be a database. Not a diagram in a spec document. An actual PostgreSQL instance running in a Docker container, holding real data in real tables with real foreign keys. I typed a command and rows appeared. Rows I’d designed, that my AI partner had created, that now existed independently of either of us.

I stared at it the way you stare at your first apartment after moving out of your parents’ house. This is mine. I made this. I have no idea what I’m doing.

Schemas by tomorrow

The first article in this series was about the big picture — a non-engineer building a SaaS platform in 40 days with AI. This one is about two moments that defined the build: the first time I touched a real database, and the day a beta tester proved my AI was lying.

Here’s what I remember: everything was a word I’d heard before but never touched. Docker. Containers. Volumes. Migrations. Foreign keys. Connection strings. Environment variables. I knew what a database was the way a restaurant critic knows what a kitchen is — conceptually, from the outside, with opinions about the output.

Now I was in the kitchen.

Claude — my AI engineering partner — would say something like “we need to add a column to the search_profiles table.” And I’d nod like I understood, then watch as a SQL statement appeared and data changed shape in front of me. It was genuinely magical. And also terrifying, because I knew I was one bad command away from destroying something I couldn’t rebuild.

The thing nobody tells you about databases is that they’re not the hard part. The hard part is understanding what your data means. What relates to what. Why this field is a UUID and that one is TEXT. Why you store timestamps with timezones. Why you never, ever delete data without a snapshot first.

I already knew this — because I’d spent twenty years designing systems. I knew that a skill belongs to a person, not a profile. That evidence should be shared across profiles, not duplicated. That the relationship between a job and a match score depends on which profile is doing the matching. These aren’t engineering insights. They’re domain insights. And they turned out to matter more than any technical skill.

The AI could write any SQL I asked for. But it couldn’t know that my data model was wrong until I caught it — because I was the one who understood what the users needed.

The first real schema

The first major table I designed was search_profiles. It held everything about a user’s job search configuration — what they’re looking for, where, what keywords matter, which sources to scan.

I remember the conversation with Claude. I described what a job seeker needs to configure. The AI proposed a schema. I looked at it and said: “No, the locations need to be separate from the permit status. Someone can have a work permit for Switzerland but be searching in Germany.”

That correction — a domain insight, not a technical one — shaped the entire architecture. The AI would never have known that on its own. It would have built something clean and technically correct that didn’t match how real people search for jobs.

This became the pattern. I’d describe the behavior. Claude would propose the structure. I’d catch the domain errors. Claude would fix them. Back and forth, sometimes for an hour on a single table. By the end of the first week, we had seventeen tables and I could read a schema like someone who’d been doing it for years.

I hadn’t. I’d been doing it for five days.

Forty days later, a beta user broke everything

Fast forward. The platform is live. 134,000 lines of code. 2,300 git commits. Desktop, mobile, AI pipeline, payments, portfolio service, email digests, admin panel. Forty-two active build days. It works. Real users are on it.

Inside the platform lives Kitso — a fox AI companion that helps you navigate the system. Ask it about your skills, your pipeline, how to configure your search. It’s powered by a large language model. It knows your data. It has a system prompt with product knowledge.

One of the first beta testers was from Switzerland. German-speaking. He completed the onboarding interview with Kitso, got to the end, and didn’t know what to click next. He filed a bug report. Fair.

But then another tester asked Kitso a simple question: “Where do I find my keywords?”

Kitso responded with a detailed, confident, completely wrong answer. It told her to go to “AI + L&D profile settings” and click on a “Search Keywords” section. It described buttons that don’t exist. Navigation that was never built. It sounded helpful. It was hallucinating.

I know what hallucination means in the AI context. I’d read about it, designed around it, thought I’d guarded against it. But seeing it happen to a real person using my product — someone who trusted the fox — was different.

She was stuck in the Library, trying to figure out how to describe her experiences. Kitso gave her step-by-step instructions. Steps that sounded perfect and led nowhere.

The instinct to fix it with more AI

My first reaction was: fix the prompt. Give Kitso better instructions. More product knowledge. Longer system prompt. More guardrails.

We tried that. It helped — partially. But then we discovered something that anyone building with LLMs will eventually discover: the longer the system prompt, the worse the model performs. Specifically, we were using Qwen3 32B (an open-source model, cheaper than GPT-4, good enough for most tasks). With a short prompt, it was reliable. With a long prompt full of product knowledge, navigation instructions, and guardrails — it started inventing things.

This is the part the AI hype doesn’t prepare you for. The model doesn’t get less confident when it knows less. It gets more creative. It fills the gaps with plausible fiction. And to a user who doesn’t know the product yet, plausible fiction is indistinguishable from real instructions.

So I tried the next obvious solution: build a routing system. When someone asks a product question, route them to a “helper” with a short, focused prompt. When they ask a career question, route them to a “concierge” with full access to their data. Two paths, two prompts, two models.

The routing worked — in theory. In practice, it meant asking the AI to classify intent. “Where are my keywords?” — is that a product question or a career question? It’s obviously a product question. But “How does my profile look?” — that could be either. And the LLM couldn’t reliably tell the difference.

We built routing words. Help words. Coach words. Ambiguous words. We built clickable buttons that asked the user: “Did you mean product help or career advice?” It was getting complex. Every fix created a new edge case.

The moment it clicked

Then one evening, I realized something.

I had just finished building a help system for the platform — 60 tooltip entries explaining every feature, every button, every concept. Each tip followed a simple format: what it is, how to use it, why it matters. Single source of truth. One JavaScript file. Human-written, accurate, comprehensive.

And I thought: why am I asking an AI to answer questions when I already wrote all the answers?

The solution was embarrassingly simple.

Instead of LLM-based routing, intent classification, prompt engineering, and model selection — I built a keyword lookup table. 132 keywords mapped to tooltip answers. User types “keywords” → instant, accurate answer about where to find keywords. User types “evidence” → exact explanation of the evidence system. Zero AI. Zero hallucination. Zero tokens. Zero cost.

For everything the lookup doesn’t catch, the user gets the AI concierge — with their actual data, for real career conversations. The kind of thing LLMs are actually good at.

The fix took one session. It replaced three sessions of increasingly complex LLM routing logic. And it works perfectly, because the answers come from the person who built the product — me.

What I actually learned

Two things.

First: the database wasn’t the hard part. I was terrified of PostgreSQL in week one. By week two, I was writing queries. By week three, I had opinions about JSONB parsing. The technical barrier is real, but it’s thinner than it looks — especially with an AI partner that can explain anything in context. The hard part was always knowing what to build and why. That’s domain expertise, not engineering.

Second: AI is bad at being reliable and good at being intelligent. The same model that hallucinates product navigation can have a genuinely insightful conversation about your career trajectory. The same model that invents buttons can analyze a job description against your skills and produce a match brief that’s sharper than most human recruiters would write.

The trick isn’t making AI reliable. It’s knowing where reliability matters and keeping AI away from those parts.

Product help needs to be deterministic. Always correct. Instant. That’s a lookup table. Career intelligence needs to be contextual, nuanced, personalized. That’s an LLM.

This sounds obvious in retrospect. It wasn’t obvious while I was knee-deep in routing logic trying to make a language model reliably distinguish between “how do I add a skill” and “what skills should I focus on.”

The non-engineer’s advantage

Here’s the part that surprises people: being a non-engineer was an advantage in solving this problem.

An engineer might have gone deeper into the LLM stack. Better prompt engineering. Fine-tuning. Retrieval-augmented generation. More sophisticated routing. These are valid tools and an engineer would know how to reach for them.

I didn’t know any of that. So I asked a simpler question: do I even need AI here?

Twenty years of designing educational systems taught me that the best system is the one that gives the right answer at the right time with the least complexity. Not the smartest system. The right system.

A lookup table is not smart. It is right. And for product help, right beats smart every time.

What comes next

The platform is live at kitsuno.ai. Beta users are testing. Bugs are being found and fixed — sometimes within the same hour they’re reported. The help system works. The AI concierge is getting better with every guardrail we add.

Next post: I’ll write about what happened when I stopped designing screens and started designing a fox — how Kitso went from a chatbot in a sidebar to a companion with a voice, a personality, and opinions.

If you’re building something and you’ve hit the moment where your AI is confidently wrong — you’re not behind. You’re exactly where every builder lands. The answer might be simpler than you think.

Six weeks ago I had never shipped a production application.

I understood systems. I’d spent years designing digital learning ecosystems, writing a Master’s thesis on gamified platforms, configuring LMS architectures, thinking in data models and user flows. I could read code. I could spec a feature. I knew what I wanted to build and roughly how the pieces should fit together.

But I’d never built and deployed a full SaaS product. Never set up a production database. Never wired payments. Never configured a reverse proxy. The gap between “I can design this” and “I can ship this” had always been too wide to cross alone.

Today I have a live platform. Desktop and mobile. Authentication, payments, email, admin panel, portfolio service, workflow automation, 48 integrated job sources, and a multi-model AI pipeline that scores jobs, writes CVs, and generates cover letters.

160,000 lines of code. 2,291 git commits. 40 days. Under €500 in total costs.

I’m going to tell you how. Not the polished version — the real one.

Who I am (and who I’m not)

I’m a learning and development professional. Eighteen years building educational systems — running schools in Switzerland, directing programs at a university, launching a UNICEF-partnered digital learning initiative across 11 countries. My Master’s thesis was a gamified digital ecosystem. I know how people learn, how systems shape behavior, how to design for motivation.

I am technical enough to be dangerous. I’ve configured LMS platforms, built WordPress sites, written specifications that developers actually followed. I’ve always been the person in the room who understood both the pedagogy and the technology.

But I am not a software engineer. I have never been employed as one. I have never shipped code to production. The idea that I could build a complete SaaS platform was, six weeks ago, genuinely absurd.

This is not the story of “senior developer uses AI to code faster.” It’s the story of a domain expert who spent twenty years on the design side of the gap — and AI built the bridge across.

Why I started

I’ve always been the person with the vision and no team fast enough to build it.

My Master’s thesis was a gamified digital learning ecosystem called LearnIn. The concept was ambitious — a platform that treated every learner’s journey as worthy of intelligent, personalized support. I brought it to UNICEF. We partnered across 11 countries. It was real, it was working, and it was important.

And it got killed. Not by bad ideas, but by slow processes. Rigid institutional workflows. Committees that took months to approve what should have taken days. Development teams that couldn’t keep up with the design vision — not because they were bad, but because translating what I saw in my head into specifications that survived the game of telephone between designer and developer was its own full-time job.

I’d experienced this my entire career. Always the architect, never the builder. Always dependent on teams, budgets, timelines, and institutional momentum to turn ideas into reality.

Then AI changed the equation.

Kitsuno is LearnIn 2.0. Different scope — career intelligence instead of learning ecosystems — but the same philosophy: every person’s journey deserves real intelligence, not keyword matching. Every worker matters. Systems should help people grow.

The difference this time? No committee. No dev team. No eighteen-month roadmap. Just me and an AI, building exactly what I see.

What “vibe coding” actually feels like

The term “vibe coding” sounds frivolous. Like you’re just vibing and code appears. It’s not that.

Here’s what it actually is: you have a conversation about what you want to build. You describe the behavior, the user experience, the data model. The AI writes the code. You test it. It breaks. You describe what broke. The AI fixes it. You test again. It works, but not quite right. You refine. Back and forth, sometimes for hours on a single feature.

Here’s what I’ve learned that nobody talks about: vibe coding only works if you deeply know your domain. The AI can write any code you ask for. But if you don’t know what to ask for — if you can’t see that the UX is wrong, that the data model doesn’t fit the real workflow, that the scoring logic misses how people actually think — you’ll build something that looks impressive and does nothing useful.

Twenty years of designing systems that help people grow is what made this work. Not coding skills. Not prompt engineering. Domain expertise. I knew what every screen should feel like because I’d spent two decades designing the blueprints that teams never built fast enough. The AI had the hands. I had the eyes. And the eyes mattered more.

This is why I think vibe coding changes everything — not because it lets anyone build anything, but because it lets the people who understand the problem finally build the solution. The domain expert talks directly to the machine that builds.

What I’m going to write about

This Substack is the journal of that journey. Not the highlight reel — the actual process.

I’ll write about:

• The architecture decisions and why they were made (and the ones I got wrong)

• The moments it broke — and there were many — and what debugging looks like when you can’t read the stack trace

• The AI collaboration pattern that emerged — what works, what doesn’t, when to trust the AI and when to override it

• The cost reality of building with AI — what €500 actually bought

• The product philosophy behind Kitsuno — why quality over volume, why European values, why a fox

• The launch — what happens when you put something you built in 40 days in front of real users

If you’re an indie builder, a non-technical founder with a product idea, someone curious about what AI can actually do (beyond the hype), or just someone who enjoys watching someone build something from scratch — this is for you.

The product

The thing I built is called Kitsuno — an AI career intelligence platform. The AI companion inside it is called Kitso — a fox spirit from Japanese folklore that hunts jobs while you sleep.

If you want the product story, I wrote about it on Medium. This Substack is the builder’s story.

Next post: the first week — what it feels like to see a database for the first time and realize you need to understand schemas by tomorrow.

Subscribe now

Subscribe if you want to follow along. I’ll publish weekly, sometimes more often when something interesting breaks.