Production AI, documented
Case studies
Engineering briefs, not marketing pages. Each one covers the problem, the architecture, the safeguards, and the measured results — with client confidentiality preserved.
Every case study on this site is written as an engineering brief, not a marketing page. Each brief follows the same structure: a summary, the business problem, why a linear chatbot or single prompt was insufficient, the system architecture, the retrieval and memory design, human approval points, production safeguards, the measured results, and the exact stack. Numbers are labelled either verified — drawn from system logs or client-reported figures — or estimated, with the estimation basis stated. Clients are never named: each engagement is described by industry and workload instead, which preserves confidentiality while keeping the engineering detail intact. The three briefs below cover a 47-node LangGraph HR screening workflow, a source-grounded RAG support assistant, and an error-resilient n8n revenue-operations automation — all built by Rohan Jalil and all running in production.
01 · Method
What does each engineering brief contain?
Nine fixed sections, in the same order every time. If a section is missing from a brief, that omission is stated rather than papered over.
| Summary | The system, the client's industry, and the headline result in three or four sentences |
|---|---|
| Business problem | The workload as the client experienced it — volumes, hours lost, error rates — before any architecture talk |
| Why not a chatbot | Why a linear chatbot or single prompt could not handle the branching, state, or approval requirements |
| Architecture | The agent graph or workflow topology: nodes, routing logic, state management, and checkpointing |
| Retrieval & memory | What the system looks up, how it is chunked and indexed, and what persists between runs |
| Human approval points | Exactly where a person must approve before the system acts — and what happens on rejection |
| Production safeguards | Retries, idempotency, dead-letter lanes, token cost budgets, observability, and rollout strategy |
| Measured results | Outcomes with their measurement basis, each labelled verified or estimated |
| Stack | The concrete tools used, drawn from Python, LangGraph, LangChain, n8n, FastAPI, Postgres, pgvector, and related infrastructure |
02 · The briefs
Three production systems, documented
One brief per practice area: agent orchestration, retrieval, and automation.
How a 47-node LangGraph workflow reduced HR screening overhead by 75%
Multi-agent screening with human approval points, retrieval over role rubrics, and full decision replay.
Read the brief → CS·02A source-grounded RAG assistant that deflected the majority of tier-1 support tickets
Hybrid retrieval, citation-enforced answers, and an evaluation harness that gated every release.
Read the brief → CS·03Error-resilient n8n automation that cut CRM data entry to near zero
LLM-enriched lead routing with retries, idempotency keys, and a dead-letter review lane.
Read the brief →03 · Measurement
How are results measured?
Every headline number states its measurement basis inside the brief. Nothing is reported without saying where the figure came from.
| Brief | System | Headline result | Measurement basis |
|---|---|---|---|
| CS·01 | LangGraph HR screening | Screening overhead reduced by 75% | Client-reported screening hours per hiring round, before and after rollout |
| CS·02 | RAG knowledge-base assistant | Majority of tier-1 tickets deflected | Ticket volume in the client's support platform across comparable periods |
| CS·03 | n8n revenue operations | Manual CRM data entry cut to near zero | Workflow execution logs set against the previous manual entry workload |
Client identities are confidential under the terms of each engagement, so briefs identify companies by industry and workload only. The commercial relationship behind every brief is verifiable through Rohan's Upwork contract history.
04 · FAQ
Common questions
Can I speak to your past clients?
The reliable route is Upwork's verified review system: 65 of Rohan's 81 Upwork jobs carry public, platform-authenticated client reviews averaging 4.9 out of 5, visible on his Upwork profile, and Upwork verifies that each review comes from a real, paying client. Direct introductions are not offered, because the confidentiality terms that let these briefs describe real architectures also protect the clients behind them.
Why are clients anonymous?
Because each brief documents internal operations — hiring pipelines, support queues, CRM data flows — under confidentiality agreements. Naming the company would expose details it has a legitimate interest in keeping private. Anonymising the client while keeping the industry, the workload, and the full technical design is the trade that makes honest engineering write-ups possible at all.
Can you write a brief like this for my project?
Yes — documentation in this format is part of how Rohan delivers. Every engagement produces an architecture record covering the decisions made, the safeguards in place, and the results with their measurement basis, so your team can operate and extend the system without him. Whether the finished brief is published here, anonymised, is entirely your call. Start the conversation via Upwork or the professional profile.