AKSHIT(1)General Commands ManualAKSHIT(1)

$ whoami

akshit ahuja

AI engineer · I ship agents to production and keep them working

Evals, human-in-the-loop gates, queues, retries, payments, voice. The unglamorous part that decides whether an agent survives real users. Technical co-founder, 4 years of Python at scale, and I talk to the customer myself.

projects blog resume.pdf mail

Akshit Ahuja — akshit.jpg · hover to decode

$ cat about.txt

DESCRIPTION

I've been writing Python for money for four years. Started as an intern at Spinny, left as an SDE-2, and in between I built a backend doing 34 million requests a day and a scheduler that ran 35,000 car auctions.

Now I co-run PeerSeek, where I built the whole backend: 18 Django apps, one payment engine, a lot of Celery. On the side I take on consulting work, mostly the "we have a manual process and it's eating us alive" kind. The last one cost a client $10,000 a month and took 20 people. Now it takes 3.

I like voice AI, Hindi speech stacks, things that run on queues, and systems that tell you when they're broken before your users do. I talk to customers myself. I think that's half the job.

$ ps aux | grep akshit

CURRENTLY RUNNING

PID	%CPU	COMMAND
101	40	peerseek	creator storefronts, payments, instagram auto-DM
102	27	folio	multi-agent blog writer: plan → research → draft → score → publish
103	13	heydev	"your in-house tech team". agency work
104	7	job-search	open to applied AI / forward deployed / agent engineering roles, remote

$ git log --oneline career

HISTORY · click a commit to git show

2025-05(HEAD -> peerseek)co-founder & founding engineer[+]

Built the entire backend: 18 Django apps covering bookings, webinars, DRM digital products, payments & payouts, coupons, analytics, search, realtime chat and Instagram auto-DM.
One payment engine for every product type. A new product gets pricing, coupons, commission and payouts without touching the money path.
Ran the early sales calls and user interviews myself, then built what people asked for.
Runs on Kubernetes (Azure AKS) as separate web, websocket, worker and scheduler deployments.

2025(consulting)independent AI & automation consultant[+]

LLM document extraction for a billion-dollar company: low-confidence reports go to human review. Replaced a $10k/month manual process, team went from 20 people to 3.
Voice agents: Hindi-first calling platform on Pipecat, and an outbound agent that detects voicemail and navigates IVRs.
Call intelligence for Happy Nature: rubric scoring, text-to-SQL + pgvector RAG, 4 STT providers benchmarked on real Hindi calls.
Ad-spend platform: Meta + Google spend into one Postgres dashboard with scheduled syncs.
Self-hosted LLMs on Azure GPU VMs behind a wake-on-request gateway. GPU bill is roughly zero when idle.

2022-08(spinny)intern → SDE → SDE-2[+]

Dealer finance: built the end-to-end integration with the central finance team for a lending system that disburses ₹30 crore+ (~$3.4M) in dealer loans every month.
Connected-cars backend handling 34M+ requests a day.
Auction scheduler on Celery + Kafka: 35k+ auctions automated.
Built the auction vertical’s ticketing on the company-wide central ticketing system: dealer queries resolved 30% faster.
Reliability at scale: moved queues off self-managed RabbitMQ to AWS SQS; idempotent webhooks with retries and backoff cut external API failures 90%.
Gevent on services fanning out to third-party vendors cut resource use 30%. Mongo indexing took an API from 500ms to 150ms.
Go-to engineer for cross-pod integrations and new business initiatives.

2022-02(zscaler)cloud operations intern[+]

Python and Bash to automate access control and watch cloud infra.

2018-08(init)B.Tech CSE, GNDEC Ludhiana (CGPA 8.02)[+]

Built Bunk Master, my first product used at scale: it told students exactly how many lectures they needed to stay above 75% attendance, and how many they could safely skip. Grew to 500+ monthly active students before COVID shut campus.
Ran the entire backend of the college fest website.
Convenor of the SCIE society (7th semester); organised a college-wide coding contest.
Spent the rest of it poking at Linux, browser automation, Python, devops and databases. First commit.

$ ls -la ~/projects

THINGS I BUILT

~/projects/peerseekco-founder · may 2025 → now · main project

peerseek

● running in production · peerseek.io

A link-in-bio storefront where creators sell 1:1 sessions, webinars, digital products and links from peerseek.io/<username>, and get paid out. I built the entire backend, from scratch, alone.

the backend

