Research and working prototypes for voice AI in Uzbek, a language the major speech vendors barely support.

Why this is hard

English voice AI is a solved-ish problem with a dozen good vendors. Uzbek is not. Recognition accuracy is poor out of the box, the language switched between Latin and Cyrillic scripts within living memory, morphology is heavily agglutinative so word-level models fragment badly, and code-switching with Russian is normal in everyday speech. Off-the-shelf pipelines fall over on all four.

What I worked on

• Streaming STT evaluation across available providers and open models for Uzbek, measured on real conversational audio rather than clean read speech.
• TTS quality and intelligibility comparison, including handling of Latin/Cyrillic script variation and loanwords.
• Realtime latency optimisation for the full voice loop under conditions where the model is slower and less certain than it would be in English.
• Multilingual assistant design that degrades gracefully: detecting language and code-switching mid-utterance, and falling back sensibly instead of confidently transcribing nonsense.
• Dataset and evaluation workflow so quality claims are measured rather than asserted.

Why it matters

This is the same engineering problem every non-English market has. The techniques transfer directly to any low-resource or code-switching voice deployment.

Stack

Streaming STT, TTS, realtime audio pipelines, Python, evaluation tooling.

Live demo, GitHub and architecture notes: https://www.twine.net/signin

A multi-agent system that runs the entire WordPress-plugin business loop: what to build, whether it is worth building, building it, marketing it, and supporting it.

The idea

Most agent demos do one task. This one models an organisation. Specialised Claude and OpenAI agents each own a function and hand work to each other through a shared state store, the way departments do.

The agents

• Market research agent — gathers demand signals, competing plugins, pricing and gaps in existing offerings.
• Scoring agent — ranks candidate ideas against effort, competition and revenue potential, and kills the weak ones. This is the agent that stops the system from building whatever it thought of first.
• Development agent — turns the winning spec into plugin scaffolding, code and tests.
• Marketing agent — produces listing copy, positioning and launch material.
• Support agent — triages incoming issues against the plugin knowledge base.

The interesting engineering

• Orchestration over improvisation. Agents do not free-associate. Each has a bounded contract, typed inputs and outputs, and a defined place to escalate when it is out of its depth.
• Shared state, not shared context. Passing whole conversation histories between agents blows up cost and degrades reasoning. State is persisted and each agent is handed only what its task needs.
• Model routing. Cheaper models handle extraction and formatting; stronger models handle judgement calls like scoring and architecture.
• Cost and loop control. Step budgets and termination conditions, because an autonomous system without them will happily burn tokens forever.

Status: work in progress, developed openly.

Stack

Claude, OpenAI, Python, multi-agent orchestration, automation, PostgreSQL.

GitHub and architecture notes: https://www.twine.net/signin

A searchable directory of AI agent skills, built by a pipeline that finds, parses and enriches them automatically.

Live site: https://www.twine.net/signin

What it solves

Agent skills and tool definitions are scattered across public repositories in inconsistent formats. Finding a good one means reading a lot of README files. This project indexes them and makes them searchable with real metadata.

The pipeline

discover -> extract -> normalise -> PostgreSQL -> Gemini enrich -> API -> UI

• Discover: crawl public sources and queue candidate repositories, with de-duplication and change detection so the same source is not reprocessed for nothing.
• Extract: parse skill definition files across several formats and layouts, tolerating malformed input rather than crashing the batch.
• Normalise and store: map heterogeneous inputs into one PostgreSQL schema. This is the unglamorous data-mapping work that makes everything downstream possible.
• Enrich: Gemini generates summaries, categories and tags on top of the extracted content, with the raw source retained so enrichment can be re-run when the prompts improve.
• Serve: FastAPI JSON API behind a Next.js frontend with full-text and faceted search.

Engineering notes

Idempotent ingestion, incremental re-crawls, Dockerised workers, and structured LLM output validated against a schema before it ever reaches the database.

Stack

Next.js, FastAPI, PostgreSQL, Gemini, Docker, scheduled data pipeline.

Architecture notes: https://www.twine.net/signin

A paying-customer SaaS product I built and run end to end: altaudit.com

The problem

Missing or useless image alt text quietly breaks two things at once — WCAG accessibility compliance and image SEO. On a site with 10,000 media items, nobody is fixing that by hand.

What the product does

Alt Audit crawls a site or connects to a WordPress media library, runs each image through a vision model, and generates alt text that is actually descriptive and WCAG-appropriate rather than keyword spam. It audits what exists, flags what fails, bulk-processes the backlog, and reports findings inside the tools the customer already uses.

What I owned

Everything: problem discovery and scoping, product decisions about which workflows were worth building, the vision-to-text LLM pipeline and prompt design, the audit and bulk-processing engine, background job architecture for long-running crawls, a metered credit system, subscription billing, the public REST API, the WordPress integration, deployment and ongoing operation.

Engineering notes

• Bulk vision inference is queued and rate-limited per tenant so one large library cannot starve everyone else.
• Credits are metered at the image level with idempotency, so a retried job never double-charges.
• Output quality is evaluated against a held-out set rather than judged by vibes, because “the alt text looks fine” does not scale.

Stack

Laravel 12, Livewire, Gemini 2.5 vision, PostgreSQL/MySQL, queued background workers, Paddle billing, Laravel Sanctum REST API, WordPress plugin.

Live site: https://www.twine.net/signin · Architecture notes: https://www.twine.net/signin

Speak to it and it answers in about 1.3 seconds, end to end.

What it is

A real-time English voice agent: browser microphone in, streamed speech out, over a single WebSocket connection. Gemini Live handles speech recognition and reasoning; Azure neural TTS handles the voice. Measured round-trip latency sits around 1.3s from end of user speech to first audible syllable.

