AI consulting

What this actually is

In short: AI consulting should answer three questions: which of your problems AI can genuinely address, what it would take to do it properly, and which ones it cannot help with. The third is the one that earns the fee, and the one most engagements avoid.

We come at this from delivery rather than from strategy. Every recommendation is one we could implement, which constrains the advice usefully — it is much harder to recommend something unrealistic when you would have to build it.

What we do

1. Opportunity assessment

   Where AI would change a number that matters, and where a rule or a process change would do the same for less.

2. Feasibility

   Whether your data supports it, at what accuracy, and what that accuracy is worth once error handling is included.

3. Sequencing

   What to do first — normally the one with a clear metric and a contained blast radius, not the most ambitious.

4. Build plan

   Architecture, integration and operating requirements, at enough detail to be costed by us or by anyone else.

The stack

• Python
• LangGraph
• PyTorch
• Vector databases
• OpenAI / Anthropic / open-weight models
• MLflow

What it connects to

Integration surface is the honest driver of effort — ten systems is not ten times one system.

• Your existing data warehouse
• Model providers — OpenAI, Anthropic, open-weight
• Experiment tracking and evaluation tooling
• The systems any recommendation would touch

How a project runs

Where teams use it

When this is the wrong answer

Proof

Frequently asked questions

• Will you tell us not to use AI?↓

  Regularly. A rule engine, a process change or a better-configured existing tool is often the right answer, and saying so is why the assessment is worth commissioning.

• Do we have enough data?↓

  For a narrow, well-defined problem, usually more than expected. For a broad one, rarely. Establishing which of the two you have is part of feasibility rather than something to assume.

• Do we have to build with you afterwards?↓

  No. The plan is detailed enough for your own team or another vendor to cost and execute. An assessment that only works if we build it is a sales document.

• Who owns the code?↓

  You do, from the first commit — work happens in your repository under your licence, and the contract assigns IP outright. We keep no rights and build no dependency that makes leaving expensive.

• What does it cost?↓

  We do not publish a number, because the honest one depends on scope, integrations and the accuracy bar. Tell us the budget you are working with and we will say what it buys — or say plainly if it does not buy enough.

• How long does an assessment take?↓

  Two to four weeks depending on how many processes are in scope. Shorter than that is a workshop rather than an assessment, and it will not have tested feasibility against your actual data.

• Will you tell us if a competitor tool is better?↓

  Yes. If a product already does what you need, buying it is cheaper than building it, and saying so is the point of asking someone who would otherwise take the build.

• What if our data is not ready?↓

  Then the first project is data engineering. That is a less exciting answer than an AI roadmap and it is frequently the correct one — a model is only as good as what reaches it.

• Can you help us evaluate vendors?↓

  Yes, including writing the technical questions and reviewing the answers. It is one of the more useful things we do, and it does not require us to build anything.

• How do we start?↓

  A scoping call, then a short written proposal with scope, sequence and the assumptions it rests on. If we think you should not do this, or should do a smaller version first, that is what the proposal says.

• Can our team take it over afterwards?↓

  That is the intended end state. Standard technology, decisions documented as they are made, and handover sessions with your engineers. If a system can only be maintained by us, we built it wrong.

Related

Before you choose anyone

Written to be useful whether or not you hire us — including the parts that argue against hiring an agency at all.