bala@ciatel-corp

AI Business Consultant & Automation Expert · Co-founder, Ciatel Corp Ltd

Bala Pothabattula

I build AI agents and data systems for UK small businesses — voice receptionists, daily research pipelines, internal tools. Through Ciatel Corp Ltd, the consultancy I co-founded.

Now

What I'm working on right now

Right now I'm running two live AI products with Ciatel Corp Ltd for UK independent service businesses — dental clinics, salons, laser-treatment centres, driving instructors, dog-grooming centres and vets. ARNO AI Receptionist answers inbound calls 24/7 and books straight into the calendar. ARNO WhatsApp Agent takes orders and bookings over WhatsApp, recognises returning customers, and sends the business's own QR for payment — no app, no login, owner controls everything by message. Both are multi-tenant and live.

I'm also running a daily research system that listens to what UK business owners are quietly complaining about online — so I know what's actually worth building next.

Alongside client work, I'm deep in building an internal AI system that runs my business day-to-day — scanning the market every morning for where real AI demand is moving, surfacing which opportunities are worth my time and which aren't, and sharpening my thinking before high-stakes conversations. The kind of strategic intelligence that enterprise firms get from a full research team, running 24/7 on a one-person operation. It's the most ambitious thing I've built for myself, and it's changing how fast I move.

I haven't taken on legal, healthcare, or finance compliance work yet — that needs a specialist partner I haven't sourced. Everything else is in scope.

Work

Selected work

Seven systems I've built and shipped. Honest about what's live, what's demo-ready, what's on the roadmap, and what's deliberately out of scope.

01

Steward — AI Email Assistant

Reads a law firm's inbox, triages every email and drafts replies in the lawyer's own voice — nothing sends without a human

What it is

Live and in production for a Manchester personal-injury law firm. Steward connects to the firm's Outlook mailbox, reads incoming mail every few minutes, and sorts each email into needs-a-reply, for-information, or noise. When a reply is needed it drafts one in the lawyer's own voice and saves it straight to the Outlook drafts folder — it never sends anything itself. It also reads PDF and Word attachments and pulls out the deadlines and actions buried inside them. A dashboard shows what it handled each week, with a one-click export for the firm's records.

Why I built it

A lawyer running a busy practice loses hours a day to email — sorting what matters, re-reading attachments, drafting the same kinds of replies over and over. That's exactly the mechanical reading-and-writing AI is now good enough to do. The non-negotiable in a regulated practice is that a human stays in control — so Steward drafts and the lawyer sends. I built it to take the triage and the first draft off the lawyer's plate without ever taking the decision.

Steward email assistant architecture: Outlook mailbox → n8n orchestration → Claude triage and drafting → Outlook drafts (no auto-send) → Supabase audit and weekly dashboard Outlook mailbox Microsoft Graph · new mail every 5 min n8n orchestration per-tenant sweep · token decrypt · Hetzner Triage + drafting Haiku triages → Sonnet drafts in your voice Python reads PDF / Word attachments Saved to Outlook drafts no send permission — lawyer reviews edits and sends manually Supabase + dashboard audit log · multi-tenant RLS weekly activity view · CSV export

Architecture · simplified

What makes it work

  • Nothing sends automatically — the system has no permission to send mail at all. Every reply is left as a draft for the lawyer to review, edit and send. That's a hard guardrail for a regulated practice, not a setting.
  • Two AI models split the work by cost — a fast, cheap one triages every email; a more capable one writes the drafts that actually need care.
  • It drafts in the lawyer's own voice, learned from samples of their real writing — so a draft reads like them, not like a chatbot.
  • Every firm's data is isolated by row-level security and the mailbox token is encrypted at rest — built multi-tenant so more firms can be added without ever mixing data.
  • Every email it touches is logged with a full audit trail and exportable to CSV — so the firm can show exactly what the assistant did and when.

What it doesn't do yet

  • A feedback loop — thumbs up/down on each decision so it learns the lawyer's preferences over time — is specced and partly built, not yet live.
  • Attachment reading covers normal PDFs and Word files; scanned documents are flagged but not yet read (OCR is a later phase).
  • VIP-sender alerts and a first-run pass over older email are designed but not switched on yet.
Stack n8n (self-hosted) · Microsoft Graph API · Anthropic Claude (Haiku 4.5 triage + Sonnet 4.6 drafting) · Python (FastAPI · pdfplumber) · Supabase (pgvector · multi-tenant RLS) · React + Vite on Vercel · Hetzner
02

