How I use AI in my work

Basis: Daniel Lakens wrote the equivalent piece for his own lab this month, and put the useful question better than I can. From his post: "Some people don't want to use AI at all, but for me, the question is not whether to use AI, but how to use it well." This is my attempt at the same thing, with more emphasis on the parts I refuse to delegate. His post is at daniellakens.blogspot.com.

I run an AI agent as part of my working day. Not a chatbot in a browser tab: an agent harness that keeps notes between conversations, follows written procedures, and reaches my phone.

The approach is roughly independent of the harness. What matters is the pattern, not the product: written procedures, rules kept in files, checks on the output, and a person at the end of every consequential step. I have worked this way in Claude Code and Claude Cowork. I use Hermes Agent now. For inference I mix Nous Portal, OpenRouter and xAI, depending on the job. The harness runs on my laptop and on a virtual server. The server has four cores and 16 GB of memory, so it keeps working when the laptop is shut.

Colleagues ask about it, and some are sceptical, which is fair. I am writing this so my practice is clear enough to argue with. It does not suit everyone. The useful question is not whether to use these tools, but which parts of the work they should touch.

What I actually run

Five parts matter, and all of them are files I can read and change.

Memory. Notes that persist between conversations: my preferences, the projects I am running, the rules I have set. It stays deliberately small, and the agent manages it, so it has to choose what is worth keeping rather than hoarding. Beside it sits my research wiki. It runs to just over three thousand pages, on the people I work with, the projects, the claims behind them and the sources. The agent reads the wiki when a question needs it, and it searches past conversations when something needs finding months later.

Skills. Written procedures, one per kind of job, loaded only when that job comes up. The agent writes and improves them, so a better method changes the procedure and not just that day's answer. They cover research and source digests, citation checking, inbox and calendar work, documents and data, diagrams and design, and the upkeep of the system itself.

Tools, and MCP servers. Tools extend the agent's reach: web search and page extraction, files, the terminal, browser automation, and the ability to send work to other agents. MCP servers are the standard way to plug outside software in. In my setup they give it the wiki and the calendar. Anything not connected stays not connected, and I can see which is which.

Subagents, and the board. Work bigger than one pass gets broken up. Commitments live as cards on a board, one card per job. A card can be assigned to a subagent. That subagent runs separately, with one task, its own workspace and its own acceptance checks. It writes the result back to the card with the run history, and I read the card and accept the result or send it back. Disagreement is built in: one of them is set up to attack a draft before anyone else reads it.

Scheduled jobs. The agent works to a timetable and reports back: the nightly backup, the weekly care of the wiki, the morning sweep of my inbox. Nothing is a surprise later, because the jobs leave records as they go.

One more thing, and it is the part I would tell anyone to start with. The rules are not in my head, they are in files. One file sets the agent's voice and character. Another holds the operating rules: what it may do, what it must never do, and that it overrides everything else. When something went wrong in the first month, the fix was a line in one of those files, not a resolution to try harder.

It is also one of several profiles I keep. Each is a separate agent with its own memory and skills for particular kinds of work, rather than one generalist doing everything.

Why it suits me, and who it would not suit

Two things are true about me. I like efficiency, and I like evidence. This setup rewards both. It turns a messy week into numbered items with the sources attached, and it does not show off at the cost of being right. It also fits the shape of my job. I spend much of the day at a computer, moving information between systems: an inbox, a list of commitments, a wiki, documents, analyses. If your work happens mostly in a room with people, most of this does not apply to you, and you are not missing anything.

Jobs it takes off me

The inbox. My email is a queue of other people's priorities. The agent reads it against my rules and protects the people and projects that matter. Then it gives me a page I can act on: everything numbered, the decision each item needs stated, the evidence named. This morning's sweep turned 272 messages into ten decisions, with the low-value mail filed and the real choices left in front of me. An hour of scrolling becomes ten minutes of deciding.

Watching things. Long jobs fail quietly. Scheduled checks look after the wiki, back the system up every night and verify the archive, and watch for jobs that have silently stopped. One of them recently found a pile of near-duplicate backups and cleared them, after proving the copy being kept was intact. I did not have to think about it, and I did not have to take it on trust either, because every step leaves a record.

Small administration. The real, unglamorous work that piles up: chasing a form, cancelling something, putting together a travel plan with the parking, the charging and the fallback. The least interesting thing on this list, and the highest return in practice.

Checking my own paperwork. Names checked against the actual correspondence, quotations checked as exact strings against the source, dates checked against the record. The least visible thing it does, and the one I would miss most, because it catches my errors as well as its own.

What it lets me do that I couldn't before

A wiki that looks after itself. I keep a research wiki of just over three thousand pages. It holds the people I work with, the projects, the claims and concepts behind them, and the sources. It is not a folder. It has structure, typed links and stages of maturity. Weekly jobs keep it in order. One brings new material in. One checks the structure. One proposes links between pages that should know about each other. One hunts for contradictions and duplication. Nothing becomes settled without me. I have wanted a system like this for years and never had the days to build or maintain it. The obstacle was never the ideas.

