The problem

Keeping track of declined refunds meant collecting the records from the portals by hand, summarizing them for the team and writing a status email to each customer.

What I built

An agentic system on n8n that owns the whole process. The agent has a tool for every step, and the process is triggered by chatting with it, so an operator can ask it to run the full flow or only one part of it and the agent decides which tools to call.

How it works

1. Pulls the declined-refund data from the portals.
2. Stores the records in BigQuery, where they are available for reporting.
3. Posts a summary of the data to Slack for the team.
4. Emails each customer the current status of their refund.

Outcome

One chat message replaces a manual chain of copying, summarizing and follow-up emails, and the data lands in BigQuery as part of the same run, so reporting needs no extra work.

The problem

HR had to watch contract end dates, chase every manager for a renewal decision and then fill each renewal contract by hand.

What I built

A chatbot-style agent that HR triggers on request. It has access to the BambooHR API, email, the Google Sheets that hold the managers' decisions and the employee data, and the contract template.

How it works

1. Queries the BambooHR API for employees whose contracts end within the next 60 days.
2. For each of them, emails the employee's manager a form to record the decision: renew or not.
3. Reads the managers' responses from a Google Sheet.
4. For every renewal, pulls the employee's data from a second Google Sheet and fills the contract template with it, producing the renewal contract.

Outcome

Handles about 30 contracts per quarter and saves HR roughly 10 hours a month.

The problem

Every pull request needed a first pass before a human reviewer could get to it: what changed, where the risks are and what to comment on.

What I built

A set of n8n workflows that listen for pull request creation on GitHub and run an LLM review automatically.

How it works

1. A workflow is triggered when a pull request is created and fetches its diff.
2. The diff is passed to three LLMs that analyze it, summarize the change, look for bugs and write review comments.
3. The outputs are consolidated and posted back on the pull request in GitHub.

Outcome

Reviewers open a pull request that already carries a summary, a list of suspected bugs and draft comments, and can spend their time on judgment instead of reading every line first.

The problem

Technical documentation in Confluence drifted out of date as soon as the code changed.

What I built

A chatbot with access to GitHub that keeps the Confluence documentation in sync with the repository. The setup assumes one Confluence page per module in the repo.

How it works

1. When a pull request is created, the agent reads the change and identifies the module it belongs to.
2. It updates the Confluence page related to that module so the documentation reflects the new code.
3. Because it is a chatbot, the team can also talk to it directly to ask for documentation updates.

The problem

In a water desalination plant, the times at which valves open and close decide how much chemical treatment is consumed and what the operation costs. The R&D question was: when exactly should the valves open and close, and when should the chemical treatment change, to minimize cost and chemical use while keeping the water output high?

What I built

A reinforcement learning planning system that learns that schedule. I implemented the approach recommended in a published deep reinforcement learning study on this problem (reference paper).

How it works

1. Plant operation is treated as a sequential decision problem: at each step the agent decides which valves to open or close and which chemical treatment to apply.
2. The reward favors water output and penalizes operating cost and chemical consumption, so the learned policy trades the two off.
3. The agent learns by trial and error: it tries schedules, observes the resulting cost, chemical use and output, and improves its policy over time.

The problem

A bank's core system was written in COBOL across multiple applications. Software architects needed to understand that legacy codebase, ask questions about it and find related scripts without reading everything line by line.

What I built

A Retrieval-Augmented Generation system over the whole codebase with two main applications: a chatbot that answers questions about the code in natural language, and similarity search that finds the scripts related to a given one. The project also produced auto-generated system documentation and an MVP re-implementation in Java and Python.

How it works

1. Context chunking: each function and code block becomes its own chunk, and an LLM pass captures how every chunk relates to the rest of the script, so a retrieved chunk carries its context instead of being an isolated snippet.
2. Code embeddings: the chunks are embedded with a code-specific embedding model rather than a general text embedder, so retrieval follows code semantics.
3. Vector store: embeddings are indexed in FAISS, Meta's vector search library, deployed on the company's own server, with a graph database holding the relationships between code units.
4. Applications: the chatbot retrieves the relevant chunks and answers the architect's question, and the similarity service compares scripts to surface related code.

The problem

Test cases are usually written after the code exists. The goal here was to generate them before implementation, from the business documents alone (SRS and BRD), which makes it closed-box testing.

What I built

A multi-stage pipeline that combines named entity recognition, several RAG systems and LLM modules, each responsible for one step, plus an evaluation stage that checks the result against the documents.

How it works

