Skip to main content
All services

AI & Intelligent Systems

Intelligence.Built to operate.

LLM applications, AI agents, computer vision, machine learning, and intelligent automation — built to run in production, not just in a notebook.

  • LLMs
  • Agents
  • Computer Vision
  • RAG
  • INPUT · INFERENCE · ACTION
  • SIX TIERS
  • THE MODEL IS ONE OF THEM

AI & Intelligent Systems.

  1. 01ModelOne component
  2. 02SystemBuilt around it
  3. 03ProductWhere a person meets it
  4. 04ProductionOperated, measured, versioned

A model is not a product. It is one component, and usually the one that changes least often. The work that decides whether an AI feature survives contact with real users is everything around it: where the data comes from, what happens when the model is wrong, what the system is allowed to do on its own, how a bad answer is caught before a person sees it, and what it costs to serve on a Tuesday afternoon.

That is the distance between a notebook and a platform, and it is where most AI projects stop. A demo has to work once, for someone who wants it to. A production system has to work on the inputs nobody anticipated, degrade honestly when it cannot, and be debuggable at two in the morning by an engineer who did not build it.

We build the system, not the demo. Retrieval that is grounded in your data rather than the model's memory. Agents with an explicit control flow and a defined blast radius. Evaluation that runs before a prompt change ships, not after a customer finds the regression. And the observability to know which version of which model answered, and what it was given to answer with.

Capabilities

What we actually build.

Five capabilities, and the engineering surface under each one. Engagements are usually a subset, scoped to the system in front of us. Nothing here is a model we resell or a platform we white-label — it is engineering work carried out on your product.

05 capabilities · 25 focus areas

01LLM Applications
Products built on large language models, where the engineering problem is almost never the model. It is what the model is given, what shape its answer has to arrive in, and what the product does when it is wrong — so the work is retrieval grounded in your own content, outputs validated against a schema rather than parsed out of prose, and a surface that cites what it drew from.
  • Model integration
  • Context and retrieval
  • Structured outputs
  • Application workflows
  • Production interfaces
02AI Agents
Systems that take multi-step action against real tools. The difficulty is not getting a model to decide what to do next; it is bounding what it is allowed to do, keeping state across a run that may fail halfway, and making the decision path something you can read afterwards. An agent without an explicit control flow is a loop with an unbounded blast radius.
  • Tool definitions
  • Orchestration
  • State and memory
  • Decision paths
  • Controlled execution
03Computer Vision
Image and video understanding applied to a specific operational problem — detection, classification, and extraction from scanned or photographed documents — including the unglamorous half: building the labelled set the result is measured against, and the pipeline that runs it on real files at real volume rather than on a curated sample.
  • Image and video understanding
  • Detection
  • Classification
  • Visual inference
  • Production pipelines
04Machine Learning
Classical models where they are the better instrument: forecasting, ranking, scoring, segmentation and anomaly detection. Often smaller, cheaper, faster and more explainable than a language model, and frequently the correct answer to a problem an LLM is being pointed at. The work is as much lifecycle as modelling — data, evaluation, deployment, and what happens as the world moves under it.
  • Data preparation
  • Inference
  • Model lifecycle
  • Evaluation
  • Deployment
05Intelligent Automation
A workflow where a model makes one judgement inside a process that already exists — triage, routing, reconciliation, document handling. The deterministic parts stay deterministic and the model is confined to the step that genuinely needs one, which is what makes the result auditable rather than merely automatic.
  • Event
  • Decision
  • Action
  • Workflow
  • System integration

Where a problem does not need a model, we say so. A retrieval system, a rules engine or a well-shaped query is often the correct answer, and it is a cheaper one to run and to reason about.

Intelligence pipeline

The model is one of six tiers.

An AI feature is a path, not a box. Something arrives, it is turned into context a model can reason over, the model infers, tools make action possible, orchestration decides what runs, and an output returns to the product. Each is a tier with its own failure modes — and the one everybody talks about is a sixth of the work.

