Nevil Nandasana — Systems Architect × Software Engineer
Nevil Nandasana — Systems Architect & Software Engineer: I TURNconfusionINTO SYSTEMS.
I'm Nevil Nandasana — a systems-oriented software engineer specializing in AI agent orchestration, distributed backend architecture, and developer infrastructure. I turn repetitive bottlenecks into deterministic, observable systems. Move your cursor through the field. Watch the noise resolve.
§01 OPERATING LOOP
I don't start with the solution.
I start by trying to understand why the problem exists. Real engineering isn't a linear pipeline — it's an iterative loop that eventually returns to refine the system. Eight stages. No shortcuts.
SOMETHING DOESN'T FIT
↺ THE LOOP RETURNS TO 01 WHEN REALITY DISAGREES WITH THE MODEL
§02 ARCHITECTURE ROOMS
Systems, dissected.
Not a tutorial — a visual map of how I reason about five architectural patterns. Open a room. Hover the nodes. Every block carries its job description and the reason it exists.
ROOM — Retrieval-Augmented Generation (RAG)
N1
User Query
Input
N2
Embedder
Vector Encoding
N3
pgvector
Vector Store
N4
Context Assembler
Prompt Builder
N5
LLM Generator
Inference
▸ WHY USE IT
When external context needs to influence generation without retraining weights.
▸ WHY NOT
Retrieval adds latency (~300ms), context fragmentation, and vector index maintenance overhead.
§03 SELECTED WORK
Case files.
Systems built because a manual process, a broken tool, or an unanswered technical question demanded a reusable system. Hover to preview the architecture — click to open the full dossier.
Grahvani
Vedic astrology SaaS with RAG & async jobs.ResumeForge
Multi-agent resume tailoring with RAG & eval harness.FocusLock
Windows focus-enforcement tool with FSM logic.OrthoScan-AI
Medical imaging classifier with Grad-CAM explainability.5 FILES INDEXEDHOVER TO PREVIEW · CLICK FOR DOSSIER
§04 THE LAB
Failure museum.
SCROLL → THE EXHIBIT MOVES SIDEWAYS
EXP-001
VALIDATED
RAG vs NO RAG
“What actually changes when vector retrieval is added to generation?”
Retrieval improves domain precision but introduces context fragmentation and latent latency.
OPEN FILE↗
EXP-002
VALIDATED
AGENT vs PIPELINE
“Where does dynamic orchestration become necessary over static DAGs?”
Dynamic agent routing is superior for unpredictable tool sets but inefficient for fixed multi-step tasks.
OPEN FILE↗
EXP-003
FAILED
MEMORY EXPERIMENT
“What should an agent remember across execution loops?”
Storing raw conversation history maintains context without window exhaustion.
OPEN FILE↗
EXP-004
VALIDATED
PROVIDER FAILOVER
“What happens when primary LLM provider experiences 429 rate limits?”
Automatic fallback to secondary provider maintains task flow without throwing client errors.
OPEN FILE↗
§05 OPEN QUESTIONS
Currently figuring out.
Question-driven technical areas under active investigation. No fake proficiency percentages — just honest uncertainty, tracked like a system.
Q-01 — AGENT SYSTEMSBUILDING
How do agents actually coordinate?
Routing, state persistence, tool protocols, execution recovery.
- routing
- state
- tools
- recovery
- planning
Q-02 — ORCHESTRATIONUSED
When does a pipeline become an orchestrator?
DAGs, dependencies, retries, replanning, failure handling.
- DAGs
- retries
- budgets
Q-03 — MEMORYEXPLORING
What should a system remember?
Retrieval boundaries, context persistence, state isolation.
- retrieval
- persistence
- boundaries
Q-04 — AI INFRASTRUCTUREDEEPENING
How do you make AI systems reliable?
Observability, fallbacks, provider routing, guardrails.
- observability
- fallbacks
- evals
- routing
TERRITORY MAPSTACK BY ROLE
Weapons of choice, grouped by system role.
LOCAL TIME● SYNCED
--:--:--IST — UTC+5:30 · RAJKOT, IN
“Every system I don't understand is just a system nobody has explained to me yet.”
— OPERATING ASSUMPTION, ADOPTED CIRCA FOREVER
§06 OPERATING RULES
The whole operating system, five lines.
These govern how I design, build, and debug. Everything else is implementation detail.
R-01
Understand the machinery
Don't hide behind the abstraction until I understand what's underneath it.
R-02
Question the architecture
Just because something is popular doesn't mean this system needs it.
R-03
Automate repetition
If I keep doing something repeatedly, I start asking whether the system should do it.
R-04
Design for failure
A system isn't finished when the happy path works.
R-05
Complexity is a cost
If the simple solution works, use it. Don't build complexity for its own sake.
§07 SELF-DIAGNOSTIC
Known limitations.
Every honest system ships with a known-issues list. Here is mine, instrumented.
SYSTEM STATUS DIAGNOSTIC — RUNTIME: HUMAN v26● ALL SUBSYSTEMS ANSWERABLE
curiosityHIGH
automation instinctHIGH
systems thinkingACTIVE
ambitionHIGH
over-engineeringDETECTED
foundationsIN PROGRESS
The problem isn't that I think too small. Sometimes it's the opposite. I can design the architecture of a system before I've fully mastered the foundations required to build it.
I'm learning to recognize when to build the system — and when to first build the foundation. The gauge above moves in the right direction every quarter.
§08 TRAJECTORY
Evolution, instrumented.
Nevil Nandasana is a systems architect & software engineer based in Rajkot, Gujarat (India). Building multi-agent orchestration frameworks, distributed backend services, and observable developer infrastructure. Below: how the engineering philosophy evolved across each phase.
0
Projects Indexed
0
Experiments Run
0
Decisions Logged
0
Failures Documented
01 — THE BUILDER
Manual → Automated
Started building things because doing them manually was annoying. The annoyance was the roadmap.
02 — THE SYSTEM THINKER
Underneath the abstraction
Started asking what was actually happening under the surface. Broke things on purpose to find out.
03 — THE ORCHESTRATOR
Coordinating systems
Started building systems that coordinate other systems — agents, queues, DAGs, failover chains.
04 — NOW
Restrained complexity
How far can I push this without over-engineering it? The loop returns. The question sharpens.
§08.1 CREDENTIALS
§09 TRANSMISSION
Have a problem worth turning into a system?
Open to remote engineering roles and systems collaboration. If it involves orchestration, automation, or infrastructure that should exist but doesn't — I want to hear about it.
START TRANSMISSION ↗