JourneyWise — WhatsApp Hotel Concierge

AI agent that finds, quotes and books UAE hotels entirely over WhatsApp — one all-in price, no haggling

What it is

Built and demo-ready — an AI concierge that handles the whole hotel-booking conversation over WhatsApp for a UAE travel company. A customer messages, says where and when they want to stay and for how many, and the agent searches availability, quotes one transparent all-in price, takes payment by link and sends the booking voucher — all in the chat, no app and no login. A built-in admin dashboard lets the travel company watch every conversation live, take over any chat, and adjust pricing on the fly. The conversation engine is production-grade; the supplier and payment connections currently run on demo adapters until the client's live accounts are switched on.

Why I built it

A UAE travel company wanted to capture customers at the moment they're ready to book — on WhatsApp, where their customers already are — without anyone waiting for a human to compare hotels and quote a price. The hard part isn't the chat; it's getting an AI to quote real prices reliably, never invent a hotel, never leak the company's margin, and hand off cleanly when a person is genuinely needed. I built the full loop end-to-end to prove it works before wiring it to live supplier and payment accounts.

JourneyWise WhatsApp concierge architecture: customer message → Next.js webhook → Claude Sonnet 4.6 agent → tool dispatch with supplier and payment adapters → store and live admin dashboard Customer message WhatsApp or web chat Next.js webhook /whatsapp · /chat on Render Claude Sonnet 4.6 agent tool-calling loop · 50-rule guardrail never invents a hotel or leaks margin Tool dispatch search · quote · discount · pay-link → escalate to human supplier + payment adapters (swappable) Store + admin dashboard conversations · bookings · audit log live SSE feed · human take-over

Architecture · simplified

What makes it work

  • It only quotes hotels and prices it actually retrieved — it can never invent a property or a rate, and it never reveals the company's margin, even when a customer asks directly.
  • A strict 50-rule guardrail keeps it on task: it promises a price only after confirming dates and room, resists prompt-injection attempts, and escalates complaints, refunds and anything high-stakes to a human.
  • Discounts are decided by the server, not the AI — the agent can only offer a reduction within a margin floor the business sets, so it can never give away more than the business allows.
  • Supplier and payment connections sit behind swappable adapters — the client's live Rezlive and Nomod accounts drop in without touching the conversation engine.
  • A live admin dashboard shows every conversation, flags escalations and abandoned payments, and lets a colleague join and take over any chat from the agent.

What it doesn't do yet

  • Live supplier and payment connections — it runs on demo hotel inventory and simulated payment links today; swapping in the client's real Rezlive and Nomod accounts is the next step.
  • WhatsApp delivery is wired to the Meta Cloud API but not yet tested on a live number — that switches on once the client's WhatsApp Business account is verified.
  • Conversations are held in memory for the demo; moving them to a shared database is needed before running across more than one server instance.
  • Multi-item carts and a gentle nudge for customers who start but don't finish a booking are planned, not built.
Stack Next.js 16 · React 19 · Anthropic Claude (Sonnet 4.6) · Meta WhatsApp Cloud API · Zod tool-calling · Server-Sent Events admin dashboard · Render
03

ARNO AI Receptionist

AI voice receptionist that answers every call 24/7 and books straight into the calendar

What it is

Live and in production — a multi-tenant AI voice receptionist built for independent service businesses. Dental clinics, salons, laser-treatment centres, driving instructors, dog-grooming centres and vets each get their own dedicated setup: your callers ring your number, talk to your AI, and get booked straight into your calendar. Every business is fully isolated — no shared infrastructure, no crossed customer data.

Why I built it

Service businesses lose around 15% of their bookings to unanswered calls — calls that come in after hours, during a treatment, or while the front desk is with a client. For a 20-booking-a-week salon at £50 average, that's around £150 of lost revenue every week. I wanted to know if today's voice AI was good enough to capture those calls without sounding like a robot — and trusted enough to run on a live business's phone line.

Arno 2.0 architecture: PSTN call → Twilio webhook → real-time Claude agent → action handlers → Supabase logging Inbound PSTN call Customer dials business number Twilio Voice webhook /incoming-call → ConversationRelay Real-time Claude agent Haiku 4.5 · WebSocket /media-stream ElevenLabs voice streamed to caller Action handlers → Google Calendar (book / cancel) → Twilio SMS (confirmation) → Warm transfer to human Supabase logging call_logs · post-call summary Sonnet 4.6 generates transcript notes

