The systems we build, and how they're put together.

The problem. Institutional knowledge is spread across a wiki nobody maintains, six years of tickets, a shared drive and the heads of four people. New joiners take months to become useful, and those four people are interrupted constantly.

How we build it. Hybrid retrieval — semantic plus keyword — across the real sources, with permission filtering applied at query time so answers never cross a boundary the asker couldn't cross themselves. Reranking before generation, citations back to source documents on every answer, and an explicit "I don't know" path when retrieval confidence is low.

What's actually hard. Not the retrieval. It's document freshness, contradictions between sources that were never reconciled, and permissions — the moment an assistant surfaces something from HR or legal to the wrong person, the project is finished. We design the permission model before the retrieval pipeline.

The problem. A team keys data from contracts, invoices, claims or application forms into a system. It is slow, it is expensive, and the error rate is quietly higher than anyone reports.

How we build it. Structured extraction with a strict output schema, per-field confidence scoring, and a routing rule: high confidence goes straight through, anything below threshold lands in a review queue with the source document and the proposed values side by side. Reviewer corrections flow back into the evaluation set, so the threshold can be raised deliberately over time.

What's actually hard. Deciding where the automation boundary sits. Chasing full automation on the long tail of malformed documents usually costs more than the manual handling it replaces. The economics almost always favour a high-confidence fast path with a well-designed review queue behind it.

The problem. Inbound volume — support tickets, applications, leads, incident reports — is classified and routed by hand. It is repetitive work, it happens on a delay, and consistency depends on who is on shift.

How we build it. Usually the least glamorous architecture on this page and often the highest return. A small, cheap model handles classification against a taxonomy built from your historical data; a larger one is called only for the ambiguous minority. Deterministic rules handle everything with a clear signature, because a regex is faster, cheaper and more reliable than a model when the pattern is unambiguous.

What's actually hard. The taxonomy. The categories teams believe they use and the categories present in their history are rarely the same set, and cleaning that up is most of the project. Expect to renegotiate the label set at least once.

The problem. A multi-step process — reconciliation, onboarding, procurement checks, renewals — requires reading across several systems, making a judgement, and then acting in a third place. It is too variable for a fixed script but too repetitive to keep consuming senior attention.

How we build it. A deterministic state machine as the skeleton, with model calls at the specific points that need judgement. Every tool the agent holds is scoped to least privilege. Actions above a value threshold pause for human approval. Everything is traced and replayable, spend is capped per run and per day, and there is a kill switch that doesn't require a deploy.

What's actually hard. Resisting the pull toward full autonomy. Open-ended agent loops demo beautifully and behave unpredictably at the tail. Explicit control flow with narrow model calls is less impressive to watch and considerably more likely to still be running in a year.

The problem. Business questions queue behind a small analytics team. Answers arrive days later, by which point the decision has usually been taken without them.

How we build it. Natural language onto a curated semantic layer rather than raw schema. Generated queries are validated and cost-estimated before execution, run read-only against a replica, and results are returned with the query shown so an analyst can verify what was actually asked. Common questions are cached and promoted into a maintained library.

What's actually hard. Confident wrong answers. A plausible number with no visible provenance is worse than no number at all. The semantic layer, the visible query, and a genuine refusal path when the question can't be answered from the available data are what make this safe to put in front of decision-makers.

The problem. Something was built — internally or by a previous supplier — and it is in front of users. Quality is unpredictable, the bill is rising faster than usage, and nobody is confident enough to change the prompt.

How we build it. Instrumentation before opinions. Tracing on every call, cost and latency attributed per feature, failure modes categorised from real traffic. Then the eval suite that should have existed from the start, built from production data. Only then do we change anything — and every change is scored against that suite.

What's actually hard. Usually nothing technical. It's establishing what "better" means when the original success criteria were never written down, and re-earning user trust that a bad launch already spent.