Service
AI Consulting and Strategy
We audit your operations, find the work a model can do reliably, and return a costed plan with the systems, data and controls each use case needs.
The problem
What usually goes wrong
Most businesses arrive at AI with a tool in mind rather than a problem. Someone has seen a demo, a competitor has announced something, and the question becomes "where do we put AI" instead of "which part of our week is expensive and repetitive".
That order produces pilots that never ship. The model works on a clean example and fails on the real inbox, because nobody mapped where the data lives, who checks the output, or what happens when the answer is wrong.
An AI strategy engagement puts the analysis first. We look at the work, not the tooling, and we are equally willing to tell you that a use case belongs in a rules engine rather than a model.
Scope
What we deliver
Operational audit
We sit with the people doing the work and document the actual path a job takes through your business, including the spreadsheets and group chats that are not in any system diagram.
Use case shortlist
Every candidate gets scored on volume, error tolerance, data availability and the cost of a wrong answer. The ones that survive are the ones worth building.
Data readiness review
A model is only as good as what it can see. We check whether the documents, records and history a use case needs are reachable, current and clean enough to retrieve against.
Architecture and model plan
For each shortlisted use case we specify the pattern: retrieval over your documents, a tool calling agent, a classifier, or ordinary code. We name the model class and the fallback.
Controls and review design
Where a human must approve output, we design that step into the workflow rather than bolting it on. Logging, evaluation sets and escalation paths are part of the plan.
Costed delivery roadmap
A sequenced plan with fixed scope for the first build, the integrations it needs, and what each later phase depends on.
Method
Technical approach
We start from the ledger of work rather than the model catalogue. A task is a candidate when it is high volume, has a checkable output, and the inputs already exist in a system we can read.
Retrieval quality decides most outcomes, so the data review is detailed. We look at how documents are stored, whether they carry usable metadata, how often they change, and whether chunking them will preserve meaning.
We build a small evaluation set during the engagement, drawn from your real cases, so that any later build can be measured rather than demonstrated. Without that set, "it seems better" is the only available verdict.
Model choice follows the constraint, not the other way round. Latency sensitive classification, long context summarisation and tool calling agents have different requirements, and some work belongs on a private or on device model because the data cannot leave your environment.
Every recommendation states what happens when the model is wrong. If there is no acceptable answer to that question, the use case does not make the list.
Handover
Deliverables
Everything below is yours at delivery, including the intellectual property. Sawhorse keeps nothing.
- 01Written operational audit covering the workflows in scope
- 02Scored use case shortlist with the reasoning for each accept and reject
- 03Data readiness report per use case, including gaps and the work to close them
- 04Reference architecture for each recommended build
- 05Evaluation set drawn from your own cases
- 06Human review and escalation design
- 07Sequenced delivery roadmap with fixed scope for the first phase
- 08Presentation of findings to your team, with the working documents handed over
Related
Systems this service builds
- AI Agents and AssistantsAssistants embedded in your product or operation that answer from your data, take scoped actions through typed tools, and escalate to a person when they should.
- Workflow Automation PlatformsAn orchestration layer that runs your cross system processes with retries, visibility and controls, instead of scripts on a laptop and rules in one person email client.
- BI Dashboards and ReportingAgreed metric definitions, modelled tables and a small number of views tied to decisions, so a meeting argues about the action rather than the number.
FAQ
Questions people actually ask
Do we need to have our data in order before you start?
No. Finding out what state the data is in is part of the work. The readiness review tells you which use cases are reachable now and which need a data fix first, with the size of that fix written down.
Will you tell us not to use AI?
Often. A lot of work that looks like an AI problem is a missing integration or an unenforced process. We say so, and the roadmap then recommends the cheaper fix.
Can you work with a model we already pay for?
Yes. If you have a provider agreement in place, the plan is written against it. Where a different model class would clearly do better on a specific use case, we say that and explain the tradeoff.
What if our data cannot leave our network?
We specify private or on device model options for those use cases. The architecture then keeps the documents inside your environment and only the application layer talks outward, or nothing leaves at all.
Who owns the outputs of the engagement?
You do. The audit, the architecture, the evaluation set and the roadmap are yours at delivery, with no restriction on using them with another engineering team.
How long does a strategy engagement take?
It depends on how many workflows are in scope and how many systems hold the data. We fix the scope and the schedule in writing after the discovery call, before any work starts.
Let’s talk about the system you need.
Tell us where the current process breaks down. We can map the workflow, examine the integration requirements and define a practical scope for the build.
- A mutual NDA is signed before project details are shared.
- Scope is fixed in writing before any build starts.
- You own the source code, the IP and the documentation at delivery.
- Support plans are available and tailored on a discovery or technical call.