1. Variable extraction: NER identifies the variables mentioned in the SRS and BRD.
2. Constraint extraction: a RAG system reads the explanations around each variable and derives its constraints, such as the number of characters, allowed ranges and formats.
3. Test path generation: a second RAG system takes the variables, constraints and documents and generates test paths, each a graph of steps. Positive paths lead to a successful outcome; negative paths violate a constraint and lead to a failure.
4. Data generation: an LLM takes the variables and their constraints and generates positive and negative data for each path, turning paths into concrete test cases.
5. Coverage evaluation: a separate LLM-based evaluator compares the generated test cases with the business documents to make sure coverage reaches at least 95%.
6. After implementation: the framework also generates unit test code for the system's modules.

• An agent that writes a complete blog post from a single request: the user enters the title, the number of words and, optionally, the sources the post should be based on.
• The sources are indexed in ChromaDB and FAISS so the draft is grounded in them (retrieval-augmented generation), and LangChain orchestrates the retrieval and the OpenAI generation steps.
• A Streamlit interface makes it usable by non-technical writers, turning hours of research and drafting into minutes.

• Diacritics are the short vowels that are spoken but usually omitted from written Arabic, because native speakers infer them. The same word can have different meanings and pronunciations depending on how it is diacritized, so restoring diacritics removes ambiguity for text-to-speech, machine translation and search.
• We treated it as character-level sequence labeling and built two models: a recurrent network (Bi-LSTM) with an embedding layer, and the CBHG architecture (a 1-D convolution bank, highway network and bidirectional GRU).
• Full data processing, training details and results are in the repository.

• A vector index that returns the most relevant vectors for an input query: the retrieval layer that RAG systems depend on.
• The challenge was to optimize both memory footprint and query time. We used IVF (inverted file index) partitioning to narrow the search space, LSH (locality-sensitive hashing) for approximate nearest neighbors, and fully vectorized operations.

• An educational platform that teaches the machine learning pipeline to kids aged 8 to 18 through games: they create their own dataset, train a model, validate and test it, and then play a game that uses the model, so they see how it behaves.
• In the image classification game, children capture or import images, train a classifier and play against it.
• Built with Unity and C# for the games and Python for the machine learning, by a team working with Agile practices.

• A binary classification task on the Santander dataset: predict whether a customer will make a specific transaction in the future from historical data, regardless of the amount.
• After data processing and analysis we compared five models: Linear Regression, AdaBoost, SVM, Random Forest and XGBoost.
• Data and model analysis are documented in the repository README and report.

• Given the U.S. Small Business Administration loan application dataset, build a model that decides whether an application should be approved or denied.
• Steps: preprocessing with Spark, exploratory data analysis, association rules between features (visualized), further preprocessing based on those findings, KNN with map-reduce, and finally Logistic Regression, Random Forest, GBT and SVM models.
• Data and model analysis are documented in the repository README and report.

• A model that recognizes the number a hand is showing. The hardest part was the noisy dataset, so the pipeline starts with preprocessing that extracts the hand from the image as accurately as possible.
• Features: HOG and LBP, reduced with PCA. Classifier: SVM.
• My role: hand extraction with GMM and K-means, and implementing the LBP algorithm in the feature extraction module.

• Real-time hand detection that reads digits and arithmetic operators shown to the camera and computes the result.
• Image processing feeds an SVM classifier that reached 90% accuracy; threading keeps the detection responsive.
• My role: image enhancement and accuracy evaluation.

• A color detector for images and videos built with OpenCV and Pandas.

• A search engine built from three components: a crawler, an indexer and a ranker, with a web interface on top.
• My role: the indexer, the preprocessing step before data is stored in the database, and part of the website.
• Our team took first place among all teams for the performance of the code and how it manages resources.

• Developed the front end of an Android mobile application with Dart and Flutter.
• A team of twenty members with backend, cross-platform and DevOps sub-teams; we used Git to organize changes and assign tasks.

• An online store that loads products from an API and lets the user add and remove them from a cart to buy them.

• A Windows application that handles multiple users and their privileges, patient appointments and medical history tracking.
• My role: part of the database schema, the backend, and the doctor, nurse and patient screens.

• An application for designing and simulating logic circuits, with save, copy, cut, paste, undo and redo.
• Built around object-oriented design: polymorphism, inheritance, abstraction and encapsulation.

• Built with plain HTML and CSS and hosted on GitHub Pages, using flexbox, grid and media queries for a responsive, mobile-friendly layout.