AI solutions inside your product

We add AI where it changes the work: extraction from documents, search over your own material, assistants that answer from that material, and agents that draft a change a person approves.

What we build

The useful version of this work is a feature in a product you already operate, or in one we are building with you. A stack of invoices becomes structured records. A body of documents becomes something a person can search in their own words. An assistant answers from that material and says when it cannot. An agent prepares a draft, a ticket update, or a pull request, and a person decides whether it lands.

We do not start from a model demo. Our AI development starts from the records, tickets, or files you already have, and from the decision a person still has to make. A custom model is a tool we use when a hosted model is the wrong fit, not the default pitch. Training data stays in the system we agree. Anything that writes back into the business is reviewed.

Tools, models, and APIs we work with

In the product, we use models from Cursor and Grok, alongside language models from OpenAI, Anthropic, and Mistral. For image and document recognition, we have worked with AWS Rekognition and Google Cloud Vision. We also build with Cursor: agents help us write and review code, and people make the decisions. Which provider is used where is documented in the handover, so a model can later be replaced by a better or cheaper one.

Typical starting points

  • Invoices, forms, or emails that someone still reads and retypes.
  • Manuals, tickets, or documents that people cannot search in their own words.
  • Repetitive drafts, summaries, or ticket updates that a person should approve, not write from scratch.

Where it sits

These features need a place to live: a web app, a hybrid app, or an internal tool. The retrieval index, the files, and the job that refreshes them are backend work in the same engagement, so the assistant is not a sidecar with its own account and its own bill.

If the ask is a research paper, a foundation model, or an unattended agent with production write access, we will not take it in that form. The engagement starts by naming the review step.

What you leave with

A feature your team can turn off, a data path you can inspect, and source in your repository. The model vendor, if there is one, is named in the handover as a dependency you can replace.

Questions we hear first

Will it act without a person checking? Not on anything that writes back into your business. Agents draft; a person approves.

Where does our data go? Into the system we agree in the scope. The data path is part of the delivery and can be inspected.

Do we need a custom model? Usually not. We reach for one only when a hosted model is the wrong fit for the task or the data.

Built by the studio whose clients include Universal Music, SongPush, and Bonial. More about the studio.

Let's Talk