The Lab

I'm Upayan Ghosh, a backend engineer, most recently an Associate Software Engineer at Accenture through August 2026. Outside of that role, I build systems like Synapse that are built to report honestly on their own state, and I'm currently available for new opportunities.

About me · lib/metadata.ts · components/ui/identity-block.tsx · /about

I'm a backend engineer drawn to one specific problem shape: systems that can report, honestly, on their own state, with logging, metrics, and provenance built in as part of the job rather than bolted on afterward. Most recently that meant production work at Accenture, and outside work it means building agent infrastructure like Synapse, tldr, and claude-jarvis.

About me · app/about/page.tsx · /about

My most recent role was Associate Software Engineer at Accenture, the title Accenture itself gave me, from October 2024 to August 2026. I describe my own discipline as backend and AI-infrastructure engineering, which is a self-description rather than Accenture's title for me.

About me · lib/metadata.ts · /resume

I have about two years of professional software engineering experience, at Accenture from October 2024 to August 2026, alongside the open-source systems work on Synapse, tldr, and claude-jarvis documented on this site.

About me · lib/metadata.ts · data/projects.ts · /resume

I'm based in Kolkata, India, and open to remote work.

About me · lib/metadata.ts · components/ui/identity-block.tsx · /about

Yes. I left Accenture in August 2026 (October 2024 to August 2026) and I'm an immediate joiner, with no notice period to serve. I'm based in Kolkata, India, and open to remote work or relocation.

About me · lib/metadata.ts · owner-supplied 2026-08-14 (gaps.md review) · /about

Email is the most direct route: upayan1231@gmail.com. I'm also at github.com/UpayanGhosh and linkedin.com/in/upayan-ghosh. All three are listed on the resume page too.

About me · lib/metadata.ts · /resume

None. I left Accenture in August 2026 with no notice period to serve, so I'm an immediate joiner: I can start a new role right away.

About me · owner-supplied 2026-08-14 (gaps.md review) · lib/metadata.ts · /about

Yes. That's separate from being open to remote work: I'm willing to relocate for the right role, not just work it remotely from Kolkata.

About me · owner-supplied 2026-08-14 (gaps.md review) · /about

I'm based in Kolkata, India, and authorized to work in India. I don't have anything published here about authorization to work in any other country, so I'd rather leave that unanswered than guess.

About me · owner-supplied 2026-08-14 (gaps.md review) · lib/metadata.ts · /about

All of them: full-time, contract, part-time, and freelance work are all on the table for me. If a role fits, the arrangement around it is negotiable.

About me · owner-supplied 2026-08-14 (gaps.md review) · /about

Open to discussion. I don't publish a number here on purpose: it depends on the role, the arrangement, and the scope, so it's a conversation I'd rather have directly than answer with a figure that would be wrong for most roles anyway.

About me · owner-supplied 2026-08-14 (gaps.md review) · /about

Yes, available on request. I share those privately over email rather than publishing any names here.

About me · owner-supplied 2026-08-14 (gaps.md review) · /about

Digital or remote interviews, calls, or meetings are my preference. You can book a 30-minute call with me directly, or email me at upayan1231@gmail.com to arrange one.

About me · owner-supplied 2026-08-14 (gaps.md review) · https://calendar.app.google/juctyoJkBBqV6pgq7

I'm a big gamer, on a Windows gaming PC, and I ride a motorcycle when I get the chance. I do a fair amount of trekking, play football, and spend time on photography and making content. Mostly, though, it's time with friends.

About me · owner-supplied 2026-08-14 (gaps.md review) · /about

A Windows gaming PC is my main machine. I write code in VS Code and Visual Studio, use Claude Code as part of the workflow, and Python is my most-used language day to day.

About me · owner-supplied 2026-08-14 (gaps.md review) · /uses

I keep two separate ledgers here. At Accenture, from October 2024 to August 2026, I kept a production system running and built two internal tools: a read-only Claude agent over a 2,300-table database, and an LLM documentation pipeline over 2,342 tables and 3,395 stored procedures. That work is under NDA, and its numbers come from a private export I can describe but can't link to. Synapse, tldr, and claude-jarvis are my own open-source projects, built outside that role, with public repositories and public numbers. Nothing in this site's Accenture figures comes from those projects, and nothing in the project figures comes from Accenture.

