06, Work

The Work

Lead Data Architect, AI Product & Systems, Insaito, Inc. (operating brand Automatan) · Jan–Mar 2026. Everything below is what I actually built, debugged and shipped, the detail a CV line can't hold. No proprietary code, prompts, client data or business figures appear below; what's shown is the engineering and process, in the same spirit as the rest of this site.

01 The Problem I Was Hired to Solve

Take an AI lead-generation pipeline from one vertical to four.

Automatan's product scrapes target-company websites against a set of criteria, scores the results with an LLM, and generates outreach material from those scores. Before this role, exactly one vertical worked end to end. The job was to replicate that pipeline for new markets, each defined by criteria written by non-technical product and sales staff, not engineers, while the inherited system underneath had unresolved reliability problems: duplicate scrape targets, unreliable failure counts, and, discovered mid-tenure, a systematic LLM hallucination pattern in the scoring stage itself.

I extended the pipeline to four production verticals (E-commerce, Consulting, Business-Coach and Recruitment, alongside the pre-existing Speaker vertical), while root-causing and fixing the data-integrity and model-reliability bugs underneath all of them.

1 → 4
Production verticals
extended & hardened
Faster email-generation
via added concurrency
~3K
Hallucination error lines
root-caused to one bug
02 What I Built & Fixed
~

Ingestion & Data Integrity

Fixing the Numbers Before Fixing the Model

Canonical-domain deduplication fix (http/https and www variants were silently counted as separate scrape targets). Fixed a progress-tracker that double-counted the same failed site across multiple report files. Built a new tool classifying every scrape failure by HTTP status code and network-error type, to separate "the target is genuinely unreachable" from "our pipeline is broken."

Python · Data pipeline debugging · Failure taxonomy

LLM Inference & Scoring

Root-Causing a Hallucination Pattern in Production

Refactored a Pub/Sub-driven, Triton-based inference server to fix a timestamp bug and a crash on the failure path. Root-caused a scoring bug where the parser checked for a field the prompt never produced. Separately traced a recurring hallucination pattern to a direct contradiction between the system prompt (forbidding extra keys) and the user prompt (demanding fields outside that schema), diagnosed against production logs, then shipped the fix.

Python · GCP Pub/Sub · OpenAI API · Prompt/schema debugging

Evaluation Methodology

Separating "Wrong Answer" from "Wrong Parsing"

Designed a two-stage evaluation methodology distinguishing whether the model answered a criterion correctly from whether the downstream parser interpreted that answer correctly, with a gold-labeled test-set plan and per-criterion confusion-matrix tracking. Cross-checked scoring outputs against a second reviewer's independently, surfacing concrete reasoning contradictions the model itself had missed.

Stratified sampling · Precision/recall · Confusion matrices

Schema & Architecture

Prose Prompts → Enforced JSON Schema

Led the migration from prose-described JSON output to OpenAI's enforced strict: true JSON Schema across four scoring and generation workflows, eliminating a whole class of parsing errors. Refactored the output router into per-market modules sharing a common base, and implemented a previously-empty email-publishing function end to end, with matching per-part output structure.

OpenAI structured outputs · Refactoring · GCP Cloud Tasks

Integrations & Tooling

CRM Migration & Internal Tools

Built an OAuth2 self-refreshing token client and field-mapping pipeline to migrate lead data from Streak into Zoho CRM. Added ThreadPoolExecutor-based concurrency to the email-generation stage. Wrote a small monitoring utility for checking pipeline task status without switching between server tabs, and shared it with the team.

OAuth2 · Zoho CRM API · Concurrent processing

Cross-Functional QA

Bridging Engineering and Product

Acted as the technical bridge between engineering and the non-technical product/sales teams who wrote the scraping criteria: reviewing prompt specifications for internal contradictions before they hit production, debugging output errors end to end, and auditing AI-generated outputs against ground truth. Authored the internal runbooks colleagues used for scraping and CRM operations.

Technical writing · Prompt review · Ground-truth auditing
03 Results, In Real Numbers

Every figure below is quantified against a specific fix, run, or log, not a general impression.

Duplicate scrape targets found & fixed across two production input lists46.2% / 55.4%
Apparent vs. actual unique failures, before/after the progress-tracking fix13,751 → 3,355
Failed rows classified by cause in one run, ~37% HTTP 403/429, ~29% DNS44,896 rows
Hallucination/schema-drift error lines traced to one root-cause contradiction2,976 lines
Recruitment vertical: raw rows deduplicated to unique sites, across 1,409 output parts22,460 → 13,847
Email-generation runtime for a 6-lead batch, after adding concurrency7.5 min → 75 sec
Structured-output validation run: valid JSON, all schema fields present, every time100%
Scoring tasks processed in production across two hardened verticals200,000+
04 Methods & Tools
Python GCP · Pub/Sub GCP · Firestore GCP · Cloud Storage GCP · Secret Manager GCP · Cloud Tasks OpenAI API · Structured Outputs Zoho CRM API · OAuth2 Git / GitHub Cursor (AI-assisted IDE) Concurrent Processing Statistical Evaluation Confusion Matrices Technical Documentation
05 How I Worked

AI-assisted, honestly. Cursor was my standing development tool from day one of the role. AI-assisted coding was the working method throughout, not an exception applied to a few files, I don't have file-by-file attribution of what the agent generated versus what I wrote by hand, and I'd rather say that plainly than imply more precision than I have.

Debugging as the day job. Most of the depth above came from tracing production failures back to a root cause, a contradiction in a prompt schema, a double-counted CSV row, an off-by-one in a progress tracker, rather than from designing a system from a blank page. The existing architecture (GCP-native, Pub/Sub-driven) was inherited; my job was to extend it reliably and fix what didn't hold up at scale.

What this page leaves out, deliberately. No prompts, scoring criteria, source code, client or target-company names, or business figures appear anywhere on this page, only the engineering problem, the method, and the measured outcome.