Sammy

Role: Prototype architecture, prompting, and technical build · Team of two · Built with GitHub Co-Pilot (pre-agentic), Python, and the OpenAI API

The problem

Job-seeking assumes a lot about the person doing it. It assumes you can read a formal job description and translate its bureaucratic language into a picture of your actual day. It assumes you can judge, unprompted, whether a role fits your abilities, your limits, and the things you happen to love. For a job-seeker with a cognitive disability, those assumptions quietly become barriers – not because the person can't do the work, but because the process was never built with them in mind.
I built Sammy with , for Samhall, a Swedish state-owned company that employs people with disabilities and helps them move into the open labour market. My team-mate brought caretaker experience to the project, and that perspective shaped the whole thing from day one. Early on she said something that became our north star: "It's crazy – the process is not adapted at all. It works the same as for you and me."
We didn't set out to redesign Samhall's administrative systems. We set out to build a layer that sits between the person and those systems – one that could take a rigid, formal process and make it feel human. The question we ended up chasing:

How might a conversational interface make formal job-seeking legible – and even personal – for someone with a cognitive disability?

What I built, and how it changed

The interesting part of this project isn't the finished agent. It's the four versions it took to get there, and the specific failures that forced each rebuild.

v0 – Proving the idea inside a chat interface

I started in the fastest environment I had: Claude's Project interface, no code. I wanted to know whether an LLM could take a dense job posting and re-explain it in warm, simple language – before I invested in building anything.

Three pieces did the work: a system prompt defining the agent's job (interpret and simplify postings), a style prompt tuned toward plain, gentle, near-child-like language, and a real job description loaded into context to test against.

It worked better than I expected. Fed a supermarket cleaning posting, the agent explained it as early-morning work, alongside friendly people, keeping the store nice for customers – accurate, but stripped of bureaucratic fog and delivered with encouragement. The concept was sound.

The limit showed up fast: a chat interface gives you almost no control over multi-turn structure. I couldn't shape how a conversation unfolded, branch it, or pass information between stages. To build a real interaction, I had to leave the sandbox.

v1 – Two sessions, and the first real architecture

I moved to Python and the OpenAI API, using GitHub Copilot to keep the build moving quickly. This is where Sammy became a system rather than a prompt.

The key move was splitting the interaction into two distinct sessions: one to get to know the user through open-ended conversation, and a second to explain jobs in light of what the first session learned. A summary of the user's interests passed from one to the other.

The payoff was immediate and, frankly, the moment I knew the idea had legs. When I role-played a user who loved trains, the second session reframed a supermarket cleaning role as "like driving a cleaning train, but on the supermarket floor." The system wasn't just simplifying language anymore – it was translating a job into someone's personal world.

v2 – Adding job description fit evaluations

v3 – Adding caretaker expertise, and hitting the wall

A user's own account of themselves isn't enough. The people who know a job-seeker's real capabilities and limits – when that person has a cognitive disability – are often their caretakers. So I added a Caretaker Chat to capture that domain knowledge, and an Evaluate Fit reasoning step to weigh job descriptions against the combined profile.

This is where Sammy broke in the most instructive way.
Despite an explicit reasoning step, the system kept recommending a chocolate factory position – and kept ignoring the disqualifying facts sitting right in the profile: workload limits, allergies. It had latched onto the role's surface appeal and shortcut past everything that made it a bad idea.
That bug taught me more than any success in the project. A reasoning step is not the same as prioritisation. Asking a model to "evaluate fit" doesn't mean it will correctly weigh competing, conflicting criteria – it will happily find a reason to justify the appealing answer. If I was building this for people whose wellbeing depended on getting the recommendation right, "usually reasonable" was not good enough.

v4 – Structure over trust

The fix wasn't a better prompt. It was refusing to let the model make the judgment call in one leap.

I added two more steps: a structured Caretaker Discussion to surface and prioritise the concerns that actually mattered for a given person, and an explicit Rank Fit reasoning step that ordered opportunities against those stated priorities rather than the model's own sense of what sounded nice. The final flow ran as a pipeline – get to know the user, capture caretaker expertise, evaluate and rank against real constraints, then explain the top opportunities and generate a personalised motivational letter for the chosen role.
It roughly doubled the architectural complexity I'd planned for. It also made the results consistent and reliable – the chocolate factory stopped winning. The complexity wasn't over-engineering; it was the cost of building something trustworthy for people who couldn't afford for it to be wrong.

What I did versus what we did

I owned the technical side: the prototype architecture across all four versions, the prompting design, the reasoning steps, and the build. My team-mate led user research and, crucially, grounded every decision in her caretaker experience – she was the reason we caught fit problems I'd have rationalised past, and the two of us made a phenomenal co-design partnership because of it. The two-session, caretaker-aware structure came directly out of her insistence that the user's voice and the caretaker's expertise were different inputs that both mattered.

What I took from it

I set out asking whether a machine could make a process more empathetic. The honest answer I landed on is more useful than a yes.
An LLM can reproduce the patterns of empathy convincingly – enough to make a bureaucratic process feel warm and legible to someone who found it opaque. That's real, and it matters. But reproducing empathy is not possessing it, and the gap becomes most dangerous exactly where it's most tempting to ignore: when the user is vulnerable and the warm-sounding answer is the wrong one. The chocolate factory bug was a small, funny version of a serious risk.
So the value isn't a machine that replaces human judgment. It's a machine that scales the accessibility work a human support network already does – with a human staying in the loop as supervisor and mediator, not spectator. Sammy made me a more careful builder: quicker to prototype, and much slower to trust a system's judgment just because its output sounds kind.
This began as a course prototype rather than a deployed product – but it's the project that most shaped how I approach building AI for people who can't afford for it to fail quietly.

The architecture – staged orchestration.
"Sammy" is a multi-step pipeline built to make job-matching more accessible. It goes well past prompt engineering:
— Sammy interviews both the applicant and their support person, adapting to each
— separate evaluation and ranking passes run in the background to identify the strongest matches
— a final pass introduces the best fit and generates a motivational letter in the applicant’s own voice.
Samhall is one of Sweden’s largest employers, with a social mandate to create accessible work. Built with Sigga Heimis – former Design Project Manager at IKEA. Delivered through my Hyper Island cohort.