Explore how I use AI, automation, and practical engineering to solve complex problems.
The problem. A projected shortage means checking demand, stock, incoming deliveries and supplier policies across four places before anyone can decide what to do.
What I built. A copilot that runs that investigation in one pass, proposes ways to close the gap, and checks each one against the stock that exists and the rules that apply.
One day's demand at one site
10,600 available
1,800 short
Demand 12,400 units
Available including deliveries that arrive in time 10,600
Four options, after the rules checked them
Transfer from Hamburg
900
Transfer from Munich
200
Approved substitution
600
Supplier expedite
100
Potential coverage if approved
1,800 of 1,800 units
AI proposes the options, fixed business rules check each one against stock and policy, and a planner approves or rejects them. Figures are from a synthetic test scenario.
A decision worth explaining
AI proposes. Rules validate. People decide.
During early testing, the AI proposed substituting 1,800 units when only 600 were available. I added deterministic validation rules in Python to check inventory limits and substitution policies before recommendations reach a planner. The planner can then approve or reject the proposed solutions.
Python
LangGraph
Claude
RAG
PostgreSQL/pgvector
The problem. The warehouse with stock is not always the cheapest to ship from, and the cheapest one does not always arrive by the date the customer was promised.
What I built. A routing engine that checks inventory, shipping costs, and delivery dates. It prioritizes delivery promises, considers the impact on limited stock, and records why each warehouse was selected.
The same batch, routed two ways
File-order routing
Orders handled in the sequence they arrived
5 of 9 delivery promises kept
$47.70 shipping cost
Urgency-first routing
Orders with the least room to spare handled first
6 of 9 delivery promises kept
$47.70 shipping cost
Changing the order the batch was worked through protected one more delivery promise, at exactly the same shipping cost.
The same synthetic batch of 10 orders, run twice. One order is rejected as invalid before pricing, so 9 are evaluated.
A decision worth explaining
Batch order is a product decision, not an implementation detail
Routing orders as they arrived cost a delivery promise for no saving at all. It only showed up by running the same batch both ways and comparing, which is now how any routing rule gets evaluated.
Python
Fulfillment Routing
Inventory Optimization
The problem. Support agents spend time understanding incoming tickets, determining urgency, checking company policies, and preparing responses before they can help a customer.
What I built. An AI-assisted workflow using n8n and Claude that classifies tickets, selects relevant approved knowledge, recommends next steps, applies deterministic policy checks, and prepares a draft response for an agent to review.
One ticket, eight stages
code
AI
1
IN
Ticket comes in
Subject, message, history
2
CODE
Normalize ticket
One consistent shape
3
CODE
Select approved knowledge
Keyword match, plus a safety policy
4
AI
Draft the brief
Claude Sonnet, fixed JSON fields
5
CODE
Enforce policy rules
Can overrule the model
6
AI
Second opinion
Claude Haiku, may fail safely
7
CODE
Build the agent view
Summary, actions, draft reply
8
OUT
Show agent brief
Draft ready for human review
How deterministic rules keep recommendations safe
When a duplicate charge is recognized, the ticket is set to Billing and at least High, with a "do not promise a refund" note attached
When the ticket shows the customer has contacted support before, an escalation recommendation is added
Payroll is raised to Critical only when the export is blocked and a deadline is close, not whenever payroll is mentioned
Any knowledge source the model cites that it was never given is removed from the brief
The first three checks run on ticket wording the rules recognize, so they lower the chance of an unsafe recommendation rather than removing it; a ticket phrased outside those patterns may not match. The citation check does not depend on wording — it compares every source cited against the ones actually supplied.
Seventeen live scenarios were run against the real Claude API, covering billing, payroll, escalation, policy safeguards and replies in four languages. A further 192 offline assertions across 19 tickets check the rules without calling a model. Every ticket and policy used in testing is fictional.
A decision worth explaining
Models draft. Rules check. Agents review.
I used deterministic JavaScript rules to enforce important support policies instead of relying entirely on AI instructions. For example, mentioning payroll doesn’t automatically make a ticket Critical. The workflow checks whether payroll is blocked and a deadline is approaching before applying that priority.
n8n
Claude Sonnet
Claude Haiku
JavaScript
Policy Validation