$ tree -L 1 peerseek/
├── auth  user  creator  central       # who you are, what you sell
├── calendar  package  webinar          # 1:1 sessions, cohorts, seats
├── digital_product  drm                # files, video, PDFs, with DRM
├── payment                             # the one money engine
├── chat                                # realtime, django channels
├── auto_dm                             # instagram comment → DM
├── analytics  redirection  url_shortner # first-party analytics + UTM
├── inquiry  testimonial  search        # leads, social proof, discovery
├── communication                       # email + whatsapp notifications
└── course                              # in flight

the idea that holds it together

Everything a creator sells is an offering. Each one gets two records: its own definition (Service, Webinar, DigitalProduct, UrlMap) and a row in one shared catalog, CreatorOffering. They're linked by a polymorphic pointer, (context_id, context_type), and that same pair shows up in every money table. So one payment engine serves products that have nothing else in common, and a new product type gets pricing, coupons, commission and payouts without touching the money path.

definition          catalog              fulfilment          money
Service        ─┐                          Booking        ─┐
Webinar        ─┼──► CreatorOffering ──►   WebinarBuyLog  ─┼──► PaymentTransaction
DigitalProduct ─┤                          DP History     ─┘    PaymentBreakdown
UrlMap         ─┘                                               CreatorLedger / Wallet

the money path

pick slot → price breakdown per component (base, recording add-on, platform commission, stacking coupons) → slot locked → Razorpay order → webhook captures payment → booking confirmed, Meet link generated, notifications sent → creator earnings go held → settled after a holding period → wallet → payout.

the rest

Instagram auto-DM. Someone comments a keyword on a reel and gets a DM. Meta Graph API with idempotent webhook handlers, keyword matching, follow-gating ("follow first, then I'll send it") and scheduled token refresh.
Notifications. One engine for email and WhatsApp that de-duplicates by message ID, so nobody gets "your booking is confirmed" twice when a webhook retries.
Infra. Django 5 + DRF, Channels/Daphne for websocket chat, Celery on Azure Storage Queues, PostgreSQL, Redis. Docker on Kubernetes (Azure AKS) as four deployments: web, websocket, worker, scheduler. Secrets in Key Vault, files in Blob Storage.
Not just code. I ran the early sales calls and user interviews, turned what creators asked for into the roadmap, and did onboarding myself.

stack: python django drf channels celery postgres redis razorpay meta-graph-api docker k8s azure-aks

~/projects/folio2026 → now

folio

● AI blog agent · tryfolio.site

A pipeline of AI agents that plans, researches, writes, scores and publishes blog posts, and won't publish anything a human hasn't approved.

PLAN→RESEARCH→OUTLINE→DRAFT→SCORE→REVISE→HUMAN_APPROVAL→PUBLISH

Each stage is a Celery task. A run moves on its own and stops at human approval. Reject it and it goes back to REVISE with the scorer's notes.
Learns the business first. Crawls the site, drafts a company summary, facts and brand voice, all marked pending_review until a human confirms.
Competitor watch. A candidate only counts if its site showed up in a real search result. Followed ones get checked weekly.
Fact provenance. Every claim in a draft has to trace back to evidence.
Browser bridge. An extension + native host lets agents research through a real browser.
Model routing. One strong model writes, cheaper ones do the grunt work. OpenAI Agents SDK on Azure Foundry.

stack: python django celery redis postgres pgvector openai-agents-sdk sanity

~/projects/report-automationconsulting · billion-dollar company · 2025

the $10k/month one

● LLM document extraction for a billion-dollar company

A billion-dollar company's vehicle service-history reports came off a vendor portal with no API, and people copied them out by hand. I automated it.

20 → 3

people on the process · ~$10,000/month saved

before20 people, manual copy-paste from a portalafter3 people, checking only the hard cases

Connector pulls service history from a vendor portal that has no API.
Extraction: parse the documents, an LLM pulls out the fields.
Human-in-the-loop: low-confidence reports go to a review queue instead of straight through.

stack: python llm document-parsing review-queue

~/projects/spinnyintern → SDE → SDE-2 · aug 2022 → apr 2025

spinny

● 2.5 years inside an Indian unicorn (used cars)

Joined as an intern and left as an SDE-2. I worked on the systems that move money, cars and dealers, and I was the engineer pulled in whenever two pods had to integrate or a new business line had to launch.

$ spinny --stats
dealer loans disbursed ..... ₹30 crore+/month (~$3.4M)
connected-cars backend ..... 34M+ requests/day
auctions automated ......... 35k+
external API failures ...... -90%
resource usage ............. -30%
API latency ................ 500ms → 150ms
uptime ..................... 98%+
dealer query resolution .... 30% faster

