Skip to content
⟡ yash.patel yantresh — the holder of threads
ThreadsCase StudiesYantreshExperienceContact Start a thread →
Available for AI infrastructure & automation engineering

FULL-STACK DEVELOPER · n8n CERTIFIED PROFESSIONAL

I hold the threads between systems.

Orchestration is my craft: distributed scrapers feeding ML matchers, LLM pipelines guarded by strict schemas, and agent loops that are mathematically incapable of hanging. I design the canvas, wire the nodes, and ship the flow to production.

Inspect the case studies yash.patel.exclusive@gmail.com

⌖ Kitchener, ON, Canada · Remote-first

amatya@yantresh:~

Command: whoami. Output: yash.patel — full-stack dev · ai orchestration · data at scale

Command: n8n certs --verify. Output: ✓ n8n Certified Professional

Command: uptime --career. Output: 4+ yrs · 1M+ products tracked · 300+ stores · 30K+ app installs

Command: ./yantresh --status. Output: ACTIVE DEV → AI Workforce OS · Phase 0: prove the loop

1M+

products tracked

at peak, across the comparison engine

300+

stores scraped

distributed crawl fleet on Azure

<100ms

search response

on 5,000+ daily indexed records

30K+

app downloads

Flutter iOS/Android · 4.3★ rating

4+

years shipping

full lifecycle: scope → deploy → scale

100%

schema-gated LLM I/O

strict JSON Schema validation on every output

THE THREADS

A constellation wired for orchestration

Every cluster below is a live input to the case studies. Hover a thread to see where it lands in production.

Languages & Core

JavaScriptGoBash/Zsh

Frontend Systems

React.jsNext.jsAngularHTML5 / CSS3Responsive Design

Backend & APIs

Express.jsFlask / DjangoGraphQLOAuth 2.0 / JWTMicroservices

THE ORCHESTRATOR

design the canvas · wire the nodes · bound the loop

Cloud & DevOps

AWS (Lambda · EC2 · S3 · RDS)Kubernetes

Data Layer

MongoDBDynamoDBApache Kafka

AI & Automation

LangChain
hover a glowing thread to light up the case study it feeds — click to jump there

CASE STUDIES

Three engines, one doctrine

Scale it, automate it, then bound it. Each node below is a production system — trace the threads from trigger to terminal state.

PROJECT NEXUS / 01

The Data Scale Engine

Software Engineer · One Red Maple · 2021 — 2024

SHIPPED · PRODUCTION

A distributed web scraping and matching infrastructure that tracked 1M+ products across 300+ e-commerce stores, powering a consumer price-comparison product on web, mobile, and browser extension.

▣ THE PROBLEM

Marketplace listings and local-store catalogs describe the same physical product with 90%+ string difference — long SEO-stuffed marketplace titles versus terse local names. Comparing prices at city scale meant continuously crawling hundreds of hostile, anti-bot-protected storefronts and resolving identity across catalogs with no shared keys.

▣ THE APPROACH

Decompose the crawl into queue-fed, per-store workers behind rotating proxy pools; normalize and deduplicate everything into a single index; and resolve product identity with a purpose-trained ML model that fuses string features with image similarity. Every stage is independently scalable and independently restartable.

TRIGGER Crawl Orchestrator GitHub Actions · cron fan-out per store
INFRA Azure Service Bus work queues · dead-letter lanes
COMPUTE Scraper Fleet Node.js + Python · rotating proxies per platform
COMPUTE Normalize + Dedup ETL · 5,000+ records/day
ML ML Match Engine product + image matching across 90%+ string drift
INFRA Azure Search Index 1M+ products · sub-100ms reads
OUTPUT Consumer Surfaces web app · Flutter iOS/Android · browser extension

Flow connections: Crawl Orchestrator flows to Azure Service Bus; Azure Service Bus flows to Scraper Fleet; Scraper Fleet flows to Normalize + Dedup; Normalize + Dedup flows to ML Match Engine; ML Match Engine flows to Azure Search Index; Azure Search Index flows to Consumer Surfaces.

Nexus pipeline — serpentine flow from scheduled fan-out to consumer surfaces.