Architecture · simplified

What makes it work

  • Two AI models work together — a fast one runs the live conversation in real time, a more thoughtful one writes a plain-English summary of the call for the owner afterwards.
  • It recognises regular customers by phone number and greets them by name.
  • It checks the calendar live before quoting any slot — so it never books a time that conflicts with an existing appointment.
  • Allergy questions, complaints, large-ticket enquiries, and anything the AI isn't confident about transfer straight to the owner — it doesn't pretend to handle things that need a human.
  • Every tenant runs in complete isolation — separate RLS context, separate conversation history, separate per-tenant cost caps. One business's calls never touch another.

What it doesn't do yet

  • Sharper flagging of urgent items at the top of the morning call summary — currently all items carry equal weight.
  • Broader calendar provider support — Google Calendar and Outlook covered; iCal sync is on the roadmap.
  • Outbound appointment reminders — the infrastructure is in place; it's a configuration step per tenant.
Stack Fastify · Twilio Voice · Anthropic Claude (Haiku 4.5 + Sonnet 4.6) · ElevenLabs Flash v2.5 · Supabase (multi-tenant RLS, pg_cron) · Render
04

ARNO WhatsApp Agent

AI agent that takes orders and bookings over WhatsApp and sends the business's own QR for payment

What it is

Live and in production — a multi-tenant AI agent that handles orders and bookings over WhatsApp for the same verticals as the voice receptionist: salons, dental clinics, driving instructors, dog-grooming centres, laser-treatment centres and vets. Customers message the business's own WhatsApp number; the AI handles the full conversation, recognises returning customers, and sends the business's QR code for payment at the end. No app, no login, no web dashboard — the owner controls everything by WhatsApp command. A daily 8 a.m. brief — today's orders, tomorrow's prep, anything needing attention — arrives on the owner's WhatsApp and email every morning.

Why I built it

Most of the businesses I work with already have more messages than they can answer. Their customers prefer to WhatsApp; the business can't afford to miss the booking. The gap between 'customer wants to message' and 'business wants to capture the order' is exactly where a well-built AI agent should sit. I built this so the same multi-tenant infrastructure I run for voice could work in the channel most UK SMB customers already use — with zero new software for the owner.

ARNO WhatsApp Agent architecture: inbound message → Twilio webhook → Claude Sonnet 4.6 agent → QR reply + owner notify → Supabase multi-tenant Inbound WhatsApp message Customer messages the business number Twilio WhatsApp webhook /whatsapp-inbound · Fastify on Render Claude Sonnet 4.6 agent RLS per tenant · conversation history recognises returning customers by number Action handlers → Send business QR code (payment) → Owner WhatsApp notify → Transfer on complaint / allergy Supabase (multi-tenant) orders · audit log · tenant isolation pg_cron: 8am owner brief

Architecture · simplified

What makes it work

  • The business's own QR code is sent with every order — we attach the image only. No payment processing, no holding of funds, no PCI scope.
  • Allergy questions, complaints, refunds, and any high-stakes situation trigger an instant transfer message to the owner — a regex pre-filter catches these before the LLM even reads the message.
  • Each conversation is isolated by tenant via Postgres RLS — one tenant's customer history is never visible to another tenant's agent context.
  • Per-conversation and per-tenant cost circuit breakers cap spend automatically — if usage spikes unexpectedly, it pauses and alerts rather than running up an unbounded bill.
  • Returning customers are recognised by phone number and greeted by name — no extra setup required.

What it doesn't do yet

  • Richer multi-item order carts — the current flow handles a single order item per conversation cleanly; grouped multi-item orders are on the roadmap.
  • Automated follow-up nudge for incomplete orders — customers who start a conversation but don't confirm; a gentle 30-minute reminder is planned.
  • More verticals — the system is vertical-agnostic but prompt configuration needs calibrating per business type; currently optimised for the six target verticals above.
Stack Fastify · Twilio WhatsApp · Anthropic Claude (Sonnet 4.6) · Supabase (multi-tenant RLS, pg_cron) · Render
05

Salesu — Lead Intelligence Engine

Daily research system that finds new business leads and writes the call brief

What it is

