Alfred
Persson

Senior AI Engineer

I build AI products that prove they work, on every change.

End-to-end ownership: user discovery, system design, shipping, and grading the AI's output against real examples.

Previously tech lead at ChromaWay. After that I built SveaSync, an AI assistant platform for local businesses.

Alfred Persson

Stockholm (Q1 2027)

I'm trained in interaction design, so I start with what the user is trying to get done, and I use error analysis to find where the product fails to deliver it.

What end-to-end ownership means, concretely:

Start from the user's problem.

I talk to users to understand what they are trying to get done, and use AI only where it is genuinely the best tool. AI inference is the slowest, most expensive, and least predictable way to solve a problem, so every part of a feature that can be ordinary software should be.

TechnicalJobs-to-be-done discovery; deterministic logic wherever possible; model calls reserved for the steps that need judgment or language.

Design the right kind of system for the task.

That can be a normal, predictable workflow that calls AI for specific steps, a system that searches your own data before answering, or an agent that plans and acts on its own. I pick the shape by the task, and keep everything around the AI boring and reliable.

TechnicalDeterministic workflows with LLM steps, RAG pipelines, tool-using agents, human-in-the-loop escalation, multi-tenant isolation.

Agree on what "working" means before building.

Before writing code, I collect real example inputs and write down what a correct result looks like for each one. Those examples become automatic checks that run on every change, showing whether each change made quality better or worse.

TechnicalHand-labeled eval sets with pass or fail criteria, run in CI as the regression suite.

Plan for the model being wrong.

A model will be wrong some of the time, so I design that moment on purpose: what the user sees, when the system says it is not sure, and when a human takes over. Every failure that shows up in production becomes another automatic check, so the same mistake cannot return unnoticed.

TechnicalConfidence gates, designed fallback and escalation paths, production errors converted into permanent CI test cases.

Measure whether it actually helps.

I track whether the feature helps in numbers: who uses it, whether it resolves what they came for, and how good the outputs are, checked by both humans and automated grading.

TechnicalProduction trace analysis, LLM-as-judge scoring validated against human grading, quality and usage metrics per release.

Languages

TypeScript and Node.js, Python and FastAPI, SQL and Postgres. React and Next.js when the work needs it.

LLM engineering

agent and tool design, RAG pipelines, structured outputs, streaming, runtime guardrails, human-in-the-loop design, multi-tenant isolation.

Evaluation

error analysis on production traces, failure taxonomies, LLM-as-judge validated against human grading, CI suites from production errors, Langfuse.

Infra

Render, Vercel, Modal, Cloudflare Workers, Postgres on Neon with pgvector, Upstash Redis, Docker, GitHub Actions.

Good fit Less of a fit
Ownership

Deciding what to build: talking to users, choosing the problems worth solving, and answering for the results.

Work that arrives as pre-scoped tickets, with the problems decided elsewhere.

Scope

Shaping how frontend, backend, and AI fit together, alongside the teams that build each part.

Roles boxed into a single layer, like frontend-only or backend-only.

Product

Products where AI is the core, or a feature users have come to depend on.

Products with no user-facing AI, or where AI only helps write the code.

AI work

Applied AI: products built on foundation models, with quality measured on every change.

ML research or model training.

obligations-agent: EU AI Act and GDPR obligations for one AI product

in progress

A tool that takes the facts of one AI product from a short form and a few follow-up questions, and returns a memo with one row per obligation under the EU AI Act and the GDPR: the clause it comes from, what it means for that product, and one action. It is for engineers who know their system in detail and have no lawyer to ask. Role: Sole builder.

Ask with a form and fixed choices first, then let a model choose the follow-up questions inside limits set in code

Because the user knows their system and does not know the law, so the questions have to come from a fact schema written from the regulation text.

Measured bythe share of started intakes that reach a memo, and the share of 'not sure' answers per question

Decide which regulations, roles and risk tiers apply with rules in code, not a model

Because the same facts must always give the same result.

Measured bya benchmark of test products with known correct answers

Quote and link the clause in the official text on every row of the memo

Because a person who is not a lawyer has to be able to check each row.

Measured bythe share of rows that users mark as disputed, and hand labels of the written meaning and action

SveaSync: multi-tenant AI assistant platform

In production since July 2026

Small hospitality businesses answer the same guest questions all day. Staffing for it costs more than it returns, and a bot that answers wrongly in the business's name loses customers. Role: Sole architect and engineer.

Route risky conversations to a human with a traffic-light escalation protocol

Because an assistant answering in the company's name cannot afford a confident wrong answer.

Measured byrouting correctness: the share of conversations that end in the right place, with the assistant or with a person

Convert every production error into a permanent CI test case

Because prompt and model changes silently reintroduce old failures otherwise.

Measured byrecurrence of known failures: a failure that has a test must not appear again in a later release

Isolate tenants with schema-per-tenant Postgres

Because one business's data must never surface in another business's answers, and each business's data has to be exportable as a unit.

