You have one seat and two candidates: you, or the person who actually does the work. Most of the material written about choosing AI training answers a different question - whether to bring a day in-house, or which format to pick - and then describes who the day is for in job titles. That does not settle it, because the job titles usually fit both of you.
The question is normally asked as a seniority question. Seniority is the wrong axis.
A build day sorts by task ownership, not rank
On a day where you build something, the thing being built has to belong to someone. The Oxford Agentic Bootcamp runs against one real task that the attendee brings from their own work, and its own “Who is it not for?” answer is blunt about the consequence: anyone who cannot bring a real task should not come, because without one you get a demonstration instead of an outcome.
That single constraint does most of the deciding for you. The seat should go to whoever arrives with a genuine task, not to whoever would normally be sent to Oxford.
Three questions that settle most cases
Whose morning does the task eat? Not whose budget, whose morning. The person who personally loses the time pays a different kind of attention to getting it back, and they already know where the task is awkward - the exceptions, the bit that always needs checking, the file that is never where it should be. Someone describing a colleague’s workflow from memory finds that out at 11am, in the room, with the day running.
Who can change how it is done on Monday? If the person who goes has to ask permission to alter the process afterwards, the day produces a recommendation rather than a change. Recommendations go in folders. This is the question that most often sends the seat upwards, and sometimes it genuinely should.
Who will build the next one? What transfers from the day is not the workflow, it is the pattern behind it - a step that gathers, a step that produces, a step that checks. The first workflow only ever covers the task you brought. The pattern is what makes the second and third ones happen without help, so the seat is worth more to someone who will keep using it than to someone who wanted to see what this is about.
When all three point at the same person, that is who goes, whatever the org chart says.
When it should be you
Go yourself if the decision in front of you is not “can this task be faster” but “is this how we are going to work”. Those are different decisions, and the second one is hard to make from a write-up.
In Cohort 1’s room the afternoon was adoption and governance: the five-level journey from a personal assistant up to autonomous systems, worked through on compliance review and marketing analytics, and where data integrity and risk sit. That material is aimed at whoever will have to decide how far the organisation goes, and how it will know when a workflow has gone wrong. If that is you, send yourself.
The other honest reason to go yourself: if you have approved AI spending without ever having built anything, a day spent building recalibrates what you ask for. It is much harder to be sold something afterwards.
When it should be them
Go the other way if the answer to “whose morning” is plainly someone else’s. The tasks that surfaced in Cohort 1 were lead generation, internal reporting and marketing content - in most organisations, none of those three sit with the chief executive.
If you do delegate the seat, delegate the decision with it. Agree before they go what they are allowed to change when they come back, and who they need to tell rather than ask. A workflow built by someone who then has to campaign for permission to use it is a day half spent.
Two of you, and what to do when there is only one seat
If you can send two people, the programme page’s own advice is to bring the same task, so the same workflow goes back to work with both of you - and teams do get more out of the day than individuals. Email hello@oxfordagentic.com and that can be arranged. It is also a better answer than sending one person this year and another next: two people who have built the same thing can keep it working between them.
With one seat, the owner of the task goes, and you book an hour in the same week to be shown the thing running. Not a summary, not slides. If it cannot be demonstrated, it was not finished, and you want to know that in week one rather than in the quarter when you assumed it had been adopted.
The two ways this goes wrong
Sending someone with no task of their own. Usually well meant - the person with the most available diary, or whoever has capacity that week. They spend the day on a hypothetical, and nothing comes home. The day is not a briefing, and the published “not for” list says so.
Not checking the laptop. A device that blocks new tool sign-ups is a real problem on a build day, and corporate and government machines often do. This is worth checking about your candidate before you decide who goes, not at 09:30 on the day - and if theirs is locked down, that is worth raising when you book rather than discovering in the room.
If the honest answer is “both, for different reasons”
That usually means there are two tasks and one ambition, and it is worth saying out loud which one the day is being bought for. Deciding whether to adopt something and getting a specific morning back are both good reasons to spend a day. They are just not the same purchase, and a seat bought for the first while hoping for the second tends to deliver neither.
The next cohort runs on 19 November at Worcester College. If you are still deciding between sending a few people and bringing a day in-house, that comparison is a separate one and worth settling first.