Software and AI engineer. I own the AI that answers SIESA's ERP support chat, about 1,000 conversations a day.
I've built software for seven years. Full-stack .NET first, and since 2025 the AI behind customer support at SIESA, one of the largest ERP vendors in Colombia.
I like owning a system from the first look at the data to the day it runs without me. At SIESA that meant reading 90 days of chats, taking a business case to leadership, building the engine, shipping it and running it since. The language is whatever the system needs. Mostly Python, C# and TypeScript, with SQL everywhere.
I also teach. I trained 16 people and worked with 3 teams as they started using AI in their own work.
SIESA's support chat ran on a third-party chatbot nobody could audit. I replaced it with an engine the company owns and can measure. It now answers about 1,000 conversations a day.
I pulled 90 days of production conversations, 55,350 chats and about 964K messages, and read what customers actually went through. There was no way to tell whether an answer was right. The model, the retrieval and the citations belonged to the vendor, so a no-invention policy couldn't be enforced from outside. And the worst moment came after the bot, when a customer asked for a person and the handoff stalled.
I took that to leadership as a business case with six decisions ranked by impact and cost. The main one was to build our own engine and fix the handoff in the same move.
Python and FastAPI straight on the model API, so every millisecond and every token can be traced.
SIESA already ran on AWS, so billing and permissions stayed in the account it had. Sonnet answers, Haiku rewrites follow-ups and reads scanned pages.
pgvector search filtered by ERP module, then Cohere Rerank keeps the five passages the model reads.
Every citation has to exist in what was retrieved. A number that isn't in the sources sends the chat to a person.
About 170 deterministic rules handle greetings, risk and requests for a person before any LLM call.
The support portal didn't change, so switching over and rolling back were both routine operations.
Human escalation per chat in Payroll, the busiest module. Statistically significant, p = 0.0005.
Replies that tell the customer to contact support.
Answer correctness between evaluation cuts, scored by a human-validated LLM judge.
Cost per turn after adding prompt caching.
Customer-service CSAT after redesigning the handoff to agents.
Hybrid retrieval looked like the obvious upgrade. I built it, measured it twice on real customer queries and switched it off. It recovered 0 of 5 failing cases, and every retrieval variant I tried landed within 3.6 points of the others.
So the effort went to the documents. I reprocessed 1,027 of them with multimodal OCR and set up a curation loop where agents approve about 150 new answers a week, from a console 44 agent accounts use.
Every change now ships the same way. A golden set per module scored by an LLM judge, an A/B replay on real traces and a significance test before and after. I rebuilt that method in the open as rag-eval-bench.
The platform belongs to SIESA. Figures come from project reports to leadership, July to October 2026. I can walk through the architecture in an interview.
A bench that decides whether a RAG change ships. Golden set with questions the docs can't answer, an LLM judge, a validator that catches invented citations and numbers, and a paired McNemar test behind a CI gate. It runs on the public Odoo 18 docs.
What it found. Hybrid retrieval beat dense by 12.5 points, p = 0.02. A reranker added 1.4 points and pushed p95 latency from 2.5 s to 8.3 s, so it doesn't ship.
My own product. A WhatsApp reception for appointment-based businesses. It answers at any hour from templates the owner approves, books free slots, sends reminders and hands sensitive conversations to a person.
How often the old bot's attribution matched a ticket-by-ticket audit. That gap is why Jarvis exists.
A daily LLM judge that reads every support conversation and decides who resolved it, the AI, an agent or no one, with the same rule for both. At closing it also types the ticket, replacing the old bot.
In shadow since October 21 at about US$0.002 per chat. I rewrote its closing engine in LangGraph with parallel judges, PostgreSQL checkpoints and pauses for human review.
Internal to SIESATwo pieces that build on the RAG. One is under construction, the other is designed and planned for later.
Today a customer picks an ERP module before the chat starts, and that choice is where the bouncing between channels begins. The triage becomes the single entrance. It reads the problem and the customer's open tickets, then sends the case to the RAG or to an L1, L2 or L3 agent with a summary, so nobody starts over.
Before promising anything I estimated the ceiling from data, about 6 points off escalation.
Today the RAG explains the fix and the customer applies it. The second version runs the fix on the customer's installation, a service restart or an update, and every action has its own permission level.
The design is done. Building it comes later.
Replaced a manual export with Excel and nine SQL scripts, run two or three times a day, with a pipeline from the Freshdesk API to Power BI. Checked against the manual load, 9,607 rows against 9,606.
A reference monorepo. ASP.NET Core in layers, JWT with roles, PostgreSQL, React with Vite, tests, Docker Compose and CI.
The Jira-style platform more than 500 employees use. I lead its development and merged three internal apps into it.
Where I can own a system end to end, in AI, backend or data. I'm in Cali, Colombia, GMT-5, with full overlap with US Eastern and Central time.
jessidc95@gmail.com