Input · Inference · Action

06 tiers · 30 controls

  1. Input

    01

    Input

    What the system receives

    Documents, images, events, user queries, telemetry. The boundary where quality is decided: what is accepted, what is rejected, what is redacted before it goes any further, and what is kept so an answer can be traced back to what produced it.

    • Source definition
    • Validation
    • PII redaction
    • Rate limiting
    • Provenance capture
  2. 02

    Context

    What the model is given to reason over

    A model knows nothing about your business except what it is handed, so this tier decides what it is handed. Parsing, chunking, embedding, retrieval and the conversation state carried between turns. Most of what reads as a model being clever or stupid is decided here — retrieval that returns the wrong passage makes a capable model confidently wrong, and no amount of prompt work recovers it.

    • Parsing and extraction
    • Chunking strategy
    • Embedding and index
    • Retrieval ranking
    • Conversation state

  3. Inference

    03

    Model

    Where the inference happens

    LLM inference, vision models, and classical machine learning where it is the better instrument. Model choice is an engineering decision with a cost and a latency attached rather than a brand preference, and the interface around it is written narrow so a model can be replaced without rewriting the product.

    • Model selection
    • Prompt and context design
    • Fine-tuning
    • Structured output
    • Fallback routing

  4. Action

    04

    Tools

    What the system is able to do

    The functions the model may call, and the boundary around each one. A tool is an API with a schema, a permission and a blast radius — not a prompt instruction. Defining that set is what turns a model that can describe an action into a system that can take one, and keeping it small is what keeps the system reasonable about.

    • Tool schemas
    • Scoped permissions
    • Argument validation
    • Side-effect boundary
    • Human confirmation
  5. 05

    Orchestration

    How steps become a task

    The control flow that turns single calls into a working agent: what runs, in what order, with what state, and what happens when a step fails. An agent without an explicit control flow is a loop with an unbounded blast radius, which is why the boundary is drawn here rather than discovered in production.

    • Control flow
    • Routing and planning
    • State and memory
    • Retries and timeouts
    • Guardrails
  6. 06

    Output

    What returns to the product

    The result becoming something a person or another system can use: a validated payload, a streamed answer with citations, a written record, an honest uncertainty state instead of a confident guess, and the feedback path that produces evaluation data rather than a satisfaction score.

    • Output validation
    • Streaming interface
    • Citations
    • Uncertainty states
    • Feedback capture
Stage 01
Input00:01
Stage 02
Model00:03
Stage 03
Output00:06
Source
1920 × 108030fps · 1.21MB

Still frame

Input · Context · Model · Tools · Orchestration · Output

Intelligence pipeline

How the work is sequenced.

The order matters more here than in most engineering. Building before grounding produces a system that demos well and fails on real inputs; shipping before evaluating means the first person to find the regression is a customer.

  1. 01

    Frame

    Decide whether this needs a model at all.

    What decision is being made, by whom, and what does being wrong cost? That answer sets everything downstream — how much latency is acceptable, whether a person has to confirm, and whether a model is the right instrument or an expensive way to do a lookup.

  2. 02

    Ground

    Get the data and the retrieval right first.

    Sources, access, extraction, chunking, embedding and index design, with the evaluation set built at the same time rather than afterwards. A model can only be as good as what it is handed, and this is the stage that decides what it is handed.

  3. 03

    Build

    Engineer the system around the model.

    Control flow, tool boundaries, structured outputs, state, retries, fallbacks and guardrails — plus the product surface that makes the result legible. The model interface is kept narrow so the model behind it can change without the product changing.

  4. 04

    Evaluate

    Measure it before anyone depends on it.

    Test cases drawn from real inputs, scored against the behaviour you actually want, run in CI so a prompt or model change is a reviewable diff with a result attached. Non-determinism is not a reason to skip measurement; it is the reason to automate it.

  5. 05

    Operate

    Run it, watch it, and keep improving it.

    Cost and latency budgets, drift and failure monitoring, versioned prompts and models, and a feedback path that turns real usage into the next evaluation set. AI systems degrade quietly as the world moves under them, so operating one is a continuing job.

