Custom AI Systems Built Around Your Process
Bespoke AI builds for work that standard tools do not quite fit.
A custom AI system is software built specifically around one of your processes, combining language models, your data and your existing tools. It suits work that is too particular for an off-the-shelf product but too valuable to keep doing by hand: sourcing potential deals, producing content across several platforms, or drafting documents for review.
We approach these projects by starting with the decision or output you need, then working backwards to the data, models and checks required. Most of what we build has an approval step, because AI output can be wrong, and the cost of a mistake is higher in some processes than others.
Custom does not always mean large. Some of our builds are a handful of connected steps. We recommend the simplest design that does the job, and we will tell you if an existing tool would serve you better than a bespoke build.
A good fit when
Businesses with a specific process that no standard product fits.
Teams publishing similar content across several platforms by hand.
Firms that research or source opportunities from many scattered sources.
Teams producing first drafts of documents from templates and data.
Probably not when
Problems an existing off-the-shelf tool already solves at lower cost.
Processes where no one can define what a good result looks like.
High-stakes output that must go out with no human review.
What a Custom AI Systems project includes
Content and publishing pipelines
The system takes a source, such as a blog post, product update or idea list, and drafts versions adapted to each platform's format and tone, using examples of your own writing. Drafts appear in a review queue where a person edits, approves or rejects them. Approved items are scheduled and published to the connected accounts. Nothing goes out unreviewed, and the tone and topics that are off limits are set by you.
Research and sourcing systems
The system collects information from sources you define, such as public registers, websites and databases, then filters and scores each item against criteria you agree. The result is a shortlist with the reasons for each score and links to the underlying sources. A person reviews it and decides what to pursue. Scores are a way of ordering the work, not a verdict, and the reasoning is always visible so it can be challenged.
Drafting with approval
Using your data and templates, the system assembles a first draft of a document such as a proposal, summary or standard letter, filling in known details and drafting the remaining text. The draft goes to the named reviewer with the sources it used marked. They edit and approve it, and the approval is recorded. The system never finalises or sends a document itself, and legal or contractual content stays with your own advisers.
Internal tools and interfaces
Where the work needs a person in the loop, we build a simple interface around it: a form to start a job, a dashboard showing what is running, a queue of items awaiting review, and buttons to approve, edit or stop. Your team uses it without touching code. Access can be restricted by person, and every action is logged, so you can see who approved what and when.
How a custom build takes shape
We begin with the output rather than the technology. What decision or document should the system produce, what does a good version look like, and what would make one unacceptable? We collect real examples of both. From those we work out which data is needed, whether it is reliable, and which steps need a language model versus plain rules. Often a large share of a process is ordinary data handling, and we keep AI for the parts that need reading or writing.
Next comes a prototype, built on a modest amount of your real material. This is the point where most disagreements surface, and it is far cheaper to discover them now. You see actual outputs, we compare them with your examples, and we adjust prompts, data and rules. Only when the results are good enough to review do we invest in the surrounding parts: approvals, logging, error handling, an interface, and a proper place to run the system.
What we automate and what stays with your team
The system does the assembly work: gathering, filtering, drafting, formatting and routing. It does it the same way each time, and it does not tire or skip steps. That is where custom builds pay off, since a person can spend their time reading a scored shortlist rather than building one, or editing a draft rather than staring at a blank page. We agree exactly which stages are automatic, which need approval, and where the process stops if something looks wrong.
Judgement stays with people. AI output can be fluent and still wrong, so we do not treat a confident-sounding result as a correct one. A reviewer decides whether a shortlisted target is worth a call, whether a draft is accurate, whether a post reflects your position. We also design against overreliance. Logs show what the system used, and sample checks continue after launch. If quality drifts, or a source changes format, you find out from the checks, not from a customer.
Data, ownership and running costs
A custom system is only as good as the data it can reach. Early on we look at where the data lives, how clean it is, and whether we may use it in this way. That includes personal data, client confidential material and third-party content. We discuss which model providers would process it and what settings apply. Your own legal or data protection adviser should confirm what is permitted. Where a requirement rules out a design, we change the design rather than work around the rule.
Ownership and running costs are agreed before the build, not after. We settle who owns the code and configuration, where the system is hosted, whose accounts and API keys it uses, and who handles fixes when a connected tool or model changes. Language model usage has an ongoing cost that grows with volume, so we explain what drives it. We hand over documentation covering how the system works, so it does not depend on one person, including us.
Typical Custom AI Systems scenarios
One idea, five platforms
A small team writes one article and then reworks it by hand for several social platforms. The pipeline drafts each version in the right format and tone, and queues them for review. The team edits what needs editing, approves the rest, and the posts are scheduled. Nothing is published without a person having seen it.
Sourcing from scattered data
A firm looks for potential targets across registers, news and directories, all checked by hand. The system collects from those sources on a schedule, scores each against agreed criteria and presents a shortlist with reasons and links. Analysts spend their time judging the shortlist, and the criteria are adjusted when they disagree with a score.
First drafts of repeat documents
Staff produce similar proposals or summaries from a template each week. The system fills in known details from your records, drafts the remaining sections and sends the draft to the named reviewer. The reviewer corrects and approves it. The approval is logged, and the system never sends a document to a client itself.
A process with no off-the-shelf tool
A business has a specific process spanning three tools, and every product it tries needs awkward workarounds. A small custom system links the data sources, carries out the repeatable steps and gives the team a simple screen for reviewing results. We may also conclude, after scoping, that an existing product would do.
What is different for your team afterwards
Specialist work done consistently
A process that used to take manual effort each time now runs the same way, with review points built in.
Your team reviews rather than starts from scratch
People assess shortlists and drafts instead of building them, and keep the final decision.
A system you can understand
Ownership, logging and controls are agreed up front, so it does not depend on one person.
How a project runs
Define the output
We agree what a good result looks like, who reviews it and what would make it unacceptable.
Prototype quickly
We build a working version on a small amount of real material so you can judge quality before wider investment.
Add controls
We add approvals, logging, error handling and limits, and agree who owns the system once it is running.
Deploy and iterate
We launch, review outputs with you and refine prompts, data and rules based on what the system gets right and wrong.
What you receive
An agreed definition of a good output and who reviews it
A working prototype tested on your real material
The finished system with approvals, logging and error handling
Simple interfaces for your team to trigger and review work
Documentation covering ownership, hosting and how it works
A review of outputs after launch, with refinements
Where Custom AI Systems is used
Systems we have built and run
Services often combined with Custom AI Systems
Frequently asked questions
When does a custom build make sense over an off-the-shelf tool?
When your process is specific, when you need to combine several data sources, or when existing products force awkward workarounds. If a standard tool does the job, we will tell you, since it is usually cheaper to run.
Who owns the system after it is built?
Ownership, hosting and support terms should be agreed in writing before work starts. We can discuss ongoing maintenance, but we do not assume it, and we will not leave you without documentation of what was built.
How reliable is AI-generated output?
It can be strong but is not guaranteed to be correct. That is why we build review steps and logging into systems where mistakes would matter, and why we test on your real material before rollout.
Can you build something using our private data?
Yes, subject to how the data is stored and which model providers are used. We discuss data handling, access and any regulatory requirements at the start. Your own legal or data protection adviser should confirm what is permitted.
How long does a custom build take?
It depends on scope, data availability and how quickly reviews happen on your side. We give an estimate after scoping and prefer to deliver a small working version early rather than promise a fixed date up front.