Measured bya business's complete dataset exports as one schema

Read the full case study

Integrated vs chat: a measured comparison

80.8% vs 64.2% action accuracy, integrated vs chat, on a 73-item eval

Teams default to a chat UI for AI features. Whether an integrated, structured interface actually performs better on the same workflow was an assumption I wanted numbers for. Role: Sole builder.

Hold the model constant and vary only the interface

Because otherwise interface effects are confounded with model quality.

Measured byaction accuracy on a 73-item hand-labeled eval set

Ground every claim with two independent judges (Claude Opus 4.7 and GPT-5)

Because a single judge bakes one model's bias into the results.

Measured bysubstring grounding rates per judge, 99.3% integrated vs 93.4% chat

Keep the eval run that failed, together with the fix and the run after it

Because a scorecard is only useful if it can catch a problem.

Measured byone recorded case: industry classification went from 32.9% to 94.5% after the fix

Read the full case study

RAG support assistant with designed failure paths

71% hit rate at 5, 4.80/5 faithfulness, across 7 evaluation experiments

Support bots fail worst when they answer confidently from weak retrieval. I built a pipeline where every low-confidence path has a designed response instead of a guess. Role: Sole builder.

Classify every query into five categories before retrieval

Because a cancellation request must never get a how-to answer, and nonsense should not waste retrieval compute.

Measured byeach category routing to its own purpose-built response path

Gate answers behind two reranker confidence thresholds

Because generating from weak context erodes trust faster than asking a clarifying question.

Measured byfaithfulness and relevancy scores across 7 experiments (4.80/5 and 4.76/5)

Run a self-critique step after generation

Because the cheapest place to catch a partial answer is before the user sees it.

Measured bythe critique verdict deciding whether human escalation is offered

Read the full case study

AI Feature Maturity Ladder

Five dimensions, five levels, weakest dimension sets the score

AI feature adoption problems get treated as prompt problems. Usually something else is holding the feature back, and teams have no structured way to find it. Role: Author. The framework is a synthesis; the dimension cuts and level rubric are my choices..

Score five dimensions independently and let the weakest set the level

Because a feature is constrained by its weakest dimension, not its average.

Measured bythe min-rule stated explicitly in the published rubric

Give every level both a user-visible signal and a team signal

Because a feature can look adopted while being operationally fragile, and the reverse.

Measured byboth signal columns present for all five levels

Make output quality one dimension of five, not the whole score

Because accuracy can improve while adoption stays flat.

Measured byfour of the five dimensions cover something other than output quality

Read the full case study

Experience

SveaSync AI Engineer 2026 to present
  • Designed, built and operated a multi-tenant AI assistant platform for local businesses in hospitality and events, with responsibility for the whole product: architecture, quality, compliance and pricing.
  • Agent: a tool-calling LLM agent built in Python, with a TypeScript frontend, serving website chat and WhatsApp Business.
  • Knowledge base: self-service in Google Sheets, so businesses can update their own information without help.
  • Quality system: risk classification and deterministic guardrails before any model call, escalation to a person when the assistant is unsure, and every production error converted into a permanent CI test.
  • Compliance: EU AI Act transparency built into the assistant, and drafted the service and data processing agreements.

The decisions and the architecture are in the case study.

ChromaWay Senior Software Engineer / Tech Lead, Platform & Distributed Systems Stockholm, 2021 to 2026
  • Tech lead for teams of up to 10 developers on Chromia, a blockchain platform built on a relational database (Postgres), with review responsibility for architecture and implementation.
  • Built a RAG-based chat application on the platform's AI services (LLM inference and an on-chain vector database). It was deployed live as the company's official showcase of what developers can build with those services.
  • As the first real user of those AI services, fed bugs and improvements back to the core team.
  • Built the entire blockchain backend for the game Mines of Dalarnia with one colleague, and helped design its in-game economy. The contracts processed over 1M real-money transactions, and the game peaked as the second most used app on Binance Chain.
  • Owned Chromia's staking system, where 1,000+ users locked their own funds. Diagnosed and fixed a critical bug that caused exponential data growth, which resolved a network-wide performance problem.
  • Took several partner projects from first conversation to first version: talked directly with the partner companies, built the product from scratch and iterated on their feedback.
  • Shaped the user-test strategy for the developer documentation with the team lead and set up external user tests.
Senseworks Front-end Developer (part-time) 2020 to 2021
  • Built interactive tables and graphs of financial data for auditors and accountants, in React and TypeScript.
  • Integrated REST APIs and managed client-side state with Redux Toolkit.

Education

UmeƄ University MSc in Engineering programme, Interaction Technology and Design 2016 to 2021

Five-year programme spanning programming, algorithms, statistics, human-computer interaction, human-centred AI, and UX evaluation and research. Exchange semester at Northern Arizona University, fall 2019.

Certifications

AI Evals for Engineers & PMs Hamel Husain & Shreya Shankar, Maven 2026
AI Engineer Expert Datalumina 2026