About me · data/accenture.ts · data/projects.ts · app/about/page.tsx · /work

At Accenture I kept a production system running, which mostly meant figuring out why something broke when the symptom and the cause sit in different places. I resolved and closed tickets, contributed pull requests, and built small tools that took repetitive questions out of my own inbox.

Accenture work · data/accenture.ts · app/page.tsx · /work

I built two internal tools that took routine questions out of my inbox. The first is a read-only Claude agent, exposed over MCP with credential isolation, that made a 2,300-table database self-service so engineers could query it without routing through me. The second is a documentation pipeline that used an LLM to explain 2,342 tables and 3,395 stored procedures across two production databases, tagging each explanation as curated, AI-generated, or rule-derived.

Accenture work · accenture-tables-self-service · accenture-tables-documented · accenture-procedures-documented · data/accenture.ts · /work

A ticket reached me only after it had already been closed and reopened, each earlier close treating it as a single bad value rather than a symptom of something structural. I mapped every check an internal approval rule engine ran against the record and tested each one directly, and found they all failed for the same reason: the destination was approved for the account but filed under a different internal grouping than the record's own project used. That reframing was what made the fix hold instead of reopening again.

Accenture work · data/decisions.ts (accenture-relocation-approval-mismatch) · /about

Over the stretch my Azure DevOps export covers, I was assigned 97 work items and personally resolved or closed 51 of them, at a median of 4.9 days from assignment to close. That median is measured on the subset of resolved items with a usable timestamp on both ends, not all 51, and I say so rather than smooth it over. Nineteen of my pull requests merged in the same window.

Accenture work · accenture-work-items-assigned · accenture-work-items-resolved · accenture-resolution-time-median · accenture-pull-requests-merged · /about

I can't name the client, the product, the internal system, or any colleague I worked with there; that's an NDA boundary I hold everywhere on this site, not just here. What I can say: I worked in Python against Azure DevOps, and I built tooling there using the Claude API through MCP. The numbers behind that work come from a private export I can describe but can't link to.

Accenture work · data/accenture.ts · app/work/page.tsx · /work

At Accenture I worked in Python against Azure DevOps, and I built internal tooling there using the Claude API through MCP (Model Context Protocol). That's the complete list I name for that engagement; anything more specific would mean naming a client, product, or internal system, which I don't do.

Accenture work · data/accenture.ts · /work

Synapse is a self-hosted AI agent platform I built that runs across WhatsApp, Telegram, Discord, and Slack, all backed by one shared memory and retrieval layer instead of a separate bot per app. I'm its sole architect and maintainer, and it's active, ongoing work, not something I shipped once and left. It's built in Python on FastAPI, with LanceDB and SQLite FTS5 underneath.

Personal project · data/projects.ts · /work/synapse

I wanted an agent that could remember a conversation started on Telegram and continue it on Slack days later, using one retrieval layer instead of a different memory per chat app. Off-the-shelf agent frameworks assume one interface and one conversation at a time, so getting that meant owning the full stack myself: async message ingestion, a fusion-based retrieval pipeline, and LLM routing that doesn't go dark when one provider has an outage.

Personal project · app/work/[slug]/page.tsx (CASE_STUDIES.synapse.problem) · /work/synapse

Synapse retrieves context by embedding the incoming query, searching a vector index, and fusing that similarity score with recency, importance, and affect signals into one ranked result. A fast gate returns the top match immediately when the fused score is confident enough; anything less confident gets reranked by a second, smaller model before Synapse answers. I haven't published latency numbers for this pipeline: the benchmark scripts exist, but I haven't run them against a committed dataset, so I'd rather show nothing than a figure I can't back.

Personal project · app/work/[slug]/page.tsx (CASE_STUDIES.synapse.architecture) · data/metrics.ts (withdrawn latency note) · /work/synapse

Synapse routes every request across 17 LLM providers, each registered by its own key, with fallback chains so one provider's outage doesn't take the agent down. My own project README undercounts this with a smaller, more conservative figure, since that's the curated list most readers would notice first; 17 is the literal count in the router's own provider map, and I've published that number specifically because a reader can count it directly against the source.

Personal project · synapse-llm-providers · /work/synapse

