The gap between approval and arrival
Approving a permanent AI engineering role is the easy part. Writing a credible profile, finding candidates who have shipped AI systems rather than demos, interviewing them, waiting out a notice period and onboarding them takes months. Meanwhile there is a project with a deadline: a customer commitment, a board milestone, a pilot that needs to become a product.
Interim contractors are the obvious answer and a common source of regret. The contractor delivers, leaves, and the permanent engineer arrives to a system they did not build, with documentation written for nobody in particular and decisions whose reasons left with the contractor. The bridge role is designed the other way round: the successor is the main customer of everything I write.
What the work involves
The bridge has three strands running together.
Delivery. I work the project under your engineering manager, in your repositories and review process, exactly as in any other contract. Priorities are yours.
Documentation for a named reader. Everything is written for the incoming engineer: why the system is built the way it is (decision records), how to run and change it (runbooks), where the risks are, and what I would do next. One of your engineers reviews it as it is written, which tests whether it makes sense to someone who did not write it.
Helping you hire. Because I am doing the work, I can describe it accurately. I draft the role profile with your hiring manager and talent partner, and a practical technical exercise based on real problems from the project. If you want, I join technical interviews and write evidence against agreed criteria. I do not make hiring decisions and do not take part in automated screening; the decision is always your hiring manager’s.
The signature deliverable
You end with a bridge remit, hire-ready documentation and a successor transition plan. The transition plan is what separates a bridge from an ordinary contract. Illustrative example:
| Phase | Successor | Me | Exit test |
|---|---|---|---|
| First week | Reads system guide, sets up environment, shadows | Walks through architecture and open risks | Successor can run the evaluation suite alone |
| Weeks two and three | Pairs on two backlog items | Leads changes, explains decisions | Successor ships a change with my review |
| Week four | Leads changes | Reviews and answers questions | Successor handles a simulated incident from the runbook |
| After overlap | Owns the system and backlog | Available for agreed follow-up questions only | Manager signs off the transition |
Illustrative example showing the format, not a record from a client engagement. The overlap length depends on the system and is agreed once a start date is known.
How acceptance is judged
Delivery work is accepted by your manager through normal review. The handover is accepted against the exit tests in the transition plan, signed off by your manager. Hiring support is judged by your hiring manager and talent partner: whether the role profile attracted the right candidates and whether interview evidence was useful.
Ownership and handover
The system, the documentation and the hiring decision are yours throughout. By the time I leave, your permanent engineer has shipped changes on the system, handled a simulated incident, and has a first-month plan written with your manager. If you later want a formal ownership review of a whole system, the AI system handover service covers that.
When to choose something else
If there is no successor in view and the work simply does not need a full-time person, use part-time AI engineering capacity. If you need someone to build and lead a team rather than bridge one role, that is a leadership engagement such as fractional AI CTO. If you already know the specific area of work, the contract roles overview compares the role pages.