Thepersononyourcallwritesthecode.

Gael Hatchue

founder · engineer · writer

The AI consulting market right now feels like the '.com agency' market in 1999. A lot of people with brand-new business cards, a lot of demos that don't survive contact with real data, a lot of 'transformation' decks. The honest version is much smaller and much more boring: scope the use case carefully, build the eval first, ship the simplest thing that works, and instrument it so your team can keep it alive after I leave.

Where I'm coming from

I currently work on AI security at a large fintech. Specifically, on the authorization rails that decide which AI agents are allowed to access which data, on behalf of which user, under which conditions. It's not the part of AI that gets keynote demos. It's the part that, when it's missing, makes a “production agent” not a production agent.

Before that I spent six years at Google. I led the rewrite of YouTube's video ingestion infrastructure, a system that had grown for a decade processing every upload. I led an ML-assisted data packing project on Google Cloud Storage that saved roughly $10M a year in operating costs (US Patent 11263128). I built the new storage test infrastructure that 60-plus teams ended up using.

I mention this not to wave a resume around. I mention it because the work that actually matters in production AI is less about clever prompting and more about the kind of engineering you'd recognize from any high-reliability distributed system: idempotency, retries that respect server hints, structured error budgets, observability that survives the long tail, deprecation campaigns coordinated across fifteen teams.

That's the muscle. The model is the new part. Almost everything else is the same job we've been doing for twenty years.

What I actually see in the field

Across enough engagements you start to see the pattern. A team has a great demo. The CEO is excited. The engineering team is vaguely uncomfortable. Someone on the team has run the demo against real data and it failed in ways that aren't easy to explain. Now there's a planning meeting, and the question on the table is: do we ship this, or do we go back to spreadsheets.

The honest answer most of the time is: don't ship this version, and don't go back to spreadsheets either. Ship a smaller, less impressive version that you can actually evaluate. Add the eval harness before you ship it. Wire monitoring before you write the press release. Pick a metric that is unambiguous, and refuse to declare success until that metric moves.

This is unsexy advice. It's also the difference between a system that's still running in eighteen months and one that gets quietly deprecated after six.

Why Airely exists

A few reasons. The first is vantage. Working on AI authorization rails inside a large fintech is a privileged seat on what AI looks like at scale. I see the patterns that will become consensus advice in two years. Some of that knowledge is useless outside that environment. A lot of it is exactly what a smaller company building its first agent should hear.

The second is pattern density. I lecture for the GSK Biopharma 4.0 program at the Jefferson Institute on applying ML and data analytics to bioprocess design. Different industry, same conversation: “we've been told AI will help. We're not sure where to start. We don't want to waste a year.” The conversation is the same in pharma, in fintech, in support ops, in legal review, in field service. The vocabulary is different. The failure modes are not.

The third is shape. I previously co-founded a consumer product, KARL, with two HBS-grad co-founders. I learned I'm much better as the technical co-founder than the marketing one. I also learned that small focused engagements where the deliverable is a working system (not a deck and a roadmap) are the kind of work that compounds when you take a small number of clients at a time and give each your full attention. Hence Airely.

What I won't do

I won't pitch you AI transformation. I don't know what that means and neither does the person selling it.

I won't take an engagement where we can't agree, in writing, on what “done” looks like. If we can't define done, we can't evaluate it, and if we can't evaluate it, we can't tell whether we shipped something useful.

I won't quietly extend a fixed-scope sprint because new things came up. New things always come up. They go through written change-orders or they go in the next engagement. This is a practice I borrowed from twenty years of contract distributed-systems work, and the only customers who object to it are the ones who were planning to scope-creep.

I won't take more engagements than I can give full attention to. Airely is by design a small practice. I run a short list of clients concurrently, not a queue. If we're not a fit for the current window, you'll get a straight “not now” rather than a soft maybe.

I won't sell you a model when what you need is a workflow tool. The most common deliverable I produce in a discovery sprint is “you don't need AI for this; here is the n8n flow that solves it.” Some clients are disappointed. The repeat business comes from the disappointed ones.

What I'm betting on

The agent reliability problem is going to define the next several years of production AI work. The current state of the art is somewhere between “honest” and “pre-discipline.” We don't yet have the equivalent of Twelve-Factor App for agents. We don't have a standard observability spec. We don't have agreed-upon SLOs. The compound failure math, where a 10-step agent at 95% per-step reliability fails end-to-end roughly 40% of the time, is widely cited and widely ignored.

The discipline that closes that gap looks unglamorous: eval harnesses, structured tool I/O, deterministic test fixtures, idempotency keys on every side effect, telemetry that distinguishes “the model gave a wrong answer” from “the network ate a tool call,” authorization rails that scope what an agent can actually do.

This is the work I find interesting. It's also the work that, if you skip it, will quietly defeat your AI initiative regardless of which model you picked.

The offer

If any of this resonates, three doors.

The Opportunity Sprint is one week, fixed price, fixed scope. We map the highest-leverage AI use cases against your actual data, evaluate feasibility, and either deliver a fixed-price build proposal or an honest “don't build.” Either way you keep the deliverable.

Or read the writing — it's where the methodology lives in long form.

Or get in touch. I read every message.