Work

Case studies first, then smaller builds, what I plan to try next, and writing. Every item carries its real status.

Status key

Implemented: Built and working as described.
Prototype: Working code that proves the hard parts. Not production, not deployed for a client.
In progress: Actively being built. Parts work; parts are still planned.
Design exercise: How I would approach a realistic scenario. No system built and no data analysed.

Case studies

CS-01PrototypeBanking · Internal knowledge · RAG

Problem: Staff spend too long finding policy answers, ask the same questions repeatedly, and interpret policy inconsistently, in an environment where every answer must be auditable and restricted documents must stay restricted.
My approach: Treat it as a trusted decision-support system, not a search box. That means permission-aware hybrid retrieval, answers grounded in approved documents with checkable citations, abstention when evidence is weak, and an evaluation loop built from reviewed feedback.
Status: A working local prototype on synthetic documents, plus a proposed six-week pilot. It has not been deployed at a bank, and no productivity results are claimed.

CS-02Design exerciseSaaS · Customer support · AI in workflows

Problem: Rising response times, with leadership pressure to automate. But some tickets touch customer data, billing and account changes, where a wrong answer or an unapproved action is expensive.
My approach: Segment tickets by volume, complexity and risk. Separate read-only answers from actions that change account or billing state. Route by intent, risk and confidence. Keep approvals and an audit trail on anything that changes an account. Validate it all with a shadow-mode pilot.
Status: A design exercise showing how I would run discovery and a pilot. No ticket data has been analysed, no system has been built, and no automation rate is assumed.

CS-03In progressSaaS product · LLM classification · Integrations

Problem: Keyword monitoring floods teams with noise, especially for brands whose names are ordinary words, while the posts that matter (complaints, bug reports, buying intent) get lost. Acting on them means replying in public, where mistakes are expensive.
My approach: Filter cheapest-first before any model call. Classify with explicit context and a three-way confidence band. Send uncertain matches to human review. Keep approving a reply separate from publishing it. Expose the same capabilities through the dashboard, REST and MCP, with scopes, rate limits, idempotency and an audit trail.
Status: A product in active development. Its marketing site is live at heysnitch.com. No usage, customer or revenue figures are claimed here.

Smaller projects that show the same instincts, not every repository I have.

Memora Prototype2026
A memory service for AI applications. Apps write facts, preferences and tasks, then ask for prompt-ready context before a model call. Results are ranked on semantic similarity, importance, freshness and past access. Memories can expire, and there are endpoints to inspect and delete them.
Shows Treating an AI capability as a backend service with a narrow, authenticated API, including a way to find and remove bad memories.
PythonFastAPIPostgreSQL + pgvectorOpenAI embeddingsAlembicDocker Compose
Kubernetes MCP server Prototype2025
An early Model Context Protocol server that lets an AI client analyse Kubernetes config files and folders and manage pods (list, get, logs, delete). More resource types are on the roadmap.
Shows Exposing operational tools to an AI client, with the data-exposure risk documented up front: the README warns against connecting clusters that hold secrets.
PythonMCPKubernetes

Planned, not started. Drawn from the known limits I documented in the RAG prototype.

N01
Enforce permissions inside the retrieval query
The prototype filters after candidate retrieval, so lower-ranked documents a user may read can be missed.
N02
Cross-encoder reranking vs. the current heuristic
Adopt it only if pass rates on reviewed cases improve by enough to justify the extra latency.
N03
Answer-quality checks beyond substring matching
Today’s checks confirm outcomes, sources and forbidden text, but not whether an answer is semantically correct.
N04
Tracing, dashboards and cost accounting
To see where latency and spend go per query before scaling anything.
N05
Automated SharePoint sync and re-indexing
Changed documents currently fail closed until someone re-ingests them by hand.

AI System Design: Build a RAG Assistant for a Bank (FDE Interview Prep)
Medium · 17 Jul 2026
How to turn an ambiguous request into a permission-aware, auditable system design: the questions to ask, the architecture, the risks and a six-week MVP.

Next step