When a provider call fails, Synapse first works out what kind of failure it is instead of retrying everything the same way: a rate limit gets a backoff and retry on the same provider, an authentication failure rotates to a different credential, a context-window overflow triggers compaction before retrying, and a model-not-found or billing error fails fast instead of retrying something that can never succeed. That classification currently runs on matching the provider's own error text, which is a real, ongoing fragility I've written about rather than smoothed over.

Personal project · content/posts/synapse-llm-router-error-recovery.mdx · /writing/synapse-llm-router-error-recovery

Synapse's long-term memory now lives in a SQLite knowledge graph instead of the in-memory NetworkX object I started with, because peak memory scaled with graph size and a restart could lose anything that hadn't been serialized cleanly. I kept the new store's method names identical to NetworkX's own, so the rest of the codebase didn't have to change while the storage underneath did. I haven't published a memory-reduction percentage for the migration: my own README makes that claim, but I don't have a committed benchmark artifact behind it yet, and citing my own README as proof of itself isn't good enough for this site.

Personal project · data/decisions.ts (synapse-knowledge-graph-migration) · content/posts/synapse-knowledge-graph-migration.mdx · /writing/synapse-knowledge-graph-migration

Every message into Synapse, across its WhatsApp, Telegram, Discord, and Slack channels, crosses one shared ingestion layer before the agent core ever sees it: a batching stage that groups a fast burst into one unit of work, a deduplication pass that catches retried webhooks, and a bounded queue that applies backpressure instead of growing memory without limit. A load test firing 500 concurrent sends at that queue asserts exactly-once processing, with nothing dropped and nothing duplicated. I haven't published a dated run log for that test, so I describe it as what the test asserts, not as a recorded result.

Personal project · synapse-burst-delivery · data/decisions.ts (synapse-bounded-queue-ingestion) · content/posts/synapse-bounded-queue-ingestion.mdx · /writing/synapse-bounded-queue-ingestion

Synapse exposes 9 MCP server modules, covering things like browser control, calendar, Gmail, memory, and Slack, so external clients can use its tools and memory instead of everything being locked inside the agent itself. They live under one directory in the repository and are identical across every active branch.

Personal project · synapse-mcp-modules · /work/synapse

Synapse is a real amount of code, not a demo: 79,746 lines of Python, 835 commits, and a test suite of 3,897 tests, measured on the project's develop branch, which carries some work not yet merged to main. All three numbers came from a full clone-and-count I ran myself, not an estimate.

Personal project · synapse-python-loc · synapse-commit-count · synapse-test-count · /work/synapse

Yes, Synapse is fully open source, at github.com/UpayanGhosh/Synapse-OSS. It isn't published to npm the way tldr and claude-jarvis are: the README's install instructions reference a package name that doesn't currently resolve on the registry, so I only link the GitHub repository until that's fixed.

Personal project · data/projects.ts · /work/synapse

Synapse has had 2 external contributors so far, counted from unique author emails across every branch, after excluding the addresses that are actually mine under different accounts. It's still mostly a solo project: I'm its sole architect and maintainer.

Personal project · synapse-external-contributors · data/projects.ts · /work/synapse

Synapse itself is self-hosted by design, so there's no public product URL to sign up for. What you can try instead is the live retrieval playground on /lab: a real query against Synapse's own architecture docs, with the actual retrieval trace and measured latency for that specific request, not a canned screenshot.

Personal project · data/projects.ts · app/lab/page.tsx · /lab

tldr is a skill I built that turns any repository into a generated onboarding site: dependency graphs, directory maps, and a framework-specific cookbook, regenerated automatically instead of hand-maintained until it drifts from the code. I'm its sole author, and it ships as both a GitHub repository and an npm package.

Personal project · data/projects.ts · /work/tldr

A new engineer's first days on a codebase are spent building a mental map that already exists implicitly in the repository's own structure. Off-the-shelf documentation generators template from doc-comments instead of reasoning about that structure, and sending a whole repository through a model file by file gets slow and expensive fast, so I built a pipeline that only spends model calls on what static analysis genuinely can't produce.

Personal project · app/work/[slug]/page.tsx (CASE_STUDIES.tldr.problem) · /work/tldr

tldr runs three tiers, cheapest first. Pure-Python static analysis pulls out imports, directory layout, and framework signatures with no model call at all. Parallel Haiku workers turn that structure into per-file summaries and cookbook drafts. A single Sonnet pass does the final synthesis under a fixed token budget, producing the dependency graphs and directory maps in the generated site.

