AMEYA DESHMUKH@ameyadeshmukh16
2
Events attended
1
Submissions made
India
8+ years of experience
About me
Nine years of building enterprise data pipelines taught me something most engineers learn too late: the architecture decisions made before a single line of code is written determine whether a data platform scales — or collapses under its own weight. That conviction is what shaped my career, and it's what's now driving my deliberate move from data engineering into data and AI architecture. Over 9+ years at Bitwise, I've delivered 6+ enterprise data projects across retail, wholesale, and banking domains — designing and owning pipelines that process 8M+ records daily across Informatica PowerCenter, IICS, Azure ADF, Synapse, Microsoft Fabric, and Databricks. As a Technology Lead, I coordinate cross-functional teams of 6–8 engineers and drive end-to-end architecture decisions from raw ingestion to analytics-ready layers. This includes two full Medallion Architecture POCs for retail transaction reporting — built on Azure Databricks and ADF + ADLS, implementing the complete Bronze → Silver → Gold pattern: raw landing and schema enforcement in Bronze, cleansed and conformed transaction data in Silver, and aggregated, business-ready reporting marts in Gold. I also lead active data quality initiatives including a Databricks DQX framework POC currently in development. I'm actively building at the intersection of data engineering and Generative AI — exploring RAG pipelines grounded in lakehouse architecture, agentic data workflows using MCP-based orchestration, and prompt engineering patterns that make LLMs reliable over enterprise data. My view: data engineers who understand AI infrastructure from the ground up are the ones best positioned to architect it responsibly. I'm building toward that role — deliberately and practically, not theoretically. If you're rethinking data architecture for an AI-first world — or building teams that sit at that boundary — I'd like to be in that conversation.
🤓 Latest Submissions
ReconcileIQ
The problem. Before paying a vendor invoice, AP teams match it to a purchase order and a goods receipt. When the numbers differ, someone pulls the documents, works out what happened and writes down why. It is slow, and the reasoning is rarely recorded. Automation usually stops at "numbers don't match". What it does: Deterministic rules check every invoice against its PO and goods receipt and flag exceptions. Clear cases, like an exact duplicate, go straight to review. An investigation agent takes the ambiguous cases. It retrieves the records through tools, checks policy and PO amendments, and submits a structured finding with a recommendation (approve, request vendor clarification, escalate or reject) and a confidence level. A review dashboard shows the evidence side by side with the agent's reasoning. The reviewer accepts the recommendation or overrides it, with a reason. An insert-only audit trail records every rule check, tool call, status change and decision, including which Vultr model produced each finding. The key idea: explanation is not authorization. Why you can trust it. The controls are enforced in code, not in the prompt: The "verified facts" are built by the backend from the retrieved records and its own arithmetic. The model's text is shown only as interpretation. The agent can retrieve only its own invoice and PO, and cannot submit a finding until the required lookups have run. approve is blocked when an invoice overbills with no covering amendment, even if the model is told to approve. A failed investigation falls back to human review rather than guessing. The recorded reviewer is the authenticated user, not a typed name. Vultr usage: One Vultr cloud VM runs the app with Docker Compose and automatic HTTPS. Vultr Serverless Inference (deepseek-v4.1-flash-1017) powers the tool-calling investigation loop. OpenRouter is a fallback only for transient failures; configuration and authentication errors fail loudly.
8 Nov 2026