A research system that runs every morning before you get to your desk. It finds UK businesses that match the kind of customer you sell to, reads their websites, pulls their reviews, and hands your sales rep a one-page call brief with talking points — so the rep walks into the call already knowing the prospect.

Why I built it

Most sales reps spend half their day on research before they pick up the phone — finding companies, reading their websites, looking up reviews, drafting the opener. That's mechanical work. I wanted to know what the day looks like if AI does the mechanical part overnight, and your rep walks in already prepared. I wanted to know if AI was finally good enough to do the part of sales that's mostly reading.

Salesu architecture: lead sources → compliance gate → researcher → pitch brief → call-ready brief Lead discovery Google Maps Places API Companies House · CQC · RCVS Compliance gate fn_can_contact() · suppression rules Researcher agent Website scrape + Claude Sonnet 4.6 Generates personalisation hook Pitch brief agent Google reviews + competitor data Drafts call opener + pain points Call-ready brief Supabase pitch_brief + brief_at Outreach automation: Phase 2

Architecture · simplified

What makes it work

  • Pulls leads from official UK sources — Companies House, Google Maps, healthcare and veterinary registers — so the businesses are real, not scraped contact data.
  • A safety check runs on every contact before anyone gets approached — no chasing people you've already spoken to, no contacting blocked names, no wrong-time outreach.
  • The call brief is written by the same AI tools used to power the most reliable enterprise software today. It reads the website and the reviews and writes a tailored opener.
  • I deliberately built only the research half. I didn't build the auto-emailing half — most businesses already have email tools they like, and choosing the wrong one for them would cost more to undo than to skip.

What it doesn't do yet

  • Email and CRM integration are not included by design — those steps tie tightly to your existing tools, and the wrong fit early would be expensive to undo. They're a natural next step once you've picked your stack.
  • The 'type of customer' definition is currently a sensible UK default — first thing we'd customise for any new client.
Stack Trigger.dev v4 · Anthropic Claude (Sonnet 4.6) · Supabase (RLS, audit log) · Google Maps Places · Companies House · CQC / RCVS · Doppler
06

Hero Pipeline / R&D Agent

Daily research system that listens to what business owners are quietly complaining about online

What it is

A system that reads the same online forums I used to scroll through manually — Reddit, Hacker News, accounting forums, job boards — and writes a one-page brief every morning of what UK business owners are quietly suffering through. It runs automatically and lands in Slack before I've had coffee. It's how I figured out which problems are worth Ciatel building products for.

Why I built it

Manually trawling forums for real customer pain was eating two to three hours of every morning before I'd done a single useful thing. I built this to give myself the headlines. The same system would work for any business that wants to know what their market is actually worried about — competitive research, customer sentiment, voice-of-the-market work.

R&D Agent architecture: cron → forum scrapers → pain extractor → embedding clusterer → brief composer → Slack Trigger.dev cron Daily 06:45 UTC + 3-hourly poll Source fetchers Reddit · Hacker News · RSS · Reed ~50 candidate posts/day Pain extractor Claude Haiku 4.5 · 4-filter frequency · money · solution · confidence Embedding clusterer Voyage 3-lite · pgvector(1024) Semantic dedup · 14-day window Brief composer Top 6 clusters by readiness score + HOT PATTERN alerts (≥5 in 24h) Slack delivery Block Kit brief · #problem-radar

Architecture · simplified

What makes it work

  • It only reads public sources — no scraping, no privacy issues, no legal risk.
  • A pre-filter throws out 60–70% of the noise before the AI even reads the post — so the system doesn't waste money on irrelevant content.
  • It groups similar complaints together, so you don't see the same problem ten times in a row.
  • If a topic suddenly spikes — five people complaining about the same thing in a single day — it sends an alert.
  • The end-of-day brief is an actual one-pager in your inbox or Slack — not another dashboard you have to remember to check.

What it doesn't do yet

  • The dashboard view (where you can browse by topic) currently shows sample data while we focus on getting the daily brief right. The plumbing is built; we'll switch it on once the daily brief has earned its keep.
  • Two extra features are designed but not yet running: a deeper competitive analysis when a topic gets interesting, and an auto-drafted social-media post about findings. Both are deliberately on hold until we're confident the daily brief is the right shape.
Stack Trigger.dev v4 · Anthropic Claude (Haiku 4.5) · Voyage AI embeddings · Supabase (pgvector + Realtime + RLS) · Slack webhooks · Next.js 15 dashboard · Doppler
07