Personal project · data/decisions.ts (tldr-tiered-inference-architecture) · content/posts/tldr-tiered-inference-architecture.mdx · /work/tldr

Four of tldr's headline numbers, an inference-cost reduction, a language count, a repo-scale ceiling, and a synthesis token budget, are withdrawn as of 2026-08-16: none of them has been verified directly against github.com/UpayanGhosh/tldr-skill yet, so none of them renders on the page right now, not even with an unverified label. The one figure I still show is trailing-year npm downloads, at 1,047, checked directly against the public registry. I'll restore each withdrawn figure once I've verified it against the repository myself.

Personal project · tldr-downloads-1y · data/metrics.ts · /work/tldr

tldr is on npm as tldr-skill, and the source is at github.com/UpayanGhosh/tldr-skill. Trailing-year downloads sit at 1,047, the one tldr figure I've checked directly against the npm registry rather than inherited from an earlier draft.

Personal project · data/projects.ts · tldr-downloads-1y · /work/tldr

claude-jarvis is a universal intent router for Claude Code that I wrote in TypeScript: it matches an incoming request against common, unambiguous intents first, and falls back to scanning installed plugins for the right skill when nothing matches directly. I'm its sole author, and it's active, current work.

Personal project · data/projects.ts · /work/claude-jarvis

Claude Code's plugin ecosystem gives every plugin its own invocation surface, so a user would normally have to remember which specific skill handles a given request. claude-jarvis removes that: a fast-path matcher handles common intents directly with no further lookup, and anything that doesn't match falls through to dynamic discovery, which scans installed plugins for the right skill file at request time instead of consulting a static registry.

Personal project · app/work/[slug]/page.tsx (CASE_STUDIES.claude-jarvis) · /work/claude-jarvis

claude-jarvis had 2,259 downloads in its first 30 days after release, which is real but is a launch spike, not a running rate: a fresh pull showed 95 downloads in a trailing 30-day window, and 2,690 over the trailing year. I publish all three side by side instead of just the flattering one, after catching myself letting the launch number imply a current pace it wasn't measuring anymore.

Personal project · claude-jarvis-downloads-launch-30d · claude-jarvis-downloads-30d · claude-jarvis-downloads-1y · /work/claude-jarvis

claude-jarvis is on npm as claude-jarvis, with the source at github.com/UpayanGhosh/claude-jarvis. It's built against the Claude Code Plugin API.

Personal project · data/projects.ts · /work/claude-jarvis

They solve different problems. Synapse is a self-hosted agent platform spanning WhatsApp, Telegram, Discord, and Slack, with its own memory and retrieval layer. tldr generates an onboarding site for an existing repository, so a new engineer doesn't have to build a mental map by hand. claude-jarvis is a small, focused router that gets Claude Code to the right plugin skill without you remembering which one handles what. Synapse is the one I actively architect day to day; the other two are built and maintained rather than under constant active development.

Personal project · data/projects.ts · /work

Yes. Beyond Synapse, tldr, and claude-jarvis, I've also shipped local-qwen-coder-turboquant (running a large coding model locally on consumer hardware), Pixamart (a Flutter wallpaper app), and Chat-with-Code (a CLI that answers questions about a codebase using local models), without a metrics ledger behind any of them. They're smaller, and the site lists what each one is and nothing more.

Personal project · data/projects.ts (secondaryProjects) · /work

local-qwen-coder-turboquant is a set of Windows setup notes and scripts for running Qwen3-Coder-30B-A3B-Instruct locally, as a coding-only, OpenAI-compatible backend on a consumer NVIDIA RTX 3060 Ti. I wrote up the process, including an out-of-memory failure and the fix that solved it, in a piece published on GoPenAI.

Personal project · data/projects.ts (secondaryProjects) · data/external-writing.ts · /work

Pixamart is a wallpaper app I built in Flutter, using the Pexels API for search and categories, with Firebase Auth (including Google Sign-In), offline support, and cloud sync. It's archived now; it's my oldest shipped project on the site.

Personal project · data/projects.ts (secondaryProjects) · /work

Chat-with-Code is a CLI I built that answers questions about a codebase using local Ollama models and LangChain's retrieval-augmented generation: it indexes a target folder by chunking and embedding source files into a local Chroma vector database, then answers questions against that index.

