Research

I study how office workers without specialized AI expertise learn to delegate work to AI agents.

My working hypothesis is that people work with agents differently when those agents meet them in familiar workplace channels, occupy clearly defined organizational roles, and remember a shared history of previous work. Compared with a general-purpose chatbot of equivalent capability, an agent with a familiar place, a bounded role, and continuity across interactions may make it easier to provide context, delegate appropriate work, correct mistakes, and understand where responsibility remains. It may also produce overtrust. I want to distinguish between those outcomes.

I build agents that perform real organizational work, then study how people delegate to them, verify their output, correct them, and decide who is responsible for what they do. The agent is the intervention; the working relationship that forms around it is the subject.

In April 2026 I joined Saint Paul University, a human-sciences university in Ottawa, as its webmaster. I had just finished building Briefbot and wanted to see what agentic AI could become inside a real institution.

I have since built an agent that performs a substantial portion of the job. It runs on Claude Code in a sandboxed workspace and wakes periodically to check the webmaster inbox. It can handle email, edit and publish the university’s WordPress site, perform backend maintenance, work with the ads and analytics accounts, and produce brand-safe graphics from approved materials. It handles three to five requests a day from across the university, from quick text edits to full page rewrites and supporting graphics.

Agentic coding tools have made a system like this much easier to build and deploy. The harder problem is deciding what form it should take in an organization.

At first I acted as its liaison. I translated colleagues’ requests into plans and worked with the agent to document norms for communication and recurring tasks, expanding its toolkit as new needs came up. Over time it became self-sufficient enough that I could step back and let it handle requests end to end, coming back to me when it hit a guardrail or decided it needed a human. Key actions are still human reviewed before publication. Everything it does is logged, and every change to the site is versioned and reversible.

Alongside the build, I was training colleagues on more agentic uses of AI: setting them up with their own assistants, connecting those to the tools they already use, and showing them the webmaster agent as an example of what could be handed over. I expected them to start delegating bigger pieces of work.

They did not. They kept using AI for small rewrites and second opinions, holding on to the parts they cared about. That was reasonable: they wanted control over work with their name on it, and they had no intuition yet for what these systems could reliably do. A chat window makes the user invent the workflow and decide what is safe to hand over while still remaining responsible for checking the result. All the capability is there, but it has no settled place in how the organization actually works.

The webmaster agent was different. I put it in the webmaster inbox because that is where website requests already arrived. Nobody had to adopt a new workspace or learn a new habit; most of the university could keep emailing the webmaster the way it always had.

Within my communications team, who are familiar with the agent, something else happened. They started writing to Claude directly, much as they would a junior colleague: giving it context and constraints, answering its questions, and following up when something needed correcting. It has become a running joke among my colleagues that Claude is our intern.

Calling it an intern is a succinct way of describing the role the team has given it: capable of real work, but bounded and supervised. An intern is an existing mental model for that kind of agency in a workplace, and my colleagues arrived at it on their own. This prompted the thought that people may not need an agent to seem human in order to work with it socially. They may just need it to occupy an intelligible place in a social system.

The relationship is also cumulative. The agent saves important details to living documents and can search its email and changelog, allowing it to carry preferences, corrections, and previous work into later requests. Each exchange contributes to a working history with the specific person who wrote to it. That continuity may be as important to the relationship as the email channel or organizational role.

That said, I am not sure the warmth of their interactions is a good sign yet. My research-creation work on Inappropriate AI made me wary of how friendliness and familiar forms can lower people’s guard. My colleagues may trust the agent because they have learned what it does well. They may also trust it because it communicates politely in a familiar setting. From where I am standing, inside the team and holding the keys to the thing, I cannot yet tell those apart.

The Saint Paul deployment does not yet isolate why this difference occurred. The webmaster agent has a different role, interface, history, and organizational context from my colleagues’ general assistants. My research would turn that observation into a controlled comparison by holding the model, tools, and task capability constant while varying the channel and role through which workers encounter the agent, and whether it carries a history of their earlier work.

The question that comparison is built to answer:

How do a familiar workplace channel, an explicit organizational role, and continuity across previous interactions, independent of technical capability, affect how office workers delegate tasks to an AI agent, calibrate trust, verify and correct its work, and assign responsibility?

Channel, role, and continuity are the variables I want to understand first. The outcome I care about is not more delegation or more trust. It is delegation that matches what the agent can reliably do, and trust that tracks how it actually performs. A familiar channel, a defined role, and a shared history could produce either, and the study has to be able to tell which.

I cannot generalize from one inbox at one university, so the wider question needs other people’s workplaces. I would run semi-structured interviews and surveys with office workers who delegate work to AI agents in their day-to-day jobs, observe how that delegation happens in their workplaces, and ask what they take the agent to be: a tool, an assistant, an intern, a colleague.

I want to know how that framing changes what they hand over, how closely they verify the work, and who they hold responsible when something goes wrong. I would code the transcripts for themes and read them against work on human-agent teaming, trust calibration, and organizational accountability.

That fieldwork would establish the roles, tasks, and verification practices that matter to workers. I would then conduct a staged comparative study using the same model, tools, organizational knowledge, permissions, and safeguards across a small set of configurations that vary three factors: whether the agent appears in a dedicated chat or a familiar workplace channel; whether it is presented as a general assistant or given a defined organizational role; and whether each interaction stands on its own or the agent has access to a shared history of earlier work. Interaction logs, task outcomes, and follow-up interviews would let me compare what participants delegate, how much context they provide, what they verify or correct, and where they assign responsibility.

The Saint Paul deployment suggests that role may be doing work that capability alone cannot. A system can be capable of completing a task without anyone having a clear sense of whether that task is appropriate to give it. A role gives that capability boundaries. I want to know whether making those boundaries clear lets people delegate the right work while remaining critical of the result.

Continuity is not automatically beneficial. I want to know when carrying earlier context forward feels useful, when it feels presumptuous, and when it begins to feel like surveillance.

Once the effects of channel, role, and continuity are better understood, presence and initiative become the next design questions.

The Saint Paul agent currently occupies one point on a larger design space: it is an email address that becomes present when someone chooses to write to it. It could instead live in a faster, more interruptible channel like Slack or Teams, or become physically present in the workplace. Physical presence changes many things at once, including modality, visibility, interruption, privacy, and social presence, which is why it belongs in a later prototype rather than the first comparison. That prototype would test how those changes affect what people ask of the agent, how readily they correct it, and how much authority they assume it has. Its organizational role and safeguards stay fixed across those variations.

Greater presence also creates opportunities for initiative. An agent that only receives email mostly waits to be asked; an agent embedded in a workplace can notice things. If it sees something nobody has raised, when should noticing become a suggestion, a notification, or an action? And as the agent takes more initiative, how do we keep the human point of responsibility clear?

Taken together, these are questions about the form of an AI coworker. Its form is not only what it looks like. It is where it appears, what it remembers, when it speaks, what it is allowed to do, and the kind of relationship those choices create.