Strategy, design & growth
AI strategy & enablement
Audits, feasibility work and the unglamorous question of which use case actually pays. We would rather tell you in three weeks that something is not worth doing than in six months, and we will say so plainly.
- Opportunity audits
- Feasibility spikes
- Build vs buy
- Data readiness review
- Governance & policy
- Team enablement
What we build
- Opportunity audit
- Use cases ranked by value, feasibility and the data you actually have.
- Feasibility spike
- A throwaway build of the riskiest assumption, scored against a real set.
- Build-versus-buy analysis
- An honest comparison including the cost of operating whichever you pick.
- Data readiness review
- What exists, what is usable, what is missing and what it takes to fix.
- Governance and usage policy
- Approval paths, acceptable use, provider terms and how you review what ships.
- Team enablement
- Working sessions that leave your engineers able to build the next one.
Problems this solves
- Problem
- There is a long list of AI ideas and no way to choose between them.
- Approach
- Score each against value, feasibility and data readiness, and spike the top one before committing to it.
- Outcome
- A ranked list with evidence behind the ranking, and a defensible first project.
- Problem
- A pilot impressed everyone and then never reached production.
- Approach
- Work backwards from the production requirements — evaluation, latency, cost, integration and ownership — and re-scope from there.
- Outcome
- The next build is sized for deployment rather than for a demonstration.
- Problem
- Nobody has agreed what data may go to which provider.
- Approach
- Write the usage policy, classify the data, check provider terms and set the approval path before anything ships.
- Outcome
- Teams can move quickly because the boundaries are written down rather than guessed at.
How we approach it
Discover
We map candidate use cases against the data you actually have, and score value and feasibility together. Half the list usually falls away in the first fortnight, which is the point of doing it.
Design
The strongest candidate gets a throwaway spike with a threshold agreed in advance. Deciding what good enough means before seeing the result is what makes the answer worth anything.
Engineer
The spike is built to be discarded and measured on your data rather than a public benchmark. It exists to produce a number, not a demo.
Evaluate & harden
We report the score against the threshold, including when it misses. A recommendation not to build carries the same detail as a recommendation to build.
Launch & operate
You keep the eval harness, the usage policy and a team that can run both. The deliverable is a decision your board can read, with the evidence underneath it.
What we build it with
The eval that ends a feasibility spike: real labelled records, one score, and a threshold agreed before any of it was written.
"""Three weeks to a number, not six months to an opinion."""
import braintrust
# Agreed with the client before any of this was written down.
GO_THRESHOLD = 0.85
def exact_match(output, expected):
return {"exact_match": float(output.strip() == expected.strip())}
result = braintrust.Eval(
"claims-triage-feasibility",
# Real records, sampled and labelled by their team. A
# synthetic set measures the set, not the use case.
data=load_labelled_sample(n=300),
task=lambda row: classify(row["claim_text"]),
scores=[exact_match],
)
score = result.summary.scores["exact_match"].score
verdict = "go" if score >= GO_THRESHOLD else "not yet"
print(f"accuracy {score:.3f} ({verdict})")
# If it comes in under the threshold, the deliverable is the
# reason why, and a recommendation not to build it yet.Languages
- Python
AI models & providers
- Anthropic Claude
Observability & evaluation
- Langfuse
- Braintrust
- Ragas
- OpenTelemetry
Questions we get asked
What do we get at the end of an audit?
A ranked set of use cases with the reasoning shown, a data readiness assessment, an architecture sketch for the recommended first build, an estimate, and a risk register. Enough to make a funding decision, and short enough that people read it.
Will you tell us not to build something?
Regularly, and it is usually the most valuable thing in the engagement. A feasibility spike that fails in three weeks has saved you a quarter. We would rather lose the build than deliver something we do not think will work.
Can you train our team rather than build it for us?
Yes. Working sessions on evaluation, prompt and context engineering, retrieval design and the operational side, run against your codebase and your data rather than a generic curriculum. Many clients do this alongside a first build.
How long does this take?
An audit is typically two to three weeks as a fixed-scope AI Sprint, including a spike of the riskiest assumption. Longer than that usually means the question is really several questions, and we would rather split them.
Tell us what you are trying to ship.
A first call is 30 minutes and costs nothing. Bring the problem rather than a spec — the useful part is usually working out whether this is the right shape of solution at all.
contact@algologix.coWe reply within 24 hours.