Personal project · data/projects.ts (secondaryProjects) · /work

My day-to-day stack spans Python (FastAPI, asyncio) and TypeScript, with LanceDB and SQLite FTS5 for retrieval and search, the Claude API and Claude Code Plugin API for agent and tooling work, Cytoscape.js and D3.js for the graphs tldr generates, and Azure DevOps from my Accenture work. That's my resume's own Skills section, not a broader claim.

About me · app/resume/page.tsx (SKILLS) · /resume

Python and TypeScript are the two languages behind everything currently active on this site: Python for Synapse, tldr, and my Accenture tooling, TypeScript for claude-jarvis and this site itself. Earlier projects also used Dart (Pixamart) and PowerShell and shell scripting (the local Qwen setup).

About me · app/resume/page.tsx · data/projects.ts · /resume

Yes. I keep a public LeetCode solutions repository, and the /dsa page on this site re-counts it live from GitHub every time the page loads, refreshed at most once an hour, rather than a number I typed in once and could forget to update. It also splits solutions by difficulty and by language, in C++ and Python.

About me · app/dsa/page.tsx · lib/dsa-metrics.ts · /dsa

I don't hand-maintain that number here on purpose: /dsa fetches the live count from my GitHub repository on every page load rather than repeating a figure that could go stale. The honest answer is to send you there for the current count rather than quote you one that might already be wrong by the time you read it.

About me · lib/dsa-metrics.ts · app/dsa/page.tsx · /dsa

I write long-form technical posts that start from a real decision record (the context, the options I considered, what I chose, and what it cost) and expand it into the reasoning I'd want to read if I were checking someone else's work. Right now that covers Synapse and tldr's architecture, plus one piece hosted externally about running a coding model locally.

Writing · app/writing/page.tsx · /writing

"Why every message into Synapse waits in a bounded queue first" covers the batching, deduplication, and bounded-queue design ahead of Synapse's agent core, and what a 500-concurrent-send load test actually proves versus what it doesn't; there's no published, dated run log behind it yet.

Writing · content/posts/synapse-bounded-queue-ingestion.mdx · synapse-burst-delivery · /writing/synapse-bounded-queue-ingestion

"Why Synapse's knowledge graph lives in SQLite, not memory" walks through moving Synapse's knowledge graph off an in-memory NetworkX object and into SQLite, why I kept the old interface intact during the move, and why I'm still not publishing a memory-reduction percentage for it: I don't have a committed benchmark artifact behind that number yet.

Writing · content/posts/synapse-knowledge-graph-migration.mdx · data/decisions.ts (synapse-knowledge-graph-migration) · /writing/synapse-knowledge-graph-migration

"Classifying failures before deciding how to recover from them" is about how Synapse's LLM router tells a rate limit apart from an authentication failure or a context overflow, so each gets a different recovery instead of one generic retry, plus the honest cost of doing that classification by matching provider error text instead of structured error codes.

Writing · content/posts/synapse-llm-router-error-recovery.mdx · /writing/synapse-llm-router-error-recovery

"Static analysis first, model calls second" explains tldr's three-tier pipeline and the specific failure that reshaped its token budget: an early version under-budgeted what the cheaper tiers could absorb, so large repositories blew past what a single synthesis pass could handle cleanly.

Writing · content/posts/tldr-tiered-inference-architecture.mdx · /writing/tldr-tiered-inference-architecture

Yes, one piece so far: "From OOM to 262K Context: Running Qwen3-Coder 30B Locally on 8GB VRAM," published on GoPenAI. It documents the local-qwen-coder-turboquant project: an out-of-memory failure, the pivot that fixed it, and the setup that resulted.

Writing · data/external-writing.ts · /writing

This site is built with Next.js on the App Router, React, and TypeScript in strict mode, mostly statically rendered. Every colour, size, and spacing value resolves to a design token defined once, and the one live backend on the whole site is the Lab's retrieval demo, deliberately hosted on its own small VPS instead of folded into the same hosting as everything else, so a visitor can see a real, separately-operated service instead of a function indistinguishable from the marketing pages around it.

This site · app/colophon/page.tsx · /colophon