Anti-bot resilience as infrastructure

Rotating proxy pools configured per e-commerce platform sustained large-scale collection without blocking — reliability was engineered into the transport layer, not patched per incident.

Identity across 90%+ string drift

Trained a product + image matching model that resolves identical items across wildly inconsistent naming, letting users find cheaper local alternatives to marketplace listings.

Sub-100ms at million-product scale

Normalization, deduplication, and Azure indexing of 5,000+ daily records kept search under 100ms while the catalog grew past 1M tracked products.

Funnel-driven product iteration

GA4 event tracking exposed a 23% onboarding drop-off; the redesign it motivated lifted conversions 11% on a 30K+ download, 4.3★ Flutter app.

1M+

products at peak

300+

stores crawled

5K+

records normalized daily

<100ms

search response

Node.jsPythonAzure Service BusAzure FunctionsGitHub ActionsRotating ProxiesML MatchingFlutterGA4

PROJECT SYNAPSE / 02

The Autonomous Operations Engine

Full-Stack Developer · Patel Solutions Corp. · 2024 — PRESENT

SHIPPED · LIVE CLIENTS

AI-powered operations automation for North American SMBs: n8n-orchestrated pipelines that fuse Stripe, supplier feeds, POS systems, and LLM reasoning — with every model output gated by strict JSON Schema validation before it can touch a database.

▣ THE PROBLEM

Small businesses run on manual glue: re-keying supplier feeds, dispatching orders by hand, reconciling payments against bookings. LLMs can automate the judgment steps, but raw model output is untrusted input — one malformed or hallucinated field can corrupt inventory, overcharge a customer, or break a POS sync.

▣ THE APPROACH

Treat the LLM as just another untrusted node on the canvas. n8n owns orchestration — triggers, branching, retries, idempotent dispatch. Claude and OpenAI handle classification, extraction, and drafting. Nothing the model emits reaches a business system until it passes a strict JSON Schema gate; invalid payloads are bounced back for bounded re-prompting, then routed to error lanes with alerting.

TRIGGER Event Triggers webhooks · cron · Stripe events · supplier feeds
INFRA n8n Orchestrator branching · retries · idempotent dispatch
ML LLM Reasoning Claude + OpenAI · classify · extract · draft
GUARD JSON Schema Gate strict validation · the trust boundary
OUTPUT Business Systems POS sync · inventory · booking · Stripe
GUARD Audit & Alerting error lanes · run logs · human escalation

Flow connections: Event Triggers flows to n8n Orchestrator; n8n Orchestrator flows to LLM Reasoning; LLM Reasoning flows to JSON Schema Gate; JSON Schema Gate rejects back to LLM Reasoning (invalid → re-prompt); JSON Schema Gate flows to Business Systems; Business Systems flows to Audit & Alerting.

Synapse flow — the schema gate is the trust boundary; rejected payloads loop back, bounded.

Schema validation as a trust boundary

Strict JSON Schema validation on all LLM outputs protects downstream databases and applications — hallucinated fields die at the gate, never in production data.

Zero-touch daily operations

n8n and Make.com ETL pipelines sync real-time product data from supplier feeds and stream order dispatch into inventory systems, eliminating manual intervention from daily operations.

Payments wired end-to-end

Stripe processing, booking and reservation engines, and website-to-POS data synchronization integrated with graceful error handling to protect uptime and revenue.

Full lifecycle ownership

Scoping, architecture trade-offs, deployment, and post-launch evolution on live codebases — shipped MVPs on time and grew them as the client businesses scaled.

100%

LLM output schema-gated

0

manual steps in daily ops

E2E

scope → deploy → support

24/7

autonomous pipelines live

n8nMake.comAnthropic ClaudeOpenAI APIJSON SchemaStripeTypeScriptNode.jsPythonREST / GraphQLOAuth 2.0

YANTRESH — AI WORKFORCE OS / 03

The Next-Gen Vision

Architect & Builder · Independent R&D · 2026 —

IN ACTIVE DEVELOPMENT

