Fractional AI platform architect & technical lead

The problem this solves

A programme with a budget, a mandate and nobody who owns the architecture. The decisions still get made. They get made by whoever is in the room: the loudest vendor, the team with the nearest deadline, or the last proof of concept that happened to work.

A permanent hire fixes it eventually. Two quarters of search, notice and ramp is the usual cost, and most of the decisions that shape the platform are taken before that person arrives.

How the engagement runs

A standing cadence, so the ownership is real rather than an advisory line on a slide.

Architecture ownership
We hold the target architecture and the trade-offs behind it, and we are answerable for them the way an employed lead would be.
A weekly decision log
Each decision, the options weighed and the reason for the one taken, written down and dated. It is the artefact that outlasts the retainer.
Review of work in flight
Technical review of what your teams and your suppliers are already building, so a problem is caught while it is still a design question.
Vendor and model decisions
Which model, which platform, and where the build-versus-buy line falls, with the production evidence behind each choice stated rather than asserted.
Enablement
The point of the engagement is that it ends. Your engineers take the architecture, the log and the operating model, and run them without us.

What you are left with

An architecture and a decision record your own team can defend to a board, to an auditor or to the next supplier, and engineers who helped write both.

A written handover, so the end of the retainer is a date in the contract rather than a cliff.

When it is the wrong choice

When the problem is already scoped, a fixed-scope engagement is cheaper and faster. A feasibility sprint settles what to build; an architecture and production build ships it. Both are priced against a defined output, which a retainer is not.

It is also the wrong shape when what is missing is capacity rather than ownership. That is a contract for embedded engineers, and it has its own page below.

What you get

Target architecture, owned and kept current
A dated decision log covering vendor, model and build-versus-buy choices
Technical review of work already in flight
Delivery governance: gates, review points and release criteria
Enablement so your own engineers take the architecture over
A written handover at the end of the retainer

Start here if

A funded AI programme with no single owner of the architecture
Vendor recommendations are the only technical opinion in the room
A permanent platform lead has been open for a quarter or more
Work is in flight and nobody senior is reviewing the design

Frequently asked questions

How much of the week does a retained architect hold?

Typically two to three days a week, under one statement of work. The shape matters more than the total: ownership that only appears at an escalation is advice rather than ownership, so the days are a standing cadence.

Who makes the final call on a model or a vendor?

You do. We hold the decision, set out the options and the reasoning, and put a date on it. What that buys is a record you can defend a year later, and an argument settled on evidence from production rather than on who presented last.

What stops this becoming a permanent dependency?

The enablement sits inside the engagement rather than after it, and the handover is written as we go. Your engineers hold the architecture and the decision log alongside us, so the end of the retainer is a date rather than a risk to manage.