How the latency was won

• Nothing is buffered to completion. Audio streams in as chunks, model tokens stream out, and TTS synthesis starts on the first sentence boundary rather than waiting for the full response.
• The transport is one persistent WebSocket, not a sequence of HTTP requests — no repeated TLS handshakes or cold starts inside the conversational loop.
• Voice activity detection decides when the user has actually stopped talking instead of waiting on a fixed silence timeout, which is where most naive implementations lose half a second.
• Partial transcripts are used to warm the reasoning step before the utterance is finished.

Why it matters

Latency is the difference between a demo and something a person will actually talk to. Below roughly 1.5s a voice agent feels conversational; above 2.5s people start talking over it or hang up.

Stack

Gemini Live (STT + reasoning), Azure Neural TTS, WebSockets, FastAPI, Python, streaming audio pipeline.

Live demo, GitHub source and architecture: https://www.twine.net/signin

An AI receptionist that answers real phone calls, gets interrupted mid-sentence, and handles it.

What it does

A caller dials a normal phone number. Twilio media streams are bridged in real time to Gemini Live, which listens, reasons and speaks back. The agent books callbacks, opens tickets, answers questions from the business knowledge base, and writes a post-call summary into the backend.

The hard parts

• Barge-in. Humans interrupt. The agent has to stop talking mid-word, flush queued audio, re-open the input stream and re-anchor on what was actually said — not what it was about to say. Getting this wrong makes a voice agent unusable, and it is most of the engineering.
• Latency budget. Telephony audio in, model reasoning, speech out, all inside the window where a caller does not think the line dropped. That means streaming everything, never buffering a full turn, and cutting round trips.
• Telephony reality. 8kHz mu-law audio, codec conversion, dropped packets, DTMF, call transfer and hangup edge cases.
• Actions with consequences. Tool calls that create tickets or schedule callbacks are validated and logged, not fired blindly on a transcript the model may have misheard.

Stack

Twilio Media Streams, Gemini Live, ElevenLabs, WebSockets, FastAPI, Celery, PostgreSQL.

Live demo, write-up and architecture: https://www.twine.net/signin

Ask a neobank dataset a question in plain English. Get a safe read-only SQL query, a table, a chart and a written summary back.

The problem

Every fintech has the same bottleneck: business users have questions (“what is the fraud rate by MCC this quarter?”) and analysts have a queue. Handing an LLM write access to a production database is not an option.

What I built

• Text-to-SQL with a hard safety boundary. Generated SQL is constrained to read-only, validated against the schema before execution, and runs under a least-privilege role. No DDL, no writes, no unbounded scans.
• Schema-aware generation using vector search over table and column descriptions, so the model retrieves the right part of a wide schema instead of being handed everything at once.
• Results as tables, charts and prose — Gemini writes the narrative summary on top of the actual query result, not on top of its own guess, which keeps the numbers honest.
• Built against a synthetic neobank dataset (accounts, transactions, merchants, MCC codes, fraud labels) so the demo is public and no real customer data is involved.

Stack

Gemini, FastAPI, PostgreSQL, pgvector, Next.js, Docker.

Live demo, GitHub source and architecture notes: https://www.twine.net/signin

Three frontier models answer the same question in parallel, then critique each other and converge on a stronger answer.

The idea

Single-model answers are confidently wrong in ways that are hard to detect from the outside. MultiChat turns that into a measurable process: OpenAI, Claude and Gemini each produce an independent answer, then each model reviews the others, surfaces disagreements, and the system drives the exchange toward a consensus response with the disagreements made explicit.

What I built

• Parallel fan-out to three providers with normalised request/response handling, streaming, timeouts and per-provider error isolation, so one slow or failing vendor does not take the session down.
• A debate loop: answer -> cross-critique -> revision -> consensus, with the full transcript retained so a user can see why the final answer changed.
• End-to-end test coverage with Playwright against the real UI, not just unit tests on the orchestration layer.

Why it is interesting

It is a practical, cheap form of ensembling and self-critique for LLM output evaluation — useful when you need higher-confidence answers and an auditable reasoning trail rather than the fastest possible token.

Stack

OpenAI, Anthropic Claude and Google Gemini APIs, multi-agent orchestration, streaming, Playwright E2E tests, Python/FastAPI backend.

Live demo, GitHub source and architecture notes: https://www.twine.net/signin

Multi-agent AI system that investigates corporate finance fraud — with a human in the loop before anything consequential happens.

Live demo: https://www.twine.net/signin

The problem

Finance teams drown in transactions. Duplicate invoices, ghost vendors, split payments below approval thresholds and policy breaches hide in volume. Rules engines flag too much; a fully autonomous LLM agent is unacceptable when the action is “block this payment” or “escalate this vendor”.

What I built

A coordinator agent receives a case and dispatches specialist agents (duplicate detection, vendor legitimacy, policy compliance, risk scoring). Each specialist retrieves evidence via RAG over policy documents and transaction history, then reports back with citations. Findings are risk-scored, and anything actionable stops at a human approval gate. Every step is written to an immutable audit log, and the case is exported as a report.

Flow: request → coordinator → specialists → RAG evidence → risk analysis → human approval → audit log → report export

Why it matters

The design point was controllability, not autonomy. Approval gates, full audit trails and cited evidence are what make an AI agent deployable in a regulated finance function.

Stack

Qwen and Gemini models, multi-agent orchestration, RAG over policy and transaction data, PostgreSQL, FastAPI, report generation (PDF), audit logging.

Links

• Live demo: https://www.twine.net/signin
• Devpost submission and GitHub source available
• Architecture write-up: https://www.twine.net/signin

Solo AI engineering project, submitted to a public hackathon.