Production engineering

What makes it production.

A notebook has to work once. A production system has to work on inputs nobody anticipated, fail honestly, and be debuggable by someone who did not build it. These are the properties we engineer for, and the ones we would ask about if we were buying this work rather than doing it.

01Evaluation before deployment
A held-out set drawn from real inputs, scored against intended behaviour, running in CI. A prompt change and a model upgrade are both code changes and both get a result attached before merge.
02Designed failure modes
What the system does when retrieval returns nothing, the model refuses, the provider is down or the answer is low-confidence. An honest "I don't know" and a route to a person are features, not gaps.
03Guardrails and blast radius
Output validation, scoped credentials narrower than the user's, idempotent effects and confirmation on anything irreversible. What an agent is allowed to do is decided at design time, not discovered in production.
04Cost and latency budgets
Token and inference cost tracked per operation, caching where the same question is asked twice, smaller models used where they are sufficient, and streaming so latency is legible instead of a spinner.
05Observability and traceability
Every output traceable to the model version, prompt version and retrieved context that produced it. Without that, an AI bug report is unfalsifiable and every fix is a guess.
06Versioning and rollback
Prompts, models, indexes and policies are versioned artefacts with a rollback path. A provider deprecating a model becomes a scheduled migration rather than an outage.

Where this fits

Shapes of problem this work suits.

These are problem shapes rather than case studies — the situations where an engineered AI system earns its cost. Our published project work lives under Selected Work; nothing below is presented as a delivered engagement.

01Answers locked inside your own documents
A large, changing body of internal content that people need answers from. Retrieval grounded in the source, answers that cite it, and an honest empty state when the corpus genuinely does not contain the answer.
02Structured data trapped in unstructured files
Invoices, contracts, forms, scans and photographs that a person currently retypes. Extraction into a schema, confidence per field, and a review queue for the cases the system is not sure about.
03High-volume triage and routing
Tickets, applications, submissions or alerts arriving faster than a team can classify them. A model on the judgement step, deterministic rules everywhere else, and a measurable fallback when it is uncertain.
04Multi-step work across several systems
A process that spans tools and currently depends on a person moving between them. An agent with an explicit control flow, scoped permissions per tool, and a confirmation step before anything irreversible.
05Visual inspection at a volume people cannot sustain
Images or video that need consistent judgement — condition, compliance, defect, presence. Built with the labelled evaluation set that makes the result checkable rather than asserted.
06Prediction from operational history
Demand, churn, risk, ranking or anomaly detection where the pattern is in data you already hold. Frequently a classical model: smaller, cheaper, faster and easier to explain to the person who has to act on it.

Systems layer

What it is built on.

Read from the same engineering stack the rest of the site publishes, not a separate AI list — so this section cannot claim a technology Moonpie does not already work in. Model providers are deliberately not named: provider choice is an engagement decision, and the interface around it is written so it can change.

01AI05The models themselves, and the shape of problem each one is actually good for
  • LLMs
  • AI Agents
  • Computer Vision
  • Generative AI
  • Machine Learning
02Backend05Where inference is called from, and what holds the result
  • Node.js
  • Python
  • REST APIs
  • GraphQL
  • WebSockets
03Database04Retrieval and state — including the vector stores an LLM system reads from
  • PostgreSQL
  • Redis
  • Supabase
  • Vector Databases
04Cloud04Where the workload runs, and what it costs to keep it running
  • AWS
  • Vercel
  • Cloudflare
  • Object Storage
05Infrastructure04How a change to a prompt, a model or a policy is shipped and observed
  • Docker
  • CI/CD
  • Observability
  • Infrastructure as Code

Have a problem that mightneed a model?

Bring the problem rather than the solution. The first useful conversation is about what decision is being made and what being wrong costs — which is also how we work out whether you need AI at all.

Start a ProjectAll services