What we do

Three practices, and the
engineering that carries them

We take a narrow set of problems seriously rather than offering everything. Each service below links to the platform where we proved it — so you can check the claim instead of taking it on trust.

01 / Practice

Agentic AI systems

Agents that finish work, not just answer questions

Proven in AgentOS

An agent is only useful if it can plan, pick the right tool, recover when a step fails, and stop when it should. That is an orchestration and boundary problem far more than a prompting one — which is why we built the platform layer ourselves before offering it as a service.

Multi-agent orchestration

Planning, tool use and multi-step execution, with the memory and permission boundaries that keep autonomy predictable.

Retrieval that fits your estate

Vector, hybrid or fully vectorless — database-agnostic by design, so retrieval works on the datastore you already run, even air-gapped.

Conversational & voice agents

Dialogue systems, question answering and speech in and out, grounded in your own content rather than the open web.

Evaluation & guardrails

Golden corpora, adversarial critics and refusal behaviour, so quality is measured continuously rather than assumed.

  • LiteLLM
  • FastAPI
  • RAG
  • Knowledge graphs
  • Whisper
  • Eval harnesses
02 / Practice

Model fine-tuning

When a general model is close, but not right

Proven in client work

Fine-tuning is worth doing when it buys accuracy on your vocabulary, lower latency, lower cost per call, or the ability to run on your own hardware. We will tell you when prompting or retrieval would get you there first — that answer is cheaper for you and more honest from us.

Dataset curation

Labelling strategy, synthetic augmentation and a held-out set built before training starts, not after.

Adaptation

LoRA and PEFT methods for domain, tone and task, sized to the smallest model that meets the bar.

Measured iteration

Every run scored against the same evaluation set, so an improvement is demonstrated rather than felt.

Serving & on-device

Quantisation, inference optimisation and deployment — including on-device, as in Haramayn Guide.

  • PyTorch
  • LoRA / PEFT
  • Quantisation
  • scikit-learn
  • Model serving
03 / Practice

AI product experience

Most AI features fail on interface, not on model quality

Proven in Haramayn Guide

A model that is right 92% of the time still needs an interface that handles the other 8% gracefully. We design for latency, uncertainty and trust: streaming output, visible sources, sensible degradation, and an honest "I don't know" instead of a confident invention.

Conversational interfaces

Chat, voice and assistive surfaces that stream, stay interruptible, and show their working.

Offline-first design

Local storage, on-device inference and sync strategies for places the network cannot be relied on.

Explainability surfaces

Citations, provenance and confidence shown in the product, not buried in a log.

Human-in-the-loop

Review and approval flows for decisions a business is not willing to fully automate — and should not.

  • Next.js
  • React
  • PWA
  • Capacitor
  • IndexedDB
  • Streaming APIs
04 / Foundation

The engineering underneath

Platforms, pipelines, automation and deployment

Proven in Agrozent

AI is a component inside a system that also has to authenticate users, move data, survive traffic, keep customer information private and be deployable on a Tuesday afternoon. We build that part too — it is usually where projects actually stall, and it is where production-grade is won or lost.

Platform & API development

REST and service architectures, authentication, integration with the systems you already run.

Automation & data pipelines

Python automation, document and PDF processing, resilient scraping with change detection and alerting.

Data & storage

PostgreSQL, Supabase, Redis and search indexes, with migrations treated as append-only history.

Security, privacy & hardening

Encryption at rest, tenant isolation, role-based access, audit trails, rate limiting and abuse defence — deployed self-hosted, on-premise or air-gapped when your data cannot leave.

  • Python
  • FastAPI
  • Flask
  • TypeScript
  • PostgreSQL
  • Redis
  • Docker
  • Nginx
  • CI/CD
05 / How we work

A short, honest engagement beats a long proposal

We would rather spend a week proving the idea is wrong than three months building the wrong thing well.

Start a conversation
  1. 01

    Scoping call — free

    You describe the problem and the decision it supports. We tell you whether AI is the right instrument, and if it is not, what we would do instead.

  2. 02

    Feasibility spike — one to two weeks

    A narrow, real test against your data with a measurable pass mark agreed up front. It either clears the bar or it does not, and you own the findings either way.

  3. 03

    Build

    Iterative delivery against the evaluation set built in step two, with working software you can try at the end of every cycle rather than a status report.

  4. 04

    Deploy and hand over

    Production deployment, monitoring, documentation and a walkthrough for your team. You should not need us to keep it running.

06 / Start

Not sure which of these you need?

That is a normal place to start. Describe the problem and we will tell you which practice it belongs to — or that it belongs to none of them.