Four systems that do the work so people don't have to.

The problem

Natural phone-style conversation with an AI needs sub-second latency. Most stacks feel like walkie-talkies.

What I built

Low-latency voice loop on Pipecat + WebRTC with Groq Whisper for speech recognition and LLaMA 3.1 for reasoning. Intelligent interruption handling, dynamic knowledge-base lookup, domain-tuned recognition and failover when providers degrade.

The hard part

A voice conversation is only as good as its slowest moment. Transcription, reasoning and speech each add delay, and callers notice any pause that sounds like lag rather than thinking. On top of that, people interrupt, speak over the assistant and use words general speech recognition gets wrong, while every external provider will eventually be slow or unavailable in the middle of a call.

Decisions that made it work

• Treat latency as a budget: every stage streams into the next, so the caller hears the first words of a reply while the rest is still being generated.
• Keep listening while speaking, stop instantly on a real interruption, and trim the conversation history to what the caller actually heard.
• Answer from a knowledge base instead of the model's memory, with short, specific facts that suit spoken answers.
• Give speech recognition the domain vocabulary that matters, such as product names and reference codes.
• Treat every provider as replaceable, with timeouts set by the latency budget and a fallback for each stage.

How a run goes

1. 1Caller speaks
2. 2Whisper transcribes
3. 3LLaMA 3.1 decides
4. 4ElevenLabs replies

Where this fits

Voice agents fit conversations people already expect to have by phone and that follow a predictable pattern: booking and rescheduling appointments, answering routine questions, qualifying inbound calls and routing callers to the right person. They are a poor fit where a mistake is expensive and hard to correct by voice, or where the caller needs to see something. The right first project is a frequent, well-understood call that is currently handled by someone reading from a script.

The problem

Inbound leads sat in a shared inbox; categorizing, assigning, researching and replying took hours of manual work.

What I built

Agent that ingests inbound email via Microsoft Graph, categorizes each message, researches the company, generates a personalized reply and creates the Outlook draft. Leads are assigned round-robin by region and seniority level, stored in PostgreSQL and synced to Odoo, with responses tracked.

The hard part

At more than 100 inbound emails a day, speed is only half the problem. Every message has to be understood, the real leads separated from everything else, each one researched well enough to reply personally, and then owned by the right person, all without anyone copying data between Outlook, a database and the CRM.

Decisions that made it work

• Split the work into small, testable steps (categorize, extract, research, draft, assign, record) instead of one giant prompt.
• Draft replies in Outlook rather than sending them, so a person stays accountable and trust grows with every accepted draft.
• Assign leads round-robin within region and seniority level, so workload stays even and every lead has an owner the moment it arrives.
• Use PostgreSQL as the system of record and reflect every lead and assignment in Odoo, where the sales team already works.
• Forbid invention: replies may only use facts the research step actually found.

How a run goes

1. 1Email arrives
2. 2Categorized
3. 3Company researched
4. 4Reply drafted in Outlook
5. 5Assigned by region and seniority
6. 6Synced to Odoo

Where this fits

Any team that receives enquiries by email and wants to answer them faster and more consistently: service firms, B2B software companies, agencies and consultancies. It is especially valuable when leads arrive in bursts, when the same questions come up repeatedly, when leads need to go to different people by region or seniority, and when the CRM should stay current without anyone updating it by hand.

The problem

Invoices, credit and debit notes across multiple business tenants, all requiring Malaysian LHDN e-Invoice compliance.

What I built

Enterprise ETL platform: automated PDF/Excel extraction, JSON transformation, schema validation and regulatory submission, isolated per tenant, authenticated via OAuth 2.0.

The hard part

Supplier documents arrive in every possible layout, as PDFs and spreadsheets, across several separate businesses. Every one has to be read correctly, checked against rules that cannot be bent, submitted in the right format, and traceable afterwards, while one tenant's problems must never affect another's.

Decisions that made it work

• Start from the mailbox through Microsoft Graph, so nobody has to change how documents arrive.
• Separate extraction from validation: extraction can be flexible, validation is strict and deterministic.
• Reconcile the numbers (line items, tax and totals) and validate the final schema before anything is submitted.
• Make every step idempotent, so restarts and duplicate emails never produce duplicate submissions.
• Isolate tenants completely, including data, credentials, configuration and failures, and keep an audit trail in PostgreSQL.

How a run goes

1. 1PDF or Excel in
2. 2Fields extracted
3. 3Schema validated
4. 4JSON transformed
5. 5Filed with LHDN

Where this fits

Any business that receives a steady flow of invoices, credit notes, debit notes or similar documents as PDFs or spreadsheets and has someone re-typing them. The signals are volume (dozens of documents a week or more), repetition (the same suppliers and layouts again and again) and pain (rejections, backlogs, or a person whose week disappears into data entry). The same pattern applies to purchase orders, delivery notes and reports.

The problem

Enterprise content operations: generation is easy, ranking content with consistent quality and publishing discipline is not.

What I built

Researches a given or trending topic, runs keyword research, and writes to EEAT standards through prompt-engineered generation gated by deterministic validation, then assembles, publishes and tracks everything automatically. Runs on an enterprise website I built that scores 100 for performance.

The hard part

Generating text is easy; getting it to rank and convert is not. Search engines are good at recognising fluent, empty content, and readers leave it immediately. The engine had to pick topics people actually search for, write with real expertise, meet a consistent quality bar and publish on schedule without anyone babysitting it.

Decisions that made it work

• Start from research: a given or trending topic, plus keyword research to target specific, winnable searches.
• Write every article to a brief built around search intent and Google's EEAT guidelines.
• Gate every draft with deterministic checks for structure, coverage, length and forbidden claims before it can be published.
• Automate assembly, publishing and tracking, so output is steady and the content calendar always matches reality.
• Run it on a fast enterprise website (100 for performance) so good content is not held back by a slow page.

How a run goes

1. 1Topic and keyword research
2. 2EEAT brief
3. 3Draft generated
4. 4Quality gate
5. 5Assembled and published
6. 6Tracked

Where this fits

Businesses that depend on being found: service companies, B2B firms and anyone whose customers start with a search. It works best alongside a fast website and a clear offer, because rankings bring visitors but the page they land on has to turn them into enquiries. The engine suits teams that need steady, high-quality output without hiring a full content department.