Research

I study how organizations that cannot program come to work with AI agents. The question I keep returning to: how do non-technical workplaces develop trust, communication norms, and accountability around agents that act more like coworkers than tools?

I am the webmaster of Saint Paul University, a human-sciences university in Ottawa, and I have been automating my own job description. A custom MCP server and agent harness give an AI agent a sandbox and tools for end-to-end work: reading staff requests from a shared inbox, producing graphics inside approved brand constraints, and editing the university’s website. My colleagues cannot program and do not need to. They forward an email and get finished work back.

What interests me is not the automation but what forms around it. Colleagues address the agent with more warmth than they show the chat interfaces they already know. They are deciding, in real time, what to delegate, what to double-check, and how to speak to a coworker that is not a person. The deployment went live in 2026 and I have watched it from inside since the first request — the norms around it are still forming, which is what makes it valuable as a field site.

My observations so far are unsystematic — things I notice because I built the system and sit beside its users. The study that would make them systematic deliberately avoids the software: semi-structured interviews with the colleagues who delegate to the agent, about how they describe it, what they would never hand it, and when they check its work. The object of study is the humans’ language and trust behaviour, not the system. Thematic analysis, read against the literature on human-agent collaboration. Before it counts as more than design research, it runs under institutional research-ethics review.

The deployment also poses an interface question best answered by building. The agent lives in an inbox, but the university is an in-person workplace, and the plausible next step is an agent with a desk: a microphone, a screen, a place people walk up to. Should an always-available agent listen ambiently, or wait to be addressed? When it notices a problem nobody asked about, when should it speak? Those questions sit under the same research question as the interviews, approached from the artifact side.

This work leans on an established vocabulary. Research through design names how the probes above produce knowledge (Frayling, 1993; Zimmerman, Forlizzi & Evenson, 2007). Research products describes prototypes finished enough to be encountered as things rather than demos, the way the Date-O-Meter cabinet and the binocular portals were exhibited (Odom et al., 2016). Autobiographical design covers the system I built and work alongside every day (Neustaedter & Sengers, 2012). This page is an annotated portfolio (Gaver & Bowers, 2012), and its annotations borrow Wobbrock and Kientz’s contribution types (2016) to say plainly what each project is and is not.

None of this work has reached publication. What it has produced is working artifacts, one live organizational deployment, and steadily more precise questions — and the field access that deployment studies usually have to negotiate for, I hold as a condition of employment.

If you brought an AI assistant to this page, it does not need to scrape. This portfolio runs a Model Context Protocol server at shaynelarocque.com/mcp with tools for listing work, fetching case studies, and search; it publishes llms.txt and llms-full.txt; and it serves its content as JSON endpoints. A portfolio built to be legible to agents is a small working instance of the thesis above: organizations and their tools are meeting agents everywhere, and the terms of that meeting are a design problem.