# Sam Erpik — full content > Bulk content dump for LLM ingestion. Last generated at build. > Index of pages: see /llms.txt. --- ## Case studies ### QuantumEye URL: https://erpik.com/case/quantumeye Role: Co-Founder · Product & Tech Lead Domain: EDGE AI · COMPUTER VISION Period: 2023 — Present Tagline: Real-time retail security, built on edge AI. **Problem** Retail loss prevention is stuck in 2010. Cameras are everywhere, but none of them think. Stores carry the cost of theft, staff time, and incident reports — while the data sits unused on a DVR in a back room. We asked a simple question: what if every camera could understand what it was watching, in real time, without sending video to the cloud? **What we built** - A multimodal vision pipeline that turns archived feeds and live streams into searchable, structured intelligence — like grep, for what the world looks like. - On-device inference on Jetson hardware so footage never leaves the store; latency is sub-200ms. - A dashboard for store managers that surfaces only the alerts that matter — not the noise. - Privacy-by-design from day one: faces are never stored, only event signatures. **Process** - 01 Field-walked the problem: Two weeks shadowing in stores before a single line of code. - 02 Spec'd the model and the team: Shortlist of 4 vision backbones. Picked the one that fit the smallest hardware budget. - 03 Shipped the spike: Working end-to-end MVP in 3 weeks — ugly, but real. - 04 Found 3 design partners: Cold-emailed loss-prevention leads. Two said yes the same week. - 05 Showed up at Retail Tech 2025: Demoed live. 8 conversations turned into a paid pilot. - 06 Now: scaling the GTM: Running follow-on pilots, refining the commercial model, and building the case for broader retail rollout. **Stack**: React, TypeScript, Python, ONNX, Jetson Nano, Postgres, Edge ML, Docker **Proof points** - 3 design partners - 9 wks from zero to first paid pilot - Retail Tech '25 live demo on the show floor --- ### Purple Luna URL: https://erpik.com/case/purpleluna Role: Founder Domain: AI RECEPTIONIST · WHATSAPP Period: 2022 — Present Tagline: An AI receptionist that runs the front desk for appointment businesses — on WhatsApp. **Problem** Purple Luna spent years as a digital agency, building websites, products and digital experiences for small service businesses one bespoke project at a time. Good work — but it only ever reached the clients who could afford a custom build. Then AI changed what a small team could ship, so we did the obvious thing: we took everything we'd learned about serving these businesses and turned it into a product. Luna is an AI receptionist that answers your business's WhatsApp — the channel your customers already use — books appointments, takes deposits, and runs the front desk 24/7, in your own voice. The agency built one great experience at a time. Luna gives every salon, dental practice, clinic and gym the same thing, switched on in an afternoon. **What we built** - Answers your business WhatsApp in seconds, as your business — warm and on-brand, never a robotic auto-reply. - Books appointments straight into your calendar, offers real open slots, and holds them with a deposit. - Takes payment the safe way: a secure link, never card details typed into the chat. - Knows your services, prices, hours and policies — and hands the conversation to you the moment it should, on anything about money, health, or a real judgement call. - Works while you're mid-appointment, closed, or asleep. No missed message, no walked-away booking. **Process** - 01 Connect your WhatsApp: Luna plugs into your existing WhatsApp Business number. Nothing for customers to download. - 02 Teach her the business: Services, prices, hours, the questions you answer fifty times a week. A few minutes, once. - 03 She answers, books, collects: Customers message like they always do. Luna replies, books the slot, takes the deposit. - 04 You get the clean handovers: Anything that needs a human lands on your phone with the full context attached. - 05 You get your evenings back: The front desk runs itself. You do the work you're actually good at. **Stack**: WhatsApp Business API, Claude / LLMs, Secure payment links, Calendar sync, Guardrails, React, Node **Proof points** - 24/7 never misses a message - < 60s average reply, day or night - £0 card details ever stored in chat --- ### WhotNow URL: https://erpik.com/case/whotnow Role: Co-Founder · Product Lead Domain: CONSUMER · NIGHTLIFE · VENUES Period: 2018 — 2021 Tagline: Real-time discovery for the city that's already happening. **Problem** Going out shouldn't require a 12-tab research project. WhotNow was a phone-shaped answer to 'what's actually on tonight — bar, club, restaurant, cafe — near me, that I'd actually go to.' Built before the AI hype cycle, when matching the right humans to the right room was still a hard product problem. **What we built** - Live discovery feed for nightlife, restaurants, bars, and cafes across Brighton & Hove — sourced from venues, promoters, and a small army of local editors. - A taste graph that understood you within 3 nights of using the app — not 30. - A two-sided platform: venues posted, users showed up, and the data flowed both ways. - iOS + Android with shared product surface. One product designer (me). One engineering team. Zero tolerance for feature bloat. **Process** - 01 Won a startup competition: WhotNow started as an MSc project, won a competition, then became a real company. The best kind of forcing function. - 02 Sketched the night out: Mapped the full user journey from 6pm to 3am before designing a screen. - 03 Hand-curated, then automated: Started by editing the feed manually. Wrote the algorithm only after we knew what good looked like. - 04 Launched in Brighton first: Saturated Brighton & Hove before considering any other market. - 05 Closed the loop with venues: Free dashboard. Venues came to us. Restaurants, bars, clubs — all in. **Stack**: React Native, Node, Postgres, Algolia, Mapbox, Stripe, Mixpanel **Proof points** - Brighton & Hove city launch market - 100k+ monthly actives at peak - Good lessons on what product-market fit actually means --- ## Writing ### Your vendor's camera is “96% accurate.” That's 40 innocent shoppers before lunch URL: https://erpik.com/writing/your-camera-is-96-percent-accurate Published: 2026-08-09 Tags: retail, computer vision, loss prevention, statistics, edge AI Every theft-detection camera quotes an accuracy number. It's the most honest-looking lie in the category — because at the rate real shops run at, a “96% accurate” camera is wrong about nine of every ten people it stops. There's a calculator; move the sliders. *Why "accuracy" is the number vendors lead with precisely because it hides what the camera does to your customers. There's a calculator below — move the sliders.* ## Is a "96% accurate" theft camera actually accurate? **The short version:** at the base rate a real shop runs at, a theft-detection camera a vendor can honestly call "96% accurate" still flags roughly 40 innocent shoppers before lunch, and is right about one time in ten when it points at someone. "Accuracy" is engineered to hide that. The number that actually matters — the one they never quote — is *precision*: when the camera accuses someone, how often is it right? A camera-AI vendor pitches you. Somewhere on the second slide: **99% accurate**. Some go higher — 99.9%, and up. It sounds like a solved problem. It isn't. Accuracy is the wrong number, and at the rate real shops run at, it's the wrong number *on purpose*. I've argued before that [most retail cameras record without understanding](/writing/cameras-that-dont-think). This is the flip side: even when the AI *does* understand, the number everyone buys it on is the wrong one. Here's the fact the deck skips: a shop is almost entirely honest people. Even with UK retail theft at record highs — [the BRC counted around 20 million customer-theft incidents last year](https://brc.org.uk/news-and-events/news/corporate-affairs/2025/ungated/retail-crime-spiralling-out-of-control/) — the person walking through your door is, overwhelmingly, not a thief. Call it one in two hundred on a bad day. That tiny base rate is where the number goes to die. Take a camera a vendor could *honestly* call 96% accurate. Nobody advertises 96% — they claim higher; I'm being generous. Point it at a normal morning and watch what it does. Move the sliders: how many shoppers, how rare theft actually is, how good the model is, how often it cries wolf. [Interactive demo: an interactive base-rate calculator showing how a high-accuracy theft-detection camera still flags mostly innocent shoppers (low precision)] Leave it near the defaults — a busy store, one thief in two hundred, a flattering 90% catch rate, a 4% false-alarm rate — and the same system that scores **96% accurate** flags about **forty innocent people before lunch**, next to four or five actual thieves. When that camera raises its hand, it's right about **one time in ten**. The gap between "96% accurate" and "right one time in ten" isn't a bug. It's the same system, described two ways: | The vendor's camera | Number | | --- | --- | | Headline "accuracy" | 96% | | Precision — chance a flag is a real thief | ~10% | | Innocent shoppers flagged | ~119 a day (~40 before lunch) | | Actual thieves caught | ~14 a day | *Worked example: ~3,000 shoppers, one thief in two hundred, a flattering 90% catch rate, a 4% false-alarm rate. Change any of them in the calculator above.* ## Why the accuracy number lies Accuracy asks: of everyone who came in, what fraction did the system judge correctly? When 199 of every 200 people are innocent, you get almost all of that score for free — for correctly ignoring the honest crowd, which is the easy part. Here's the tell. A camera that flags *nobody* — unplugged, a brick — scores about 99.5% accurate at these rates. It never catches a thief and it still beats the "96%" system on accuracy. Any metric a brick can win is not measuring the thing you care about. The thing you care about is **precision**: when the camera points at someone, how often is it right? That's what decides whether your staff are stopping shoplifters or stopping shoppers. And it's the number that quietly collapses when theft is rare — there are simply so many more innocent people to get wrong. To make even *half* your flags real thieves, you'd need a false-alarm rate under half a percent. Almost nothing in the wild hits that. This isn't a hot take. It's the [base-rate fallacy](https://en.wikipedia.org/wiki/Base_rate_fallacy), a first-week statistics result: when the thing you're hunting for is genuinely rare, even a tiny false-positive rate produces far more false alarms than real hits. Run the numbers on any "99-point-something" system at a real shop's base rate and you land in the same place — most of what it flags is innocent. ## The false positives aren't rounding errors. They're people. A "flag" doesn't stay an abstraction. It becomes a member of staff walking over. The clearest record of what that looks like at scale comes from the US, where in 2023 the [FTC banned Rite Aid from facial recognition for five years](https://www.ftc.gov/news-events/news/press-releases/2023/12/rite-aid-banned-using-ai-facial-recognition-after-ftc-says-retailer-deployed-technology-without). The system generated thousands of false-positive matches; shoppers were followed around stores, searched, told to leave without their purchases — prescriptions included — publicly accused, and in some cases had the police called, all on a bad match. Those are the ones that ended up in an enforcement order. Most false flags just make someone's afternoon worse and never get written down. And the errors don't land evenly. The FTC found Rite Aid's system was especially likely to misfire on Black, Latino, Asian, and women shoppers — and it isn't a one-off: [NIST's landmark study](https://www.nist.gov/news-events/news/2019/12/nist-study-evaluates-effects-race-age-sex-face-recognition-software) found many face-recognition algorithms produce 10 to 100 times more false positives for some groups (to be fair, several of the most accurate systems showed little gap). A blended "96%" hides who actually pays for the other 4%. ## "But a human reviews every alert" This is the standard reply, and it's worth taking seriously — because it's exactly what vendors say when it goes wrong. The line is almost always the same: the technology worked, a human just made the final call badly. But a human in the loop doesn't fix the system's precision. It hands your staff forty alerts a morning to adjudicate, and two things happen. Either they trust the confident AI and wave it through — now you've *automated* the accusation — or they drown, tune it out, and stop looking by week three. Either way you've rebuilt the thing I keep complaining about: a screen full of alerts nobody reads. A camera that cries wolf forty times before lunch doesn't earn a human's attention. It burns it. ## Ask the only question that matters None of this means the tech is useless. It means "accuracy" is marketing, and you should refuse to buy on it. Three questions cut through the deck: - **What's your precision** — at *my* store's base rate, not a lab set? If they can't answer, they've never measured how many flagged shoppers were innocent, because they have no way to. - **How many false accusations a day** does that precision imply at my footfall? Put a number on the people, not just the catches. - **What does one false positive cost** — the stopped customer who never comes back, the staff time, the headline? The real fix is upstream. Stop trying to recognise *a thief* — a rare, low-signal needle — and detect a *specific behaviour* with enough signal that precision is high by construction. Fewer flags, and the ones you raise are mostly right. That's the whole reason [QuantumEye](https://quantumeye.co.uk) reads what's happening on the shelf instead of scoring who's standing in front of it. When a false positive is a person, precision isn't a nice-to-have. It's the product. So the next time a camera vendor opens with an accuracy number, you already know the follow-up: *when your camera points at one of my customers, how often is it wrong — and who pays for it?* *I build [QuantumEye](/case/quantumeye), and through [Purple Luna](https://erpik.com/case/purpleluna) I build Luna, an AI receptionist for appointment businesses. The calculator above is a worked example, not a measurement — plug in your own store's numbers.* --- ### I stopped shipping screenshots URL: https://erpik.com/writing/i-stopped-shipping-screenshots Published: 2026-07-17 Tags: design systems, prototyping, figma, front-end, AI Closing the gap between design and engineering, back when a prototype was a picture and now that it's code. With a few live demos you can poke at, including a component X-ray. *How coding our prototypes closed the gap between design and engineering, and turned the prototype into a design-system adoption tool. Poke at the demos as you read.* ## Why ship coded prototypes instead of screenshots? Because a screenshot shows one state, and a product is made of states. A coded prototype behaves — it handles empty fields, error states, and different roles, prefills its own forms, and can X-ray your design system as people use it. AI made that cheap, so the prototype stopped being a throwaway sketch. For years the handoff looked like this. A designer finishes a screen in Figma. It gets thrown over the wall to engineering. Engineering squints at a flat picture and guesses at the parts the picture can't show: what happens when the field is empty, what a broker sees versus an admin, what the error state does. Everyone means well. The gap opens anyway. I [work across design and engineering](/about) on a large, regulated financial product, and that gap was the expensive part. Not the design. Not the build. The space in between, where a static mockup meets a real system and the two quietly disagree. [Interactive demo: a renewals product dashboard with a customer/admin view toggle] ## A picture can't answer the interesting questions A mockup shows you one state. Products are made of states. Filled, empty, loading, error, this role, that permission, the edge case nobody drew. Here is the shape of the problem, and where it gets solved. [Interactive demo: the prototype as the bridge across the design and engineering gap] Figma is still the source of truth for the look. That is not changing, and it should not. Plenty of designers are design-first and want to stay in Figma, and the moment you force them into a code editor you lose the thing that made them good. So Figma stays where the visual truth lives. The truth about *behaviour*, though, lives somewhere else now. ## AI moved prototyping into code, so I followed it there Spinning up a coded prototype used to be a luxury you couldn't justify. It's not anymore. The cost of getting a real, clickable thing on screen has dropped through the floor, so the prototype stopped being a throwaway sketch and started being something closer to the product. Once it's code, it can do what a picture can't: it can *behave* — the same shift that later [made my portfolio act instead of just sit there](/writing/why-portfolio-is-agent). And once it behaves, you can hand a stakeholder something that answers their questions before they ask them. Take roles. Our product shows a completely different surface depending on who's logged in. In Figma that's three files to keep in sync forever. In a coded prototype it's one thing that changes. [Interactive demo: a permission-driven UI that changes with the selected role] Same prototype. The layout, the navigation, the permissions all follow the role. Nobody has to imagine the admin view. They click into it. Then there's the boring stuff that quietly decides whether a prototype gets used. We have a lot of forms. If a tester has to fill twelve fields by hand every single time they want to reach the screen after the form, they stop testing. So the prototype prefills itself. [Interactive demo: one-click prefilled form states] One click, and you're testing the interesting screen instead of doing data entry for the tenth time today. Small thing. It's the difference between a prototype people actually open and one they don't. ## The design system's real problem was never the design Here's the part I'm proudest of, and it has nothing to do with how anything looks. Design systems don't fail at design. They fail at adoption. You can build a beautiful, well-documented library and still watch engineers ship a one-off button because they didn't know the real one existed, or couldn't tell whether the thing on screen was the system component or somebody's copy of it. So I built an X-ray. Flip a toggle on the prototype, hover any component, and it tells you what it is, whether it's published in the system, and whether it's actually in use. One hop to the Figma reference. One hop to the docs. The prototype teaches the design system while people use it. [Interactive demo: an X-ray that names each component and shows whether it is published in the design system and in use] That amber one is the whole point. An in-use component that never made it into the system is exactly the kind of drift you can't see in a screenshot and can't feel in a spec. Made visible, it becomes a five-minute fix instead of a slow rot. ## It lives at one URL None of this matters if it sits on my laptop. The prototype is served org-wide from a single link, so the PM, the engineers, the stakeholders, and QA are all looking at the same living thing instead of arguing over which version of which PDF is current. [Interactive demo: the prototype X-ray in context — an inspector panel naming the PolicyCard component and showing its JSX] A shared, behaving, self-documenting prototype turns out to be less of a design artifact and more of a piece of infrastructure. It's the one place design and engineering can stand together and point at the same reality. ## The takeaway Keep Figma as the source of truth for how things look. Let design-first designers stay there. But stop treating the prototype as a screenshot with delusions. Now that code is cheap, make it behave like the product: give it states, give it roles, give it prefill, and let it tell you the truth about your own design system. I stopped shipping screenshots. I started shipping something people could actually use to make decisions. The gap got a lot smaller. [Interactive demo: a closing card: a prototype your team can actually use] *This is the kind of work I did through [Purple Luna](https://erpik.com/case/purpleluna) — now an AI receptionist for appointment businesses, answering WhatsApp and booking appointments 24/7. The demos above are generic illustrations, not the real product.* --- ### Cameras are everywhere. None of them think. URL: https://erpik.com/writing/cameras-that-dont-think Published: 2026-06-15 Tags: retail, computer vision, edge AI, loss prevention, QuantumEye Most retail crime walks out past cameras that record but don't understand. The actual hard problem in retail loss prevention, with sources. *Why throwing more cameras at retail theft stopped working, and what the back-room DVR is actually telling you.* ## Why doesn't all that CCTV stop retail theft? Because recording isn't the same as understanding. A DVR captures theft but never comprehends it, so the footage piles up unwatched until long after the goods have gone. What actually stops theft is a camera that recognises what's happening as it happens — on-device, in under a second — so a manager can reach the aisle while it still matters. UK retail crime cost the sector [£4.2 billion in 2023/24](https://brc.org.uk/news-and-events/news/operations/2025/ungated/brc-retail-crime-survey-2025/). £2.2 billion of that walked out in customers' pockets. 20 million theft incidents that year. 55,000 a day. Most of it walked out past cameras that were recording. The footage exists. It sits on DVRs in back rooms, taped over on a cycle, watched by precisely nobody. The £4.2 billion did not walk out past blind cameras. It walked out past cameras that saw everything and understood nothing. ## Cameras are everywhere. None of them think. Walk into that back room. The DVR hums. Dozens of little tiles, all updating in real time, watched by precisely nobody. The store manager has a day job, and that day job is not staring at a monitor wall. Most retail security is still recording, not understanding. The data exists. It just sits there until something goes wrong, at which point the manager scrubs through hours of feed looking for a handful of seconds. A several-hundred-store chain with ten checkout lanes is sitting on [roughly 1,000 years of video at any given moment](https://ecrloss.com/research-paper/retail-cctv-strategy/). Nobody watches most of it. By the time the clip is found, the goods are already moving through the [resale rings the BRC flags as a growing organised retail crime threat](https://brc.org.uk/news-and-events/news/operations/2025/ungated/brc-retail-crime-survey-2025/). It isn't the lone opportunist anymore. It's a supply chain. Recording has been a solved problem for years. Understanding hasn't. The industry kept selling more recording and calling it progress. ## The old answers all assumed someone was watching Every old answer in retail loss prevention shares one flaw. It assumes someone was watching, and it only ever tells you about thefts that already happened. Three examples. More cameras. The thinking was: if the current rig misses it, add more. They didn't catch it, because nobody was watching the current rig either. Adding cameras to an unwatched system gives you more unwatched footage. The [research backs it up](https://pmc.ncbi.nlm.nih.gov/articles/PMC3897661/): 66% of people paid to watch CCTV miss an unexpected event in plain view. Experienced operators miss 61% of task-relevant ones. Even when humans are watching, they mostly aren't. More guards. A guard is expensive, and a guard cannot stand in every aisle at once. One person watching the door is one person not watching the spirits aisle. The maths doesn't work, and every store manager I've sat with already knows it. Post-incident analytics. Dashboards that tell you, on a Monday morning, how much you lost last week. Pie charts of stolen categories. Heat maps of high-shrink zones. Good for the Monday morning report. No help to the manager who's on the floor at 4pm on a Tuesday watching it happen. All three share the same shape. The thief already left. You are looking at a record of a thing that is now finished. The only question left to ask is how much it cost. And the number is climbing. [530,643 shoplifting offences in the year to March 2025](https://www.ons.gov.uk/peoplepopulationandcommunity/crimeandjustice/bulletins/crimeinenglandandwales/yearendingmarch2025). Up 20% in a year. Highest since records started in 2003. ## What changes when the camera understands the scene Better cameras are not the shift. They have been fine for years. 4K, decent low-light, more than enough resolution to see what is happening. The shift is the camera knowing what it is looking at while it is looking at it. Easy to say in a deck. Hard the first time you try to build it. I spent two weeks shadowing in stores before writing a line of code, because the actual signal is mundane and you only learn it by standing there. Someone hovers near the spirits shelf. Their bag changes shape. They walk past the till without breaking stride. None of those three things, on their own, mean anything. Together they mean something specific. The job is teaching a model to notice that combination, on-device, in under 200 milliseconds, without sending a single frame to the cloud. I have watched it work on a Jetson the size of a paperback book, sitting in [a working deployment](/case/quantumeye). The hardware has been ready for a while. We were the bottleneck. This is what we are building at [QuantumEye](https://quantumeye.co.uk/). ## The hard part nobody talks about is the edge cases Classification is where the demo always wins and the deployment usually loses. A teenager loitering and a parent waiting for their kid look identical to a naive model. Same posture, same dwell time, same glances at a phone. A staff member restocking the spirits shelf moves the same way as someone lifting from it. Reach, grab, turn. Fire on motion alone and you've built a pager that pages the manager every time someone restocks. 📟 The privacy gate makes it harder. Faces never stored. Only event signatures, anonymised, ephemeral. That's the right call, and it's the thing that takes face recognition off the table. You cannot build a watchlist of "known thieves" because you cannot store who anyone is. You have to read the scene itself and decide what is happening from movement, geometry, context, and what is in someone's hands. Most of the work is in the cases that don't look like anything. Telling a manager from a thief. Telling an alert from noise. Telling a kid reaching for sweets from a kid pocketing them. Get that wrong and the dashboard becomes the new DVR, ignored by week three because the manager learned it cries wolf. That false-alarm trap is worse than it looks — it's [why a "96% accurate" camera still cries wolf](/writing/your-camera-is-96-percent-accurate). The interesting model work is not the detection. The hard bit is knowing what to ignore. Get that wrong and the manager mutes the app by Tuesday. ## Real-time comprehension is the actual product Step out of the back room for a second. The shift here is not "AI in retail" in the marketing sense. That version of the story is exhausting and the store managers stopped listening to it years ago. At [QuantumEye](https://quantumeye.co.uk/) we are trying to build something that notices a theft while it is happening, not after. The shop floor is the test. If the alert doesn't help the manager intervene in the next minute or so, it isn't worth sending. Anything slower than that is just a more expensive version of the DVR. A PDF of last Tuesday's losses is still last Tuesday's losses. The camera that thinks is only useful if it earns the manager's trust on the first day. They will give you a handful of alerts. If most of them are noise, you are uninstalled by Friday. There is no second deployment. Retail managers have strong opinions about software that wastes their time. 🚪 Everything else, the model, the Jetson, the dashboard, the inference pipeline, is plumbing for one moment. A manager glances at their phone, sees one alert, and walks to the relevant aisle. Recording is an insurance policy. Comprehension is an intervention. Retailers spent [£1.8 billion on CCTV, guards and hardware in one year](https://brc.org.uk/news-and-events/news/corporate-affairs/2025/ungated/retail-crime-spiralling-out-of-control/). Crime kept climbing. Staff violence is [finally bending](https://brc.org.uk/news-and-events/news/operations/2026/ungated/brc-crime-report-2026/) after a cumulative £5.5bn of spend across five years, dropping from roughly 2,000 to 1,600 incidents a day. The theft number isn't. The next chapter is comprehension, or it is the same numbers, every year, on a different DVR. *Public retail-crime figures cited from sources below. [QuantumEye](https://quantumeye.co.uk/) deployment data not disclosed in this piece.* ## Sources - [BRC: Retail crime 'spiralling out of control' (2025 Crime Survey)](https://brc.org.uk/news-and-events/news/corporate-affairs/2025/ungated/retail-crime-spiralling-out-of-control/) - [BRC: Retail Crime Survey 2025](https://brc.org.uk/news-and-events/news/operations/2025/ungated/brc-retail-crime-survey-2025/) - [BRC: Crime Report 2026](https://brc.org.uk/news-and-events/news/operations/2026/ungated/brc-crime-report-2026/) - [ONS: Crime in England and Wales, year ending March 2025](https://www.ons.gov.uk/peoplepopulationandcommunity/crimeandjustice/bulletins/crimeinenglandandwales/yearendingmarch2025) - [ECR Retail Loss: Retail CCTV strategy](https://ecrloss.com/research-paper/retail-cctv-strategy/) - [Näsholm, Rohlfing, Sauer (2014): Inattentional blindness in CCTV monitoring (PMC)](https://pmc.ncbi.nlm.nih.gov/articles/PMC3897661/) --- ### Why I made my portfolio an agent, not a document URL: https://erpik.com/writing/why-portfolio-is-agent Published: 2026-05-28 Tags: agentic web, personal sites, AI, design Four moves I made on erpik.com this year — an AI terminal, a labelling cursor, a live presence dot, and a couple of files agents read. Pull back and they all point at the same thing: a portfolio in 2026 should respond, remember, and act. ## How do you turn a portfolio into an agent instead of a document? You give it three jobs a document can't do: respond, remember, act. On erpik.com that's an AI terminal that answers in my voice, a live dot showing when I'm at my desk, a cursor that names every action, and an llms.txt that tells AI crawlers how to describe me. The infrastructure's boring now; the decision is the rare part. My old portfolio loaded, showed you my work, sat there. A reader scrolled, maybe clicked a case study, maybe didn't, left. Same artefact whether they came at 9 a.m. on a Tuesday or 1 a.m. on a Sunday — whether they were a recruiter, a founder, or another engineer just curious. A document. This year I rebuilt it as something that **acts** — [the same shift I made when I stopped shipping screenshots](/writing/i-stopped-shipping-screenshots), one scale up. Four moves. None of them new on their own — all of them quietly converging on the same idea: in 2026, the website that wins is the one that responds, remembers, and *does things*. Not the one that's the prettiest static page. ## 1. The terminal that knows me There's an AI on the homepage called **Ask Sam**. Tap the backtick on your keyboard and a terminal slides in. Ask it anything about my work, what I'm building, whether I'm free. It runs on Claude, knows my case studies and current focus, and answers in my voice with a five-questions-a-day limit so it stays a real conversation, not a costed-out chatbot. This bit isn't novel. What's novel is what it *replaces*. The Ask Sam panel does the job that [a 600-word "About" page](/about) used to do — except it answers the question you actually had, not the question I guessed you'd have. ## 2. The cursor that names every action Hover anything on the site. A small label trails the cursor: **OPEN**, **READ**, **EXPLORE ✦**, **ASK ↳**, **JUMP ⌘**. Every interactive surface tells you what'll happen before you click. Looks like a flourish. It's actually a thesis. UI in the 2010s was about reducing clicks. UI in the 2020s is about reducing *uncertainty* — telling the visitor what they're about to do, in plain language, before they commit. AI interfaces already do this everywhere ("are you sure?" "this will…"). I just brought it to the cursor. ## 3. The live presence dot There's a small dot in the nav. When it pulses green and says **Here.**, I'm actually at my desk right now. My laptop pings a serverless function every 60 seconds when I'm not idle. The site knows. After 15 minutes idle it goes amber: **Around.** After four hours: **Off for the night** / **Off for the weekend** / **Out today** — picked from UK clock and weekday. When I'm travelling I curl an override: *"Off-grid, back Tuesday."* No randomness; pure clock math. This is the move that surprised me most. People who'd never have DM'd a stranger felt OK to drop me a quick note when the dot was green. "Hey, you're at your desk — quick question." That little signal of *aliveness* did more for my reply rate than any contact form. ## 4. The bits agents read Two files at the root nobody sees: `/llms.txt` and `/robots.txt`. `llms.txt` is a markdown summary written *by me, for LLMs*. When ChatGPT or Claude or Perplexity is asked "who is Sam Erpik?", they don't have to scrape my LinkedIn bio and guess — they read my pitch. The framing I'd want a stranger to encounter. `robots.txt` explicitly invites every AI crawler I know of: GPTBot, ClaudeBot, PerplexityBot, Google-Extended, the lot. Most React templates ship blocking them. I reversed the default. I *want* to be in their answers. And the homepage's JSON-LD now has a `FAQPage` schema that mirrors the questions Ask Sam expects. The structured-data signal Google's AI Overviews use to pull "is Sam free for a project?" straight into their answer card. These are tiny files. They might be the most important ones on the site. ## The shape underneath Pull back. The four moves all point at the same thing. A portfolio in 2026 should **respond** (Ask Sam answers your question), **remember** (the site has state — my live presence, your last visit), and **act** (the cursor names the action, the dot reflects reality, the llms.txt speaks to agents). Old shape: I put my work in a document. You read it. Maybe you contact me. *Maybe.* New shape: my site is a small, partial version of me, available to whoever needs it. It talks. It knows when I'm around. It tells AI agents how to describe me. It does some of the work a real conversation would do. That isn't extra. That's just where the medium is going. ## What's coming The honest next step is an MCP server at `mcp.erpik.com`. Anyone using Claude Desktop, Cursor, Goose — any of the agent IDEs — could connect their AI to me as a *tool*. Five functions: `get_bio`, `list_case_studies`, `get_availability`, `ask_sam`, `get_presence`. Someone's AI could query me directly without ever loading my homepage. That's the move that turns a website into an *agent surface*. I'll ship it when more people use MCP clients (probably six months out — I'd rather be the early example than the late convert). ## Why this should matter to you If you have a personal site, you have a decision to make over the next 12 months. You can keep treating it like a static document — a brochure that scales linearly with how much time you spend on it. Or you can start treating it like a small, partial agent — one that knows you, talks for you, signals when you're around, and tells the AI ecosystem how to summarise you. The infrastructure to do this is now boring. Claude API, a few Netlify functions, a markdown file at `/llms.txt`. None of it is exotic. The thing that's still rare in 2026 is *the decision to do it*. I made it. Here's the site that came out of it. --- *Ask Sam directly — backtick on the homepage. Or just email me.* ---