Database Assessment

A senior engineer spends a week inside your database and tells you what's broken — in plain English

What it is

A 5–7 day audit of your business's database. I get read-only access (so nothing can be broken during the audit), spend the week looking at seven specific things — how the database is structured, where it's slow, where security gaps are, where AWS spend is being wasted, whether your backups would actually work, where storage is leaking, where you're flying blind — and write you a plain-English report ranked by what's actually costing your business money.

Why I built it

A pattern I keep seeing — your database started simple and now runs eight things nobody fully understands. The engineering team senses something's off — slowness, creeping bills, a backup nobody's tested — but they don't have a clear week to step out of feature work. So I do.

Database Assessment delivery: discovery call, read-only access, 5-7 day audit, draft, walkthrough, remediation roadmap Day 0 · Discovery call 30 min · scope, stack, concerns Day 1 · Read-only access Scoped credentials · NDA signed Days 2–5 · Audit Schema · indexes · RLS · backups AWS config · cost · storage pgAnalyze · slow query traces Day 6 · Report drafting Findings ranked by business impact Plain English · effort estimates Day 7 · Walkthrough call 60 min · Q&A · roadmap signoff Deliverable · Remediation roadmap PDF report · CSV findings list 90-day priority sequence

Architecture · simplified

What makes it work

  • Findings are ranked by what they're costing your business in pounds, not by technical severity. The report has to make sense to your finance director as well as your engineer.
  • I never modify anything during the audit — it's read-only. If you want me to fix what I find, that's a separate engagement with explicit sign-off.
  • Every finding has a 'if we don't fix this, what happens' line. Severity without consequence is just opinion.
  • The cost review uses AWS's own attribution data, not just the bill — so we can see exactly where money is leaking.

What it doesn't do yet

  • Currently it's all manual delivery. I'd like to automate the easy diagnostics so you get the boring findings in the first day, leaving the rest of the week for the parts that need real judgment.
  • I'm considering open-sourcing the diagnostic checklist so any business can run a basic health-check themselves.
Stack Postgres · MS SQL · Supabase · AWS (Cost Explorer, RDS, S3) · pgAnalyze

Defaults

Defaults I keep

Things I do on every project, regardless of brief — because these are the principles that prevent the kinds of failures I've seen most.

01

Single-tenant by default

Each customer gets their own deployment. Your data never sits on a shared server with someone else's.

02

Row-level security on every table

Even when records live alongside another tenant's, the database itself enforces that they can't cross over.

03

Strict checking at every data handoff

Bad data gets rejected at the boundary, before it can spread into the rest of the system.

04

Hard cost limits on every external service

Every paid API has a budget cap built in. No runaway spend, no surprise bills.

05

Tests written first where it matters

Not as a religion — but on the parts of the system where a bug would cost real money.

Stack

Stack & tools

The actual tools and services I build with. Deliberately short — anything that's promised the moon and then sent a surprise bill has been dropped.

Languages

  • TypeScript
  • Python
  • SQL

Frameworks

  • Astro
  • Next.js 15
  • Fastify
  • Tailwind CSS

AI / LLM

  • Anthropic Claude (Haiku 4.5, Sonnet 4.6, Opus 4.7)
  • Voyage AI embeddings
  • Anthropic SDK

Voice

  • Twilio Voice + ConversationRelay + SMS
  • ElevenLabs streaming TTS

Data & infra

  • Supabase (Postgres + pgvector + RLS + Realtime)
  • AWS (RDS, S3, Cost Explorer)
  • Vercel
  • Trigger.dev v4

Tooling

  • Doppler (secrets)
  • Lucide
  • Zod
  • pgAnalyze

Background

Background

Double Master's in Engineering and Project Management. Spent most of my career inside production systems that have to keep running when nobody's watching — that's where my intuition for what's actually load-bearing comes from.

AI business consultant and automation expert, and co-founder of Ciatel Corp Ltd, registered in England & Wales. The company is the commercial vehicle; this site is the engineering one. They share a stack, a brand, and a phone number.

Most interested in: building AI products that actually work in real businesses (not just demos), keeping each customer's data inside their own systems, the unglamorous engineering that makes the difference between a demo and a working product, and what UK small businesses are quietly putting up with that no software vendor has bothered to fix.