Asking harder questions of the evidence. I can ask for a behavioural analysis of a research platform, measured against published frameworks. It comes back as a table I can interrogate. Where the claim matters, the quotation behind it is checked against its source. I can ask what my own system does and get the evidence trail rather than a description of it. What has changed is not my thinking. It is how quickly my thinking meets its evidence.

Drafting without letting go of judgement. Replies and documents arrive drafted, ready for the red pen. What changes is how much of my attention goes on the words rather than on assembling them. The failure mode of machine prose is fluency. It reads well and says very little, and polish does not fix material that was never mine.

What the job becomes

I saw this coming. Through late 2022 and early 2023 it was clear to me what was on its way. The ability to write a grant, and especially the detailed work plan that gets one funded, would stop being the thing my work rested on. So when I took the chair at Sheffield, I moved deliberately. I did the Lego Serious Play training, and I have the materials. I also trained in behavioural systems mapping at UCL. Those two practices overlap, and together they shaped the co-production process I now use.

The change in my own practice was from commissioning facilitators to being the facilitator. I run and facilitate the workshops in large work packages myself. That deeper engagement with people who have lived experience is where much of the meaning in my job now sits. It is also the part no one should automate. A workshop is not an output, it is a relationship. It only works if the person in the room is the person who carries the work afterwards.

So I would put the shift like this. The tasks get cheaper and the judgement gets dearer. What is left for me is the choosing. What is worth doing, whether the result is good enough, and being present for the parts that only count if I did them myself.

Where it goes wrong, and the lines I hold

Making things up is the failure mode, and it arrives fluently. A confident, well-formed claim that happens to be wrong is the most dangerous output of these systems. It is worse in a wiki, where a wrong fact starts to look settled. I do not rely on care for this. I rely on checks: names checked against the actual correspondence, quotations against the actual source, and nothing written down that cannot be traced.

It is worth being exact about the shape of this, because it is not a rare malfunction. This week an analysis reached me carrying nine claims. Four of them needed correction. Nothing was invented on purpose and nothing looked wrong: the errors were fluent, plausible and confident, and the checks found them, not my judgement. That is the ordinary version of the problem. Not a lie, but a confident error produced at machine speed and delivered to me while I am doing something else.

The check has to be independent. A commenter asked a colleague of mine whether the agents that review the work share their context with the agents that wrote it. It is the right question, and in my setup the answer is no. The writer and the reviewer are separate profiles, with separate workspaces and no shared conversation. The card is what passes between them, so the reviewer sees the claim and its evidence, not the writer's reasons for believing it. That separation is by design.

The risk I worry about more is volume. Someone once took a set of materials I had shared and used them to submit thirty-five grant applications in a year. As far as I know, nothing in them was invented. It was still a bad outcome. Reviewers and panels are people with finite time, and a tool that lets you push more work at them does not make the science better. Where the agent helps on a proposal, it helps with the evidence and the structure. The case for the work stays mine, and I decide how much of it goes out.

Some things are simply not delegated. Some lines exist, and they are enforced. The agent will not enter my symptoms or my date of birth on a participant's behalf, whoever asks. The same line covers my signatures, my appraisals, my formal attestations, and anything sent in my name.

It costs money and attention. Between 80 and 135 pounds a month. September was the high month and October the low one, so a range is the honest figure rather than a single number. On top of that sits the setup, and the keeping going. Anyone thinking about this should know that the maintenance is the real cost. A system like this is not a purchase. It is a habit with infrastructure.

There is a quieter risk as well: reading the summary instead of the source, because the summary is easier. My rule runs the other way. If a claim matters, the file it came from gets named, and when a summary has disagreed with the record, the record has won. Every time.

Whose agent it is

One more distinction, because I think it will matter more than the rest within a few years. An agent that runs on my machine, with my keys and my rules, answers to me. An agent that runs on someone else's platform answers to that platform, however helpful it feels, and the difference is invisible from the outside. Same interface, different loyalty.

I would not want an institution to own my agent. A great deal of what it holds is bound up with my own work and my own judgement, and it should go where I go. So I keep mine: my files, my keys, my rules. That is also why I can write a piece like this one. I know where the material sits, because I put it there.

What I tell students

My position on students' use is my own. AI-assisted work is acceptable as your own work, and you remain responsible for whether it is true. Fabricated references are the offence, and using the tool is not. What is written down in my own department is narrower. It is Sheffield Psychology's policy for one module, PSY6232, written for the 2025-26 cohort and retiring on 15 November 2026. That standard is the one I would defend in a viva or a misconduct panel.

If you are starting, three things. Pick one bounded job you do every week and can check in five minutes. Keep the accountability on your side of the line, always. And write your rules down before the tools get good enough to tempt you. The habits form in the first month, not the first year.

If someone asks to copy it

Colleagues do ask, and a few are building something similar. The part worth passing on is not the machinery. It is the rules: what must never be automated, what gets checked, and how much output is reasonable to produce.

One person I have been corresponding with put the volume question better than I had. He would rather write a small number of good applications than dozens of poor ones. What he asked for was a set of rules of engagement rather than a template. That is the right instinct. It is the conversation I would want to have before anyone borrows this approach, and the thing I would hold them to.