Venkatesh Sridharan

Case study · PrivCo

AI Company-Profile Enrichment Workflow

I led and built an n8n workflow that turns raw vendor company records into structured, publishable company profiles. Each record arrives with a name, headquarters, and several overlapping descriptions from different sources; detailed prompts I wrote guide the LLM through three jobs per company.

1. Classify the company into PICS (PrivCo industry keywords) and NAICS.
2. Describe it with a single sanitized, verified company description.
3. Tag it with keywords that power search and group similar companies together for comparison and competitor analysis, which is the core of PrivCo's product.

Design decisions

• One step per task, not one large prompt. Classification, description writing and keyword tagging produce different outputs and fail in different ways. Separate steps keep each prompt short and focused, and each one can be tuned and retried without discarding good output from the others.
• A closed taxonomy. The model chooses from the fixed PICS list, supplied as a retrieval (RAG) document, and the NAICS list. Anything outside those lists is rejected.
• Structured output. Every step returns JSON, which is validated before it moves on.

Keeping it accurate

• Grounding rule. The prompts restrict the model to facts present in the input record.
• Description rules. No marketing language, no person names, no first-person “we” phrasing, and the company name must be present.
• Rule-based routing. Python rule checks run on the output. Records that pass every check are auto-accepted; the rest go to analysts with the reason attached.
• Thin inputs are not guessed at. Records with empty or too little source text are skipped and handled manually later.

Running at scale

• Batching and retries. Companies are processed in batches of 10k, sometimes 40–50k, with n8n retrying failed calls.
• Resumable runs. Output is written as the run progresses, so an API limit or an unexpected failure loses nothing. On restart, input IDs are compared against the IDs already processed and the run continues where it stopped.
• A separate processed-ID list. Re-opening the output files to find finished companies was slow in n8n, so I keep the processed IDs in their own small file, which makes the restart check fast.
• Failure logs. Detailed, timestamped log files are written to AWS S3, recording which records failed and why.

Results

• 2–3 days per batch including analyst verification, where 10k companies took about a month by hand
• 88% of classifications accepted by analysts without edits
• 40–50k companies in the largest batches

What I'd build next

Analyst verification is now the slowest part of a batch, and routing today relies on basic rules. Stronger automated checks would send fewer records to analysts.

• Grounding check. Extract the numbers, places and names from each description and flag any that do not appear in the source record.
• Classification confidence. Classify each company twice and cross-check PICS against NAICS; disagreement marks the record as uncertain.
• Golden set. Keep a few hundred analyst-approved companies to test every prompt change against before it runs on a real batch.

• n8n
• Gemini LLM
• Python
• Prompt design
• RAG
• AWS S3

Case study · PrivCo

AI QA Pipeline

I built an automated data-quality pipeline to take routine checking off QA analysts. Given a list of companies and the values PrivCo already holds for them, an AI research agent checks each company on the web, compares what it finds with the stored record, and decides which updates are safe to apply and which need a person.

1. Resolve the company's website: normalize the URL, try likely variants, and use the first one that responds.
2. Research the company with an AI agent that searches the web and reads pages for firmographics, financials and corporate events, returning strict JSON with a confidence rating on every field.
3. Compare the findings with the existing record after parsing them into typed values, so revenue figures, headcount ranges and years line up.
4. Triage every finding into one of five buckets: auto-apply, no action, verify before update, human review, or analyst-only.
5. Report the results as JSON for the import process and as one self-contained HTML report per company for analysts.

Design decisions

• Confidence decides the route. Only a high-confidence value for a field PrivCo has no data on is applied automatically. Anything that conflicts with existing data goes to a person, with the reason attached.
• Tolerance, not exact matching. Numbers within 5% of the stored value count as a match, so small differences between sources do not create review work.
• One contract, two model providers. The research step sits behind a single function interface, with one implementation on the Claude Agent SDK and one on Gemini using search grounding and function calling. Every other module is shared.
• A controlled field vocabulary. Only known fields can be imported. Anything else, including corporate events such as a missed acquisition, is flagged for an analyst and never written automatically.

Cost and failure handling

• Hard budgets per company. The Gemini path stops at 8 tool calls or $0.06 per company, and the Claude path at 180 seconds.
• Failing safe. If a site is unreachable or the agent times out, the record is marked as needing a human; nothing is guessed.
• Built to hand over. I documented the output contract, the triage rules and how to extend each stage, so another engineer could pick the pipeline up.

• Python
• Claude Agent SDK
• Gemini API
• Search grounding
• Function calling
• httpx