Service AI development

An AI development company that ships production systems, not demos.

Most AI proposals describe what a model can do. The engineering is everywhere else: what it is allowed to reach, what happens when it is wrong, and what it costs per call once real people are using it. That is the part we build.

Seven of our MCP servers are open source, so you can read the code before you contact us
Open source · 7 servers public on GitHub
Server Connects a model to
wp-malware-cleanup-mcp WordPress installs, over SSH
buddypress-mcp Community data and moderation
zoho-desk-mcp-server Support tickets and customers
basecamp-mcp-server Projects, cards and comments

Four of seven shown. All public, so you can read how we build before you ask us to build anything.

There are two kinds of AI project. One produces a demo that impresses in a meeting and quietly stops being used. The other produces something people rely on, which means it has permissions, a cost ceiling, a failure path and somebody who gets alerted at 2am.

The difference is not the model. It is whether the boring parts were built. This page is mostly about the boring parts.

What we build

Five kinds of AI work, and which page covers each.

01

Agents that do work

Not a chat box. An agent with tools, a defined scope, a failure path and a human handoff. It reads what it needs, takes the action it is allowed to take, and stops when it should.

Work that used to need a person watching it.

02

MCP servers, so a model can reach your systems

Model Context Protocol servers connect a model to the things you already run: your database, your ticketing, your project tool, your WordPress install. We have seven of them public on GitHub.

Your own systems, reachable by a model, with the permissions you set.

03

AI inside an existing product

Search that understands the question, summaries that are accurate, classification that routes correctly. Wired into a product that already exists rather than built beside it.

A feature your users notice, not a badge on the marketing site.

04

Automation between tools

The work that happens between systems: lead routing, data sync, reporting that assembles itself, approvals and handoffs. Sometimes that needs a model and sometimes it needs a rule, and we will tell you which.

Fewer things a person copies from one screen to another.

05

Chatbots that answer from your documents

Retrieval first, so the answer comes from your real material rather than from the model guessing. When confidence drops or retrieval fails, it hands to a person instead of inventing something.

Answers you would be comfortable seeing quoted back to you.

Open source

seven of our MCP servers are public on GitHub, readable before you contact us

Tool definitions, permission handling and failure paths, all in the open. Most AI capability claims cannot be checked by the person reading them. These can.

The question nobody answers

What it costs to run, not just to build.

01

Cost per call, not just cost to build

Every call has a token cost. Prompt caching, batching where latency allows, and a smaller model where a smaller model is enough. Wired in from the first integration rather than after the first invoice.

Per-call cost logged, so you can see what each feature costs to run.

02

A ceiling you set

A per-tenant or per-feature cap, enforced in code. Finance knows the maximum before the month starts rather than after it.

No surprise bill, because a surprise bill is how AI features get switched off.

03

What happens when the provider is down

Retries, fallbacks between providers, idempotent steps, a dead-letter queue for what cannot complete, and an alert to a person rather than a silent failure.

An outage pauses a run instead of losing it.

The other half of honest

When AI is the wrong answer.

01

When a rule would do

If the logic is "when X, do Y", that is an if statement. It is cheaper, faster, testable, and it will still be correct in a year. Reaching for a model here adds cost and uncertainty for nothing.

We will write the rule and not bill you for an AI project.

02

When the data is not there

A model cannot retrieve what you have not written down. If the knowledge lives in three people rather than in documents, the first project is capturing it, not automating it.

An honest sequence rather than a disappointing pilot.

03

When being wrong is expensive

Anything probabilistic will sometimes be wrong. Where a wrong answer costs money, safety or a regulatory problem, the design needs a human in the path, and that changes what is worth automating.

The failure case designed first, not discovered in production.

What it costs

What an AI project costs is decided by reach and by write access.

Two systems with identical screens can differ by a factor of several, because the cost sits in what the model may touch and what happens when it is wrong. These are the things that move it.

What moves the number

  • What it reaches, and whether it may write Reading your documents is one problem. Writing to your CRM, your ticketing or your database is another, and it brings permissions, audit trails and a rollback path with it.
  • How many systems are involved Each integration is scoped by the system on the other end and how much of it you control. A modern API is quick. A legacy system with no API is most of the project.
  • Who uses it An internal tool for your own team tolerates rough edges. Anything customer-facing needs the failure path, the tone, and the escalation designed properly.
  • What a wrong answer costs Low stakes means you can ship and iterate. Where a mistake costs money or carries a regulatory consequence, a human sits in the path and that shapes the whole design.
  • Call volume and context size This decides running cost rather than build cost, and it is the number that determines whether the feature is still switched on in a year.

A read-only assistant over documents you already have is a contained piece of work. Anything that writes to a system of record is a different engagement with a different review attached.

Rough idea to delivery

  1. You send the details What you want built, roughly, plus budget range and timing. The form asks for all of it
  2. Within 4 business hours We read it and reply. Nothing is scheduled before we know what it is about
  3. Then the call Free discovery, booked once there is enough on the table to make it worth your hour
  4. Within 48 hours of the call A written fixed-price quote you approve before anything starts
Get an estimate

Quick enquiry

What should it be able to reach?

The two answers that shape everything else are which system it connects to, and whether it needs to write as well as read. A rough version of both is enough for a useful reply.

Prefer the full form? Start a project

No drip sequences, no marketing list. We reply and that is it.

Common questions

Frequently asked

  1. What makes an AI development company different from a normal agency?

    Mostly the parts that are not the model. Anyone can call an API. The engineering is in what the model is allowed to reach, what happens when it is wrong, what it costs per call, and how it behaves when the provider is down. If a proposal talks about capability and not about failure paths and running cost, it has not been through production.

  2. Can we see something you have built before we talk?

    Yes, and that is unusual enough to be the main reason to start here. Seven of our MCP servers are open source on GitHub, so you can read the code, the tool definitions and the permission handling before you contact anyone. We also run AI in our own operations daily, which is where most of what we know came from.

  3. Which models do you build on?

    Whichever fits the job, and the answer changes as the models change. More useful is that we build the integration so the model is replaceable: a provider swap should be a config change and a re-run of the evaluation set, not a rewrite. Committing your architecture to one vendor is the expensive mistake in this space.

  4. How do you stop it making things up?

    Retrieval first, so the answer comes from your material rather than the model. Structured output with schema validation, so an invalid response fails loudly instead of passing through. An evaluation set that ships with the build so you can re-run it after any prompt change. And a confidence threshold below which it hands to a person.

  5. What does it cost to run, not just to build?

    That depends on call volume, how much context each call carries, and how much of it can be cached. We wire per-call cost logging in from the start and set a ceiling you control, so the number is visible from week one rather than discovered on an invoice. Any proposal that does not mention running cost is quoting half the project.

  6. What does an AI engagement cost?

    It is scoped after we know what the system reaches and whether it may write as well as read, because those two answers move the number more than anything else. Tell us those in the form below and we will come back with a written fixed-price quote.

Building something with AI?

Tell us what it needs to reach.

Discovery call is free, and it happens after we have read what you sent rather than before.