Engineering for the AI era. Real AI. Real engineering. Built to last.

Yes — AI engineering is one of the engagement types most often asked for by our agency partners. Three partnership models: white-label (your brand, our engineers, fully invisible), agency-of-record (a dedicated AI pod working as your in-house capacity), and capacity overflow (sprint-by-sprint engagement when your in-house team is full). AI engineering as a white-label offering needs particularly careful IP handling — model access keys stay yours, training data stays yours, evaluation harnesses transfer to your repos, and the production inference endpoints run in your infrastructure. Standard NDA and sub-contract in place before any work begins.

Our entire engineering team is based in Noida, India — 40 people in our iThum Tower B office, founded in 2015. We work with product teams and agencies across the UK, US, Ireland, Australia, the UAE, Germany, and the Netherlands. Working hours overlap with UK mornings, the full EU workday, and US afternoons. The AI engineers on the team are also engineers in the rest of our practice — there is no separate AI team disconnected from the production engineers who keep your system running.

AI Integration means adding AI features to an existing product — RAG over your documentation, in-app summarisation, classification, recommendations, generative features alongside what is already there. AI Workflow means automating internal business processes with AI — agentic systems that triage tickets, draft responses, process documents, replace manual research workflows. AI Product Development means building an AI-first product from scratch where AI is the core capability, not a feature. Most engagements start in Integration or Workflow; some graduate to Product when the AI proves out and becomes the centre of the offering.

Honest scope drivers: model choice and inference volume, depth of evaluation required, complexity of data preparation, integration complexity with existing systems, and production observability requirements. A focused RAG MVP over existing documents is at the lower end of the range. A full agentic workflow with eval coverage and human-in-the-loop fallback is mid-range. A production AI-first product with custom fine-tuning and multi-region inference is at the higher end. We scope every engagement against the specific brief and are honest about which features should wait until phase two — most AI projects are over-scoped on the first draft.

A focused RAG MVP over existing documents typically takes 4 to 8 weeks. An agentic workflow with full evaluation harness takes 8 to 14 weeks. An in-product AI feature added to an existing application takes 6 to 12 weeks. An AI-first product takes 16 to 26 weeks. Eval discipline adds time at the start of the build that pays back many times during rollout — most AI projects that ship late are projects that skipped evals and discovered the problem in production. Two-week sprints with eval-gated reviews from sprint one.

AI that demos well is unmeasured. AI that ships has evals, latency budgets, cost ceilings, fallback behaviour, and observability. The demo runs on three carefully chosen prompts and a model with no rate limits. The production system runs on real user inputs at p95 budget, with hallucinations caught by judge models or grounding, with fallback to human review where the case warrants it, with cost capped per task, and with continuous evaluation against a golden dataset that grows every week. The engineering difference between the two is roughly 80% of the total work.

Layered defence. First, retrieval-augmented generation grounds the model in your documents rather than relying on parametric knowledge. Second, constrained outputs and structured response formats narrow the surface area where hallucinations can hide. Third, judge models verify the output against the retrieved context before it is shown to the user. Fourth, low-temperature inference on critical paths reduces variance. Fifth, human-in-the-loop on cases the system marks as low-confidence. Sixth, continuous evaluation against a hallucination-tracking golden dataset that catches drift as models update. No single defence is enough; the system is the defence.

Golden datasets per use case — typically 200 to 1,000 examples curated with the client, growing every week. Judge-model evaluation against the golden dataset on every prompt change, model swap, or retrieval-tuning change. A/B against humans where the stakes warrant it. Per-task accuracy thresholds named in the contract. Hallucination rate ceiling named in the contract. Eval coverage percentage tracked in CI. Production observability captures the prompts that fail and feeds them back into the golden dataset. We use Promptfoo, custom judge pipelines, Langfuse, and Phoenix depending on the build.

Frontier closed models when accuracy is the leading constraint: Claude (Anthropic) — Sonnet for most production paths, Opus for reasoning-heavy cases, Haiku for cost-sensitive paths; OpenAI — GPT-4o for general, GPT-4o-mini for cost, o1 for deep reasoning; Google Gemini — 1.5 Pro and 1.5 Flash for long-context. Open-source models when cost, latency, or data residency lead: Llama 3.x for general, Mistral for cost-sensitive, Qwen for multilingual. We are model-agnostic and recommend based on the case — most agencies who only know one model recommend that one for everything. We build with an abstraction layer so the model is swappable without rewriting the application.

No. We build with a model-router abstraction (custom or LiteLLM-style) that lets you swap providers without rewriting the application. The evaluation harness runs across providers, so when a new model launches you can A/B test it on your real workload before committing. Most of our clients move between two and four model providers over the lifetime of a system as relative pricing, latency, and accuracy shift. The lock-in risk in AI engineering is not the model — it is the prompts, the evaluations, and the architecture. Those stay with you.

Multi-layer cost control. Smaller models on the cheap path with automatic escalation to larger models only when confidence is low. Prompt caching where the provider supports it (Anthropic prompt caching cuts repeat-token costs by 70 to 90%). Batching for non-interactive workloads. Smaller context windows by aggressive retrieval rather than dump-everything prompts. Cost per task tracked in production observability and fed into budget alerts. For every build we name an explicit cost per task target in the contract and hold ourselves to it. Most AI projects come in under budget because the typical first build is over-engineered on model choice.

Yes — this is a common engagement type. Most AI prototypes are built by engineering teams new to AI; they work on demo data but fall over in production for predictable reasons. Typical migration: audit the prototype against eight production-readiness criteria (evals, fallbacks, observability, cost control, latency budget, error handling, data hygiene, prompt versioning), build the missing pieces, replace ad-hoc prompts with a versioned prompt registry, add a golden-dataset evaluation harness, introduce cost and latency observability, and roll out under a feature flag with an A/B comparison against the prototype. Typical engagement: 8 to 14 weeks.

Our default 2026 production AI stack: Python 3.12 + FastAPI for the AI backend; one frontier model per critical path (Claude Sonnet most commonly) plus an open-source fallback (Llama 3.x); a vector database (Pinecone for managed, Chroma or pgvector for self-hosted); LangChain or LlamaIndex for orchestration where it earns the complexity, otherwise custom; Promptfoo and a custom judge-model harness for evaluation; Langfuse or Helicone for observability; structured outputs via Pydantic + provider-side JSON mode; rate limiting and retries via Tenacity; prompt versioning via a Git-backed prompt registry; deployment on AWS or GCP behind an inference gateway. We adjust based on the team and the case but this stack ships fast and stays maintainable.