Yantresh (સૂત્રધાર — 'the holder of the threads') is a supervisor-over-worker agent platform built on one non-negotiable guarantee: no task can ever hang. One Amatya (supervisor) plans, bounds, and verifies; one Karta (worker) executes — model-agnostic by construction, costed per task, terminal by design.

▣ THE PROBLEM

Multi-agent systems burn ~15× the tokens of a single chat, fragment context across workers, and fail silently — a worker can simply declare success. The field's strongest skeptics and strongest advocates agree on the failure modes; almost nobody engineers for them up front.

▣ THE APPROACH

Use the supervisor not to parallelize, but to bound and verify. Every run is capped on five independent axes that each resolve to exactly one terminal action, every model call flows through one router seam so vendors are config rows rather than code, and a worker can never self-certify — the verification gate belongs to the Amatya. Phase 0 gates the whole platform: 4 of 5 golden tasks must pass under a fixed token budget before any dashboard exists.

TRIGGER Task Intake CLI · REST (FastAPI)
ML Amatya — Supervisor plans · reviews · owns the bounds
COMPUTE Karta — Worker executes · 3 tools · cheap fast model
GUARD Loop Guard + Breaker embedding fingerprints · circuit breaker per tool
GUARD Verification Gate definition-of-done · no self-certification
OUTPUT Terminal States complete · escalated · failed — with checkpoint

Flow connections: Task Intake flows to Amatya — Supervisor; Amatya — Supervisor flows to Karta — Worker; Karta — Worker flows to Loop Guard + Breaker; Loop Guard + Breaker flows to Verification Gate; Verification Gate rejects back to Amatya — Supervisor (replan ≤ 2); Verification Gate flows to Terminal States.

The bounded loop — every path terminates in complete or escalated. 'Stuck' is unreachable.

THE DOCTRINE

Five Bounds — why Yantresh can never hang

Every run is bounded on five independent axes. Every counter is monotonic and capped, and the only thing past a cap is a clean escalated or failed state with a checkpoint.

01

Step budget 25 tool-calls / task

forced supervisor review → escalate

02

Token budget e.g. 200K / task, all calls

soft warn at 80% · hard stop at 100%

03

Wall-clock budget 10 min

cancel in-flight · checkpoint · escalate

04

Retry ceiling 2 per subtask

mark blocked · move on or escalate

05

Replan ceiling 2 per task

escalate to human — never a 3rd replan

Loop Guard

Fingerprints every (tool, params, output) call; embedding cosine similarity > 0.92 in a sliding window flags the loop and burns a replan.

Circuit Breaker

Per tool/connector: opens after 3 consecutive failures, half-opens on timeout, fails fast while open — never hammers a dead endpoint.

Verification Gate

The Amatya checks worker output against an explicit definition-of-done before complete. A Karta can never self-certify.

steps↑ tokens↑ time↑ retries↑ replans↑ — every counter capped, every cap terminal. "Stuck" is unreachable.

MODEL-AGNOSTIC BY CONSTRUCTION

One seam for every model

Agent logic never calls a provider SDK. All inference crosses a single ModelRouter seam into a gateway — swapping a frontier model for DeepSeek or a local vLLM is a config edit, zero code change.

COMPUTE Agent Logic never imports a provider SDK
GUARD ModelRouter model per step type · budget caps · fallback chains
INFRA LiteLLM / OpenRouter one OpenAI-format endpoint · cost logging
ML Frontier Reasoning Anthropic · OpenAI — planning & review
ML Cheap Fast Models Google · DeepSeek · Mistral — execution
ML Local vLLM self-hosted · embeddings & overflow

Flow connections: Agent Logic flows to ModelRouter; ModelRouter flows to LiteLLM / OpenRouter; LiteLLM / OpenRouter flows to Frontier Reasoning; LiteLLM / OpenRouter flows to Cheap Fast Models; LiteLLM / OpenRouter flows to Local vLLM.

ModelRouter fan-out — model per step type, budgets and fallback chains enforced at the seam.
STEP TYPE MODEL CLASS WHY
Supervisor planning / review strong reasoning class quality-sensitive, low frequency
Worker tool-calling / execution cheap fast class high frequency, repetitive
Embeddings (loop guard, memory) shared API endpoint never a local model per worker

