8.9 → 5.0 s
Median time to first token with prompt caching
Median time to first token per turn before and after transcript caching on a ~80k-token loop (4 tool rounds) Per-turn range: 4.6–22.0 s before 3.4–5.1 s after
Vinayak
AI Engineer
I’m an AI Engineer at AMnova Technologies architecting full-stack multi-agent systems with FastAPI LangGraph and Next.js
My focus is practical reliability building agents with sandboxed code execution source-grounded citations and deterministic guardrails that prevent hallucinations
Featured projects
All systems & archive (14)8.9 → 5.0 sMedian time to first token with prompt caching
9Job sources merged and deduplicated
Predicts which customers will leave then explains why in plain words and voice
10kCustomer records trained on
3Clinical screening models
8Autonomous pipeline agents
One AI workspace to chat code in a live sandbox study and delegate

8.9 → 5.0 s
Median time to first token with prompt caching
Median time to first token per turn before and after transcript caching on a ~80k-token loop (4 tool rounds) Per-turn range: 4.6–22.0 s before 3.4–5.1 s after
8
Models routed with automatic provider fallback
Models in the routing table across Groq OpenRouter and OpenCode as listed in the README A failed call retries on at most two alternates
10
Specialist agents with human approval
Specialist agents on one parameterised graph each pausing for human approval as listed in the README
Chat windows can't execute code or check answers against private documents Coding research and study each need their own tools and a real environment to run in
LangGraph agent in an E2B sandbox; turns routed across 8 models retried on up to 2 alternate providers
SOURCED CLAIMS · CLICK ONE TO HEAR IT
Chatbots talk about code Loom runs it inside a real Linux sandbox
Every turn is routed across 8 models If a provider fails the turn falls back to the next one
Caching the transcript cut the median time to first token measured turn by turn
And the limits are written down too
route_turn() · try it: take a provider down
Each provider toggles up/down Primary first then up to two alternates
Provider names from the project; the replay is illustrative
time_to_first_token() · median ~80k-token test loop
Measured values from the performance method doc; playback is 10× faster than real time
Turn Classifier & Router
Routes across 8 models (Groq OpenRouter OpenCode) with 2-hop provider fallback
LangGraph Checkpointer
Persists graph state after every node visit; caches ~80k-token transcript
E2B Sandbox & pgvector
Concurrent read-only tool batches; sequential writes; lexical hashed RAG
User Prompt / Task · Repo Filesystem · PDF · Web · YouTube Sources
Typed WebSocket Trace · Live Dev Server Preview · Cited [n] Notebook Answers
The Code agent gets a real Linux box (shell filesystem web search dev servers) and streams every tool call over a typed FastAPI WebSocket contract into a live trace and preview Read-only tool batches run concurrently; writes run in order
Learn turns PDFs web pages and YouTube transcripts into answers with [n] citations and graded courses and abstains when the sources don't cover the question Retrieval uses lexical hashed vectors in pgvector
Each iteration is classified and routed across eight models On a rate limit quota or 5xx it retries on up to two alternate providers and LangGraph checkpoints let sessions survive cold starts
STACK (8 TOOLS)
DOCUMENTED LIMITS (3 OF 26)
Nine Kerala job boards one ranked list no duplicates
Here’s a simulated run of the CV guard Pick the edit you think it rejects
tailor_cv() · pick an AI-suggested edit
source CV (fictional)Built a FastAPI service that parses supplier invoices into PostgreSQL
One of these edits invents something The guard will catch it
Toy guard: it checks numbers only LazyHire's real checks cover numbers and requirements

LazyHire pulls 9 job sources around Kerala's tech parks into one ranked list minus the duplicates
Every match score opens up: freshness source location role fit and skills
It tailors your CV and rejects any edit it can't trace back to the original
The code is public: read it on GitHub
Predicts which customers will leave then explains why in plain words and voice
A toy dial not the trained model: drag it to see how the risk tier changes
score_churn() · illustrative toy not the trained model
Low risk
p(churn) ≈ 12%
Low risk Activity is recent so the usual check-ins are enough

ARIA predicts which bank customers might leave: XGBoost on 10,000 records balanced with SMOTE
It sorts them into Low Medium and High risk and surfaces the top five drivers
Then Llama 3.3 explains why in plain words and ElevenLabs reads it aloud
Screening results that explain themselves
Preprint · Zenodo
DOI 10.5281/zenodo.20253956
Zenodo record v1.0 17 May 2026 A preprint not peer-reviewed

PredictLab screens for diabetes stroke and heart-disease risk from 30 health inputs
Three models an SVM a Random Forest and a Logistic Regression behind one FastAPI service
Llama 3.1 explains every result in plain language Vinayak published it as a preprint
Skills & technologies
Each tool links to the project or role that used it.
Python for the AI and ML work, TypeScript for the Next.js front ends, and SQL for the data underneath.
Agents that call real tools, routed across models with fallback, retrieval that cites its sources, and guardrails that reject made-up output.
See it in use in Loomscikit-learn and XGBoost for tabular models, feature engineering on skewed data, MLflow to track experiments, and pgvector for retrieval.
See it in use in AmdoxFastAPI services over REST and WebSockets, Next.js on the front, and agents that run code inside E2B Linux sandboxes.
See it in use in LoomPostgreSQL and Supabase for data, SQLite where it runs locally, and Docker and CI/CD to ship to AWS.
See it in use in AMnovaProfessional experience
AI/ML engineer on the product team. I work on the LLM pipeline that checks new merchant stores and the backend behind the merchant dashboard.
Built the LLM pipeline that checks new merchant stores at AMnova: It speeds up the store audits that were done by hand during merchant onboarding.
Wrote the FastAPI + Supabase backend behind the merchant dashboard: Its queries run async.
Packaged the inference services in Docker: GitHub Actions deploys them to EC2 on every push.
Built retail demand-forecasting and customer-churn models and served them as FastAPI endpoints.
Built demand-forecasting and churn models: XGBoost and scikit-learn on transaction histories.
Served the models behind FastAPI endpoints: Other apps call them over REST.
Tracked experiments in MLflow and built Streamlit dashboards: So the business team could see the results.
Built credit-approval classifiers on a heavily imbalanced financial dataset.
Trained and tuned credit-approval classifiers: Checked on F1, precision, recall and ROC-AUC, not accuracy alone, because the classes are skewed.
Feature engineering, outlier cleaning and class-imbalance handling: On skewed applicant data.
Certifications & achievements
Zenodo, DOI 10.5281/zenodo.20253956.
Participant, HackerRank Orchestrate Hackathon
Built and submitted a terminal-based autonomous support-triage agent.
Top 2%, LeetCode Weekly Contest 487
Rank 108 of 6,770.
Bachelor of Computer Applications (BCA)
Mahatma Gandhi University, Kerala
Advanced Data Science & AI Specialization
Avodha Centre for IT Education
7-month intensive program, accredited by NSDC and Skill India.
Try asking
Tap me to talk

NEO // run for vinayak k v
—
Each line links back to its step.
Tearing copies a plain-text summary, with Vinayak's email, to your clipboard.