Building AI that works in the real world.

01 · Problem

Project knowledge was spread across Teams and SharePoint documents. Finding scope, technologies, project context, or similar past work required manually reviewing multiple files, making knowledge reuse slow.

02 · Solution & architecture

Built an agent-based wiki pipeline inspired by Andrej Karpathy’s LLM Wiki idea: turn source documents into structured entities and persistent Markdown knowledge pages, then make them discoverable through semantic retrieval.

• Entity extraction: identify projects, clients, technology stacks, scope, and other attributes.
• Wiki management: create or update Markdown pages and maintain the schema as new entity types appear.
• Semantic retrieval: store wiki Markdown in AWS S3 and embeddings in PostgreSQL for similar-project discovery.
• Human-in-the-loop: include a human review checkpoint for ambiguous or low-confidence extracted details and proposed knowledge updates before they are accepted.

Reference: Inspired by Andrej Karpathy’s “LLM Wiki” concept, which treats a knowledge base as a maintained, evolving collection of linked notes rather than a one-off document summary.

03 · My role

• Designed and implemented the agentic workflow for transforming source documents into structured wiki knowledge.
• Built the LangChain orchestration flow and connected document processing, entity extraction, similarity detection, and wiki management tools.
• Implemented S3 storage for Markdown pages and PostgreSQL embeddings for semantic search.
• Worked on dynamic entity/schema management and integrated Claude Sonnet 4.5 for document understanding and extraction.
• Evaluated extraction quality and identified agent execution cost as an optimization area.

04 · Results

Created a searchable organizational knowledge base, enabled discovery of similar projects, and reduced time spent locating previous project documentation by 90%. The work also identified cost-efficiency opportunities for production-scale use.

05 · Tech stack

Python · LangChain · AgentCore · Claude Sonnet 4.5 · AWS S3 · PostgreSQL · Embeddings · RAG / vector search · Markdown

01 · Problem

Legal teams needed a more efficient way to identify discrepancies between vendor/customer contracts and internal company policies.

02 · Solution & architecture

Processed documents submitted through a chatbot/API, chunked the contract text, retrieved relevant policy passages from PostgreSQL using semantic similarity, and sent the contract chunks plus retrieved context to GPT for analysis.

Potential discrepancies were shown directly in the Word document by striking through flagged text and adding suggested corrections as comments for legal review.

03 · My role

• Developed the document-processing workflow, chunking, similarity search, and LLM analysis.
• Implemented the RAG pipeline over company policy content stored in PostgreSQL.
• Integrated GPT-based clause comparison and Microsoft Word Track Changes/comment automation.
• Helped connect the workflow to chatbot/API-based document submission.

04 · Results

Delivered a working POC that helped surface policy deviations faster and placed proposed corrections in the document for legal teams to review, reducing manual review effort.

05 · Tech stack

Python · GPT · RAG · LangChain · PostgreSQL / vector search · FastAPI / REST API · NLP · Microsoft Word automation

01 · Problem

Sales executives and technical leads manually prepared SOW and LOE documents for customer engagements. This involved gathering requirements, scope, effort, and cost details and repeatedly formatting content.

02 · Solution & architecture

Connected GPT to API tools that retrieve relevant project/customer context through RAG, store generated content in Excel, and populate standardized Word templates dynamically with Jinja2.

Human review remains important before generated commercial or scope documents are finalized.

03 · My role

• Developed/implemented API-based tools for RAG retrieval, Excel content storage, and Word template population.
• Integrated GPT with backend tools so retrieved information could ground generated drafts.
• Worked on Jinja2 template binding and the structured document-generation workflow.

04 · Results

Reduced drafting and formatting time from approximately 1–2 days to about one hour, an estimated 85% reduction in manual effort. Standardized output and reduced repetitive copy-paste work.

05 · Tech stack

GPT · RAG · Python · REST APIs · Database retrieval · Jinja2 · Microsoft Word · Microsoft Excel

01 · Problem

Moving legacy OpenText Exstream templates to Precisely RapidCX can be complex and manual, particularly when templates vary in structure and complexity.

02 · Solution & architecture

Parsed and analyzed source XML, identified reusable patterns, and used prompt-engineered LLM workflows to generate corresponding target structures. Tested across template complexity levels and compared outputs against originals.

03 · My role

• Analyzed template structure and identified reusable conversion patterns.
• Designed and refined prompts based on conversion test results.
• Compared Claude and Amazon Nova Pro outputs.
• Evaluated accuracy, visual fidelity, functional equivalence, and limitations across complexity levels.

04 · Results

Demonstrated technical feasibility, documented conversion patterns and failure cases, and established evaluation considerations. The POC targeted 85% conversion coverage with minimal manual adjustments; this is a target, not a claimed measured result.

05 · Tech stack

Generative AI / LLMs · Prompt engineering · XML parsing · Claude · Amazon Nova Pro · AWS · RAG / document knowledge base