Agents built to replace the manual work, evaluated on cost, accuracy, and speed, not novelty.

Menu data needed to be extracted at scale, over 1,000 restaurant menus, for a downstream reporting dashboard. Menus arrive in wildly inconsistent formats (PDFs, photos, scans), and picking one OCR or LLM combination blind risked either poor accuracy or paying for more model than the task needed.

Landing.AI OCR handled initial document parsing, then I ran a comparative evaluation across GPT-4o, Claude Sonnet, and Gemini specifically on cost, accuracy, and speed, rather than defaulting to one model, and picked the best fit for structured extraction at this scale. I built fuzzy matching logic to reconcile extracted brand names against a large beverage database, since OCR output rarely matches a canonical brand name exactly. The pipeline runs through n8n into Supabase, and went through several iterations (V3, V4) as I debugged n8n workflow failures, Supabase schema issues, and Landing.AI timeout errors. I also built a custom dashboard so operations teams could see extraction accuracy, brand coverage, and menu trends across venues, and wrote client-facing documentation explaining the system in plain terms.

Over 1,000 restaurant menus processed, manual processing time cut by 85%, and 94% extraction accuracy in production. Presented at the AI Builders Mixer.

Classifying products under the correct Harmonized System tariff code across multiple regional customs regimes (EU, GCC, USA) was a manual lookup process, slow and error-prone, especially for categories like footwear, jewellery, and apparel, where small product differences change the correct code entirely.

I built an agent using Pinecone for retrieval and GPT-4.1 for classification, matching product line items to HS codes automatically. Getting accuracy right took real debugging across those three tricky categories, restructuring the pre-classification logic to weigh product name and fiber type together rather than either alone, and implementing 8-digit anchor extensions for more precise matches within a code family. I validated the whole approach with a dual-agent architecture tested against a 50-SKU sample from a luxury fashion brand, producing both client-facing accuracy reports and internal notes on where corrections were needed.

Cross-border trade classification that used to depend on manual lookup now runs through an agent, with a validated accuracy baseline from the 50-SKU test behind it.

Building an RFP from scratch, understanding requirements, drafting content, picking the right past project examples and candidate CVs, formatting into a client-ready document, was slow manual work spread across multiple people and steps.

I designed a multi-agent pipeline where the user holds a conversation with the system, plain text or an uploaded brief both work, rather than filling out a rigid form. An orchestrator routes the whole flow: an analyst agent builds requirements understanding from the conversation, an RFP builder drafts the proposal topic by topic against a set of RAG'd templates, a CV specialist pulls the best-fit candidates from a resume database, and a proposal builder compiles everything into a finished document. The user picks from four templates inside an Open WebUI interface, and the system generates the final output as a client-ready PowerPoint through code-driven templating rather than a static export.

A proposal that used to take a person building it from scratch now comes out of a structured conversation, with the multi-agent pipeline and UX architecture already working end to end.

Manually matching invoices against purchase orders and goods received notes (a 3-way match) was slow, and any automation attempt risked either missing real mismatches or flooding the team with false-positive exceptions, which is usually what kills adoption of automation like this.

I built the pipeline in Make.com and Azure AI Foundry: OCR pulls data from incoming invoices, then the system runs the 3-way match against purchase orders and goods received notes stored in SQL Server. The real work was the exception-handling logic, teaching the system to tell a genuine mismatch that needs a human from a minor variance it should resolve on its own, so the team wasn't drowning in exceptions that didn't actually need their attention.

Automated 3-way matching with intelligent exception routing and approval workflows, cutting manual review down to genuine exceptions only.

A monthly report was taking about two weeks to put together, manually pulled and formatted each cycle, making it the single biggest bottleneck in that client's reporting calendar.

I built an agent that generates the report directly, removing the manual pull-and-format cycle entirely rather than just speeding pieces of it up.

Report turnaround dropped from about two weeks to a few minutes, a reduction of over 99%.

A scheduling metric, tracked internally as NBOT, across a workforce of over 70,000 staff, was only visible after someone manually pulled a Power BI report, by which point the problem had often already had an operational impact.

I built a second agent for the same client that automates the scheduling activity report and surfaces where NBOT is running high in real time, so operations can catch and mitigate it as it's happening instead of waiting on a manual pull to flag it.

A problem that used to surface after the fact in a manual report now gets flagged as it's happening, across a workforce of 70,000+.

Every time an end user needed a slightly different cut of a report, it came back to the BI team as a one-off request, which ate a disproportionate amount of analyst time on small variations rather than new work.

I built a Streamlit application letting end users generate and adjust their own reports directly, so they can tweak the exact cut they need without a request routing through an analyst first.

End users get the exact cut of a report they need on their own, without waiting on analyst time, freeing the team up for higher-value work.