Every number on this site is defined once, with a stated method and date, and every place that number appears reads it from that single definition instead of being typed in twice. The dotted underline is the tell: hover or focus it and you get the method and date behind that exact figure, so "trust me" is never the only thing backing a number here.

This site · data/metrics.ts · components/ui/provenance-tag.tsx · /about

Yes. When a number doesn't survive a check, I withdraw it rather than quietly edit it: the site is built so a reference to a withdrawn figure fails the build outright instead of shipping. The most recent case was a resume line claiming a specific count of engineers using one of my Accenture tools directly; I pulled it myself once I realized it came from my own resume rather than an actual measurement of who queried the system.

This site · data/metrics.ts (OWNER RETRACTION note) · /about

This tool matches what you type against a fixed set of answers I wrote and sourced myself, using a small embedding model that runs in your browser, plus a small language model that also runs there once your device has finished downloading it. Your question is answered on your device: nothing you type is sent anywhere unless you use the optional card under the conversation to email me the exchange yourself, which is a button you have to press. A confident match is answered from the pre-written text with a link back to where it's sourced; below that confidence, you get an honest "I don't have that on record" instead of a guess.

This site · owner-supplied 2026-08-15 (lead-capture design) · app/colophon/page.tsx · /lab

The Lab used to run a live query against a self-hosted Synapse retrieval backend, but that backend was never provisioned, so the widget could only ever show one recorded example, permanently labelled as such. I removed it on 2026-08-14 rather than leave a demo that could never actually be live. Ask the ledger, the tool above this list, is the Lab's one real live feature now: it runs entirely in your browser, matching your question against this same FAQ corpus. The only time anything reaches a server is if you choose to email me the conversation from the card under it.

This site · app/lab/page.tsx · app/colophon/page.tsx · /lab

Nothing at all, unless you press the button. If you do, exactly what you can see in the conversation, plus your address and the times it started and was sent, is emailed to me through Resend, an email relay, and lands in my personal inbox. Nowhere else: no database of conversations or addresses, no mailing list, and the page-view analytics running elsewhere on the site never sees this conversation or your address. I read it, reply to you myself, and use whatever it failed to answer to fix the corpus. Email me at upayan1231@gmail.com whenever you want it deleted.

This site · owner-supplied 2026-08-15 (lead-capture design) · app/api/lab-lead/route.ts · /lab

Yes: this site calls itself "The Systems Ledger," which is also the whole idea behind it: every claim gets logged with its method and date instead of just stated.

This site · lib/metadata.ts · /

Most figures link straight to something you can check yourself: a GitHub commit, a repository you can clone and grep, or a public npm registry endpoint, and each project's case study includes the exact commands I ran. The Accenture figures are the one exception: they come from a private client export with no public URL, so for those you have my stated method rather than a link to click through, and the site says so plainly rather than dressing them up the same way as the rest.

This site · app/work/[slug]/page.tsx (Verification sections) · app/work/page.tsx · /work/synapse

There's a dedicated status page at /uptime that polls the marketing site, the Synapse API, and the Lab backend independently and reports what a third-party checker actually observed, refreshed on a five-minute cycle. It's built to show "unknown" rather than a stale or invented status if a check can't reach a service, so I'd rather send you there for the current state than repeat a status here that could be wrong by the time you read it.

This site · data/services.ts · app/colophon/page.tsx · /uptime

I have a B.Tech in Computer Science and Engineering from Techno International New Town, 2020 to 2024.

About me · app/about/page.tsx · app/resume/page.tsx · /resume

I hold two: Claude Certified Architect, Foundations, from Anthropic, and Reinvention with Agentic AI, from Accenture. Neither carries a stated issue date, credential ID, or verification link on my resume, so I don't display one I don't actually have.

About me · data/certifications.ts · /resume

As of my last update, 2026-08-10, I'm rebuilding Synapse's rerank stage and writing up its retrieval trace format for the Lab page. I keep a dated /now page specifically so this doesn't quietly go stale without me noticing.

About me · app/now/page.tsx · /now

Yes, there's a PDF download on the resume page now. It's a separate document I dropped in rather than an export of the page itself, so the two could in principle drift from each other; if you specifically want this page's own content as a PDF instead, your browser's print-to-PDF still works, since /resume reads as a single ATS-safe column either way.

About me · app/resume/page.tsx · public/UpayanGhosh_Resume.pdf · /resume