Selected projects

Asked simply to name the skills, an LLM produces plausible but ad hoc labels: the same skill is worded differently from one work item to the next, so the results cannot be compared. Mapping to a fixed taxonomy avoids that, but then the service has to find the right entries among around 13,900 ESCO skills, whose formal names rarely match the wording of a ticket.

• Discovery and requirements with the product team
• Architecture of an agentic extraction loop
• Prototyping of prompt and tool strategy
• Production-grade API service with automated tests
• Containerized delivery with CI, plus handover documentation

• A LangGraph agent works with four tools: search the taxonomy, browse its hierarchy, verify a skill, and submit. Every skill is checked against a local full-text index before it is returned, so the service never returns a skill it cannot verify.
• The prompt translates tech jargon into formal taxonomy terms, scores relevance, isolates untrusted input against prompt injection, and runs deterministically for reproducible results.
• Guardrails cap tool turns and total time and detect loops.
• An asynchronous job API supports submitting, polling, retrieving, and rating results. Webhook callbacks use token auth, retries with backoff, and SSRF protection.
• Hardening covers token authentication, rate limiting, security headers, non-root containers, and least-privilege database roles. LiteLLM keeps the service provider-agnostic across OpenAI, Gemini, and Anthropic models.

A secure, observable service that turns unstructured work descriptions into consistent, machine-readable skill profiles, with a taxonomy link, hierarchy path, and relevance score for every skill.

Duplicates rarely share their wording: one ticket might say “Dashboard for customer churn”, another, months later, “Report on which clients cancel their contracts”. String matching misses pairs like that. An LLM recognizes them, but asking it about every pair is far too slow and expensive: checking one work item means tens of thousands of comparisons, and checking a whole backlog means hundreds of millions.

• Method survey of the entity-resolution literature
• Architecture of a three-stage detection cascade
• Prototyping and threshold tuning
• Production-grade API service with automated tests
• Containerized delivery with CI, plus handover documentation

• Stage 1 narrows the search. Five quick lookups run in parallel and return at most 50 candidates: identical text, keyword search, similar spelling, neighbors in the project hierarchy, and items with similar meaning (embeddings). The meaning-based lookup also finds duplicates that share no words at all.
• Stage 2 scores each candidate. Title similarity, shared key terms, similarity in meaning and position in the project hierarchy are combined into one score. Clear matches are accepted and clear non-matches dropped, at no further cost.
• Stage 3 passes only the uncertain cases to an LLM, which reviews them all in a single call and can read an item's full text when it needs more detail. Its verdict is combined with the stage 2 score.
• Every partial score is stored, so thresholds can be adjusted later without running detection again.

A production service that finds duplicates even when they are worded differently, at a cost of at most one LLM call per work item checked.

The classic answer is a filter form with dozens of fields, such as maximum group size or distance from a city, each queried directly in the database. It is precise, but it is not how people describe what they want, and the platform did not want one. The usual LLM approach, retrieval-augmented generation (RAG), understands free text but treats facts as similarities: for a group of 21, an activity for up to 20 people looks like a close match, when in fact it is ruled out. Strict filters fail the other way: an event 101 km from the office is a close match for “no more than 100 km”, yet a filter drops it. The search has to tell hard limits from approximate ones without the user spelling out which is which. The design also had to work without a vector database or a rewrite, with the existing relational database as the source of truth and structured data as output.

• Stakeholder discovery and constraints analysis
• Three architectures designed and compared in detail
• API contracts, security analysis, and model selection
• Token budgets, success criteria, and candidate tech stacks
• A recommended starting point. No prototype or production code was part of this engagement.

• All three designs have the LLM turn the request into database filters for the hard facts, then rank the remaining offers by how well they match the wishes. Because the LLM reads the request in context, it can tell which limits rule an offer out and which are approximate.
• Open-text agent: a single free-text query, an LLM with a typed search tool that runs a direct SQL query, and a two-stage re-rank that skims titles and tags, then reads the full descriptions of the best candidates.
• Guided step-by-step flow: click or type at each step, the LLM turns answers into structured filters, a live count updates after every step, and re-ranking runs only on the final set.
• Stateless frontend-driven flow: the same user experience with the frontend holding the state and three pure backend endpoints. It removes the risk of state tampering and roughly halves token use.
• Each design came with request lifecycles, JSON response schemas, prompt-injection mitigations, rate limiting, and a model choice for every call.
• Recommendation: start with the guided flow, the closest to the existing experience and the lowest risk.

The team could pick an approach and build it on their existing stack, with no vector store and a clear security and cost profile for each option.