I build AI applications that connect LLMs, retrieval, tools, and software people can use. I bring 4 years of professional engineering experience across Python AI workflows and full-stack product engineering with React, Next.js, Node.js, and Express.
- Target role: AI Engineer / Generative AI Engineer
- Currently building: Self-Driving Data Analyst
- Focus: RAG, agent orchestration, safe tool use, evaluation, AI APIs, and backend systems
- Based in: New Delhi, India
Architecture for a real assistant
┌─ durgesh-ai / assistant-preview ──────────────────────────┐
│ visitor › What does Durgesh build? │
│ agent › Reliable LLM applications, RAG, and workflows │
│ with validation, evidence, and observability. │
│ │
│ visitor › What happens before a tool runs? │
│ agent › Authenticate → authorize → plan → validate → │
│ execute → evaluate → trace. │
│ │
│ mode: README preview · live chat: deployment required │
└───────────────────────────────────────────────────────────┘
The design below is intentionally larger than a simple prompt-to-response chain. It separates the control plane, data plane, policy decisions, and quality feedback loop.
flowchart TB
U["User / client"] --> G["API gateway
Auth · rate limit · request ID"]
G --> O["AI orchestrator
LangGraph state machine"]
O --> C["Context plane
Schema · metrics · documents"]
O --> T["Tool plane
SQL · retrieval · approved APIs"]
O --> P["Policy plane
Guardrails · permissions · budgets"]
T --> D["Data systems
MySQL · vector store · services"]
O --> R["Response composer
Evidence · assumptions · status"]
R --> G
O --> M["Observability
Traces · metrics · audit events"]
M --> E["Evaluation loop
Regression · quality · safety"]
E --> O
Request path: client → gateway → orchestrator → context and tools → policy checks → evidence-backed response.
Feedback path: traces → offline evaluation → regression cases → safer prompts, policies, and graph edges.
flowchart TD
A["Receive request"] --> B["Validate schema
principal · tenant · budget"]
B --> C["Classify intent
answer · clarify · refuse"]
C -->|clarify| Z["Ask focused question"]
C -->|answer| D["Retrieve permitted context"]
D --> E["Plan typed actions
metric · filters · tool"]
E --> F["Check authorization
resource and field scope"]
F -->|denied| Z2["Safe refusal + trace"]
F -->|allowed| H["Check exact-result cache"]
H -->|hit| I["Validate cache scope + freshness"]
H -->|miss| J["Generate tool call"]
J --> K["Deterministic guardrail
AST · schema · row/time caps"]
K -->|fail| L["Bounded repair
max two attempts"]
L --> J
K -->|pass| N["Execute read-only tool"]
N -->|transient| Q["Retry with deadline"]
Q --> N
N -->|rows| I2["Normalize evidence"]
I --> I2
I2 --> S["Synthesize answer
claims linked to evidence"]
S --> V["Output validator
format · leakage · citations"]
V --> W["Response + trace ID"]
B --> X["Metrics, logs, traces, cost"]
C --> X
K --> X
N --> X
V --> X
| Layer | Responsibility | Production control |
|---|---|---|
| Gateway | Identity, quotas, request IDs, payload limits | Auth middleware, rate limits, abuse protection |
| Orchestrator | State transitions and tool sequencing | Typed state, deadlines, idempotency, bounded retries |
| Context plane | Retrieve only relevant approved context | Versioned metadata, tenant filters, token budget |
| Policy plane | Decide what may be generated or executed | AST checks, allowlists, least privilege, output validation |
| Tool plane | Execute constrained actions | Read-only credentials, timeouts, row limits, sandboxing |
| Quality plane | Measure behavior over time | Golden set, adversarial tests, drift checks, release gates |
Guardrails and security
- Authenticate before retrieval; derive tenant and permissions from trusted claims.
- Treat user text, retrieved documents, schema comments, and sample values as untrusted.
- Allow only typed tools and approved resources; never expose unrestricted shell or network access.
- Parse generated SQL into an AST; reject DDL, DML, multi-statement payloads, system tables, and disallowed columns.
- Use parameter binding, read-only database principals, row limits, timeouts, and result-size caps.
- Validate the final answer for authorization, unsupported claims, sensitive data, and missing evidence.
Cache and performance
- Cache successful bounded results only; never cache denials or internal errors.
- Key results by tenant, permission scope, datasource, normalized query, typed parameters, schema version, metric version, and policy version.
- Re-check authorization before every cache read; a cache hit never bypasses policy.
- Use freshness-aware TTLs and invalidate on schema or metric changes.
- Track cold-cache and warm-cache latency separately; protect the database with admission control and connection-pool limits.
Evaluation and release gates
- Dataset: synthetic fixtures, hand-reviewed cases, ambiguity, adversarial prompts, empty results, and large results.
- Quality: parse validity, execution accuracy, result-set correctness, metric/filter correctness, faithfulness, and evidence completeness.
- Safety: policy precision/recall, unsafe execution rate, authorization leakage, prompt-injection resistance, and cache-scope isolation.
- Operations: p50/p95 latency, time to first token, tokens/request, cost/request, retries, timeouts, and provider/database saturation.
- Release gate: publish the dataset, model, prompt, schema, dependency, commit SHA, and cold/warm cache conditions with every result.
Observability and failure handling
- Trace every graph node with request ID, duration, model, token usage, cache status, policy result, and tool fingerprint.
- Redact prompts, row values, secrets, and personally identifying data from default logs.
- Retry only transient failures and never reset the request deadline.
- Use circuit breakers for provider/database outages, structured error classes, and explicit partial-result states.
- Turn reviewed failures into regression cases before changing prompts or graph edges.
|
Natural-language analytics with an explicit target architecture for schema retrieval, SQL policy checks, read-only execution, evidence-grounded answers, scoped caching, and evaluation. Current: Python · LangGraph · Gemini |
Agent workflow combining fleet telemetry, corridor weather, and logistics SOP documents to produce an operational summary and action plan. Stack: Python · LangGraph · LangChain · SQL Server · Pinecone · Streamlit |
01 · AI engineering and LLM systems
LLM applications · agent orchestration · RAG pipelines · embeddings · hybrid retrieval · prompt design · tool calling · structured outputs · SQL agents · evaluation harnesses · guardrails · caching · tracing
02 · JavaScript and frontend systems
JavaScript · TypeScript · React · Next.js · responsive interfaces · SCSS modules · GSAP motion · accessibility · SEO-friendly rendering · API integration · component systems
03 · Backend, data, and delivery
REST APIs · FastAPI · Node.js · Express · SQL Server · MySQL · MongoDB · Pinecone · Docker · Git · GitHub · authentication · rate limiting · logging · CI/CD fundamentals
Building AI features that are inspectable, testable, and useful beyond a demo.