Evidence before architecture

Pattern validated against Anthropic's orchestrator-worker results (+90.2% over single-agent on research evals), LangGraph's supervisor library, and Cognition's pivot to coordinator-over-Devins — then deliberately constrained to 1+1 agents to dodge the 15× token trap.

A go/no-go gate, not a roadmap

Phase 0 is one week: hand-rolled ~300-line state machine, 3 tools, golden-task eval. If 4/5 tasks don't pass under the token budget, the platform doesn't get built. The loop is proven before a single dashboard exists.

Security-first runtime

Prompt-injection sanitizer on every tool output before it re-enters context, AES-256-GCM encrypted token store with per-tenant KDF, Postgres RLS with tenant_id on every table from day one.

Cost is a first-class signal

OpenTelemetry traces carry cost_usd and token counts on every LLM call, rolled up task → worker → tenant, with hard per-tenant spend caps enforced in the job processor.

5

independent bounds per run

1+1

supervisor + worker, by design

4/5

golden tasks to pass Phase 0

0

code paths that can hang

Python 3.13FastAPILiteLLM / OpenRouterRedisPostgreSQL + pgvectorPostgres RLSAES-256-GCMOpenTelemetryDockerStripe Metering

THE TIMELINE

Experience, threaded

Full-Stack Developer @ Patel Solutions Corp. / Independent Consulting

Mar 2024 — Present · Ontario, Canada · Remote

  • Built and deployed end-to-end web applications and MVPs for North American SMB clients in e-commerce, retail, and restaurant sectors — TypeScript, React, Node.js, Python — owning scoping through launch.
  • Integrated Stripe, delivery/ordering platforms, booking systems, OAuth 2.0 social auth, Google Maps, and inventory feeds with graceful error handling.
  • Architected AI automation workflows on OpenAI + Claude APIs with strict JSON Schema validation protecting all downstream systems.
  • Designed n8n / Make.com ETL pipelines syncing real-time supplier data and order dispatch — zero manual intervention in daily operations.
⟶ trace this thread in the case study

Software Engineer, AI Training (Freelance) @ Alignerr · Outlier AI · Handshake AI · Mindrift

Mar 2024 — Present · Remote

  • Evaluated and refined AI-generated code across four frontier AI platforms, feeding structured feedback into RLHF pipelines and reward model training.
  • Authored PRDs used as ground-truth training data: auth flows, data models, REST API design, edge-case error handling.
  • Documented hallucination patterns in query optimization and index usage, contributing to multiple model update cycles. Passed Alignerr vetting (~3% acceptance rate).

Software Engineer @ One Red Maple

May 2021 — Feb 2024 · North Bay, Ontario, Canada

  • Designed and built a distributed scraping system aggregating product listings from 300+ e-commerce stores, powering a price-comparison product across web, mobile, and browser extension.
  • Automated the pipeline on Azure (Service Bus, Functions) with GitHub Actions CI/CD and per-platform rotating proxy infrastructure.
  • Trained a product + image matching ML model resolving identical products across 90%+ string difference.
  • Engineered normalization, deduplication, and indexing of 5,000+ daily records — sub-100ms search over 1M+ tracked products.
  • Launched Flutter iOS/Android apps: 30,000+ downloads, 4.3★ App Store rating; GA4 funnel work lifted conversions 11%.
⟶ trace this thread in the case study

Data Engineer (Part-Time) @ Manish Advertising

Aug 2018 — Jul 2019 · India

  • Designed data workflows extracting insights from 10GB+ datasets; deployed Kafka Connect in standalone and distributed modes for real-time streaming.
  • Optimized reporting with complex SQL Server queries and stored procedures; containerized deployments with Docker on AWS.

OPEN A CHANNEL

Every system needs an orchestrator.

If you're scaling data infrastructure, wiring LLMs into operations that can't afford to break, or building agent systems that must terminate — let's trace the thread together.

yash.patel.exclusive@gmail.com
Email · yash.patel.exclusive@gmail.com LinkedIn · linkedin.com/in/patel03 Location · Kitchener, ON, Canada — remote-first
esc