What you are hiring
A contract with me buys one thing: my time as a senior AI engineer inside your team. I report to the manager you name, work your sprint cadence, commit to your repositories through your review process, and follow your security and data rules. Priorities, product decisions and the backlog stay with you.
That is a different purchase from commissioning a project. In a scoped delivery engagement I am accountable for an outcome against acceptance criteria. In a contract, your manager directs the work and accepts it change by change. If you cannot spare a manager to direct an engineer, a scoped delivery service is usually the better buy, and I will say so in my reply to your brief.
Who performs the work
I do, personally. This is not a staffing bench and there is no account manager between you and the engineer. The CV you assess is the person who joins your stand-up.
Occasionally a piece of work would go better with a specialist alongside me, for example a security reviewer for an access-control change or a front-end engineer for an internal tool. When that happens, I name the person, share their background, confirm their availability, and ask for your written approval before they start. They work under the same remit and data rules. If you say no, the work stays with me. Associate capacity is never implied in a proposal and never substituted for my time.
How to pick the right role
The table below compares the role pages. Each describes responsibilities, typical work, stack fit, onboarding needs and reporting for that kind of work. Pick the one closest to your backlog; if your requirement spans two (LLM integration plus retrieval, say), name both in the brief. If what you need is recurring senior input a few days a week, start from part-time AI engineering capacity. If you are covering a gap until a permanent engineer joins, use the interim bridge role, which includes helping you hire and onboard the successor.
Assessing fit before anything is signed
Ask for what you would ask of any senior hire, and a little more:
- A current CV with dates, roles and what I personally did in each.
- Work you can inspect: published code, written technical guides, or a design discussion about your actual problem.
- A design conversation on your hardest issue. Framework names in a job spec matter less than how an engineer reasons about state, failure, permissions and evaluation.
- A dated availability statement for your start window and working pattern.
The contractor selection checklist turns these into questions you can use with any candidate, including me.
Sending a brief directly
You do not need to buy a workshop, discovery phase or strategy call to start. Use the form on this page, or build a fuller brief with the engineer brief builder. The useful parts are: what the engineer should own, who they report to, the systems and data involved, the start window and duration, the working pattern, and your location, time zone and contract route. A rough brief is fine. I reply with questions, a plain view on fit, and an availability window checked against the brief.
Contract basis
I contract directly, through your preferred agency or contract desk, or through a delivery partner already working with you. If you are a recruiter with an approved vacancy, the recruiter route explains how representation works. Your organisation makes the IR35 or equivalent employment-status determination. I will describe the working practices honestly so your determination reflects them, but I do not give tax advice. Day rate and terms are shown in the engagement model on this page.
Working patterns
Contracts run in one of a few patterns: full-time for a defined period, three or four days a week, one or two fixed days a week, or a fixed block of days for a specific piece of work. Fixed patterns matter more than total hours. A team that knows I am in on Tuesdays and Wednesdays can plan reviews and decisions around it. Working-hours overlap and any on-site days are confirmed in the brief, not assumed.
Onboarding and handover
Onboarding runs through your normal joiner process: laptop or approved device, repository and environment access, a named manager, and the first piece of work agreed for the opening weeks. I send a short written update each week covering what changed, what is blocked and what is next.
Handover is planned from the start, not left to the last week. I pair with your engineers on the hard changes, write decisions down where your team keeps them, and finish with a written handover: what was built, how to run and change it, known risks and the remaining backlog in priority order. If you want a formal ownership transfer for a whole system, the AI system handover service covers that.
When a contract is the wrong vehicle
If you need an outcome delivered and accepted rather than capacity, commission a scoped service. If you need several engineers at once, a consultancy or delivery partner is the honest answer. If you need someone with authority over teams and budget, that is a leadership appointment, and the contractor versus consultancy guide sets out the trade-offs.