Dealer finance. Worked with the central finance team and built the entire integration for the dealer lending system, which disburses ₹30 crore+ (~$3.4M) in loans every month.
Connected cars platform. Backend for car telemetry handling 34M+ requests a day on MongoDB, Redis, AWS Lambda and Elastic Beanstalk.
Auction scheduler. An event-driven microservice on Celery + Kafka that schedules and runs vehicle auctions on its own. 35k+ automated.
Central ticketing. Built the auction vertical's ticketing on the company-wide ticketing system, after mapping the common dealer questions with business and product. Queries resolved 30% faster.
Reliability at scale. Led the move off self-managed RabbitMQ to AWS SQS, so the queue layer stopped being something we had to babysit. Idempotent payment-webhook APIs with retries and exponential backoff cut external API failures 90%.
Performance. Introduced gevent on the services that fan out to many third-party vendors, so workers stop sitting idle on network I/O: 30% less resource use. MongoDB indexing: 500ms → 150ms.
Monitoring. Alerting on New Relic, Sentry and gateway logs kept uptime at 98%+.
Cross-pod work. Pulled into almost every cross-pod integration and new business initiative: the person who reads both codebases and gets two teams' systems talking.

stack: python django celery kafka aws-sqs rabbitmq mongodb redis aws-lambda elastic-beanstalk gevent new-relic sentry

~/projects/voice-agentsconsulting · 2025 → now

voice agents

● hindi-first, on real phone lines

Voice agents that call real people in Hindi and Hinglish, on Pipecat, Twilio and Plivo. The hard part isn't the LLM. It's turn-taking, latency and everything a phone line throws at you.

latency budget (designed, user stops talking → first audio)

stage                 budget   how
audio capture          20ms    twilio 20ms chunks
noise cancellation     10ms    rnnoise frame
VAD                    10ms    silero
STT (interim)         100ms    streaming
smart turn             50ms    onnx end-of-turn model
LLM first token       200ms
sentence aggregation   50ms    wait for punctuation, then speak
TTS first audio       150ms
total                ~600ms    target: under 700ms

Calling platform, three planes. Django control plane, FastAPI + Pipecat voice plane, analysis API. Telephony, LLM, STT and TTS sit behind adapters, and import-linter enforces the boundaries in CI next to ruff, mypy strict and a pytest gate.
Outbound agent that survives the phone network. Voicemail-vs-human detection, and an IVR navigator that generates DTMF tones to get through phone trees.
Call intelligence for Happy Nature. Transcribe, score agents against a rubric, flag red flags, answer questions with text-to-SQL + pgvector. Benchmarked four STT providers on real Hindi/Hinglish calls before picking one.

stack: python pipecat fastapi twilio plivo deepgram sarvam elevenlabs silero-vad pgvector

$ man ship-agents

HOW I PUT AGENTS IN FRONT OF REAL USERS

gate: Nothing irreversible without a human gate. Folio stops at HUMAN_APPROVAL; the extraction pipeline sends low-confidence reports to a review queue.
score: Score outputs against a rubric, and route on the score. Weak drafts go back to REVISE with the scorer's notes, not to production.
trace: Every claim traces to evidence. Facts from a crawl stay pending_review until someone confirms them.
measure: Benchmark on your own data before choosing a provider. Four STT vendors on real Hindi calls, not a leaderboard.
retry: Agents call flaky APIs. Idempotent handlers, retries with backoff, de-dupe by message ID. Same lessons that cut failures 90% at Spinny.
route: Strong model for the hard step, cheap models for grunt work, GPUs that sleep when idle.
own: Sit with the customer, scope the messy problem, ship, and stay on the hook for the outcome.

$ cat /etc/clients

WORKED WITH

[✓]Spinnydealer finance, auctions, connected cars (SDE-2)
[✓]Hashtag OrangeGoogle Ads + Meta Ads reporting automation
[✓]Happy Naturecall intelligence + WhatsApp bot
[✓]DS GroupWebAR experience for their 97th Founders' Day

$ cat /etc/stack

TOOLS

lang      python  sql  js/ts  bash  (go, rust: dangerous enough)
backend   django  drf  channels  fastapi  celery  kafka
data      postgres  pgvector  redis  mongo  cosmos
infra     aws (lambda, eb)  azure (aks, blob, gpu vms)  docker  k8s
ai        claude code  anthropic api  langgraph  pipecat  stt/tts (sarvam, deepgram)
watching  sentry  new relic  prometheus

$ ls -lt /var/log/blog

WRITING

-rw-r--r--2026-10-023 min20 people to 3: the part of an LLM pipeline that isn't the LLM

cd /blog →