For many years I have been teaching a case on human-centered design from IDEO’s perspective. In the case, IDEO is tasked to redesign the moviegoing experience at Cineplanet and to do so the IDEO team works closely with Mildreth Maldonado, Cineplanet’s chief financial and marketing officer. For most of the first part of the case, Mildreth drives the Americans from IDEO around Lima, visiting cinema theaters and people’s homes to view their home cinema setups. It’s a vivid depiction of how intensive the process of context building is.
The case also clearly illustrates how iterative the process human-centered design is. The case was initially written in 2014, so naturally there was no AI being used by the designers, at least not the way we understand AI today. What is really useful, though, about the case is how it helps to make the process of human-centered design both explicit and made to feel like a richly textured human practice.
Human-Embedded Agentic Design is no different. It’s fundamentally a human practice, even if it is assisted by agents. Perhaps I should have called it Agent-Assisted Human Design, but AAHD just doesn’t have the same ring as HEAD. So, what does a richly textured human practice of working with agents to build things look like when it is laid out like a process that can be followed programmatically, similar to IDEO’s process? My suggestion is that it consists of three main phases: Context, Code, and Criticism. While each of these steps occur throughout the design process, I have arranged them in a linear flow because I think that each of them dominate at the early, middle, and late periods of a project.
The HEAD Process
Context
The key idea of context building is to build a knowledge stack that ranges from the more general to the more specific, and this stack of knowledge needs to be mirrored between your brain and the LLM harness you are working with. Building the context, however, is not a one-time thing, rather it is a concern that occurs throughout your design process. Of course, context building is most intense at the beginning of a design process. Early in a project, most of your hours should go towards interviewing the people who will use the thing you are building and running research agents that go collect what’s already known. The scite.ai MCP is what I use the most. Elicit, Consensus, Undermind, and ResearchRabbit are each alternatives that have received a lot of attention, even though I have not tried them out personally.
The context stack you have built, however, is never finished. As you build, the code tells you what you failed to specify, which may then prompt you to update your context. As you gather criticism, users tell you things that you did not know, prompting further updates to the context. Both of those flow backwards into context. You are continuously updating the world your agents live inside, and if you treat context building as a phase to be completed then forgotten about, then the world you have built for your agents will quickly go stale.
Which means you need a system for it, not an episode. I’ve been building an application on a small, headless server I built out of an old Macbook sitting in my closet, assisted by Claude. It scours the journals I usually read, plus newspapers and magazines, for new studies, findings, and arguments, and synthesizes them into a weekly report short enough that I actually read it. The important part isn’t the scraping. It’s that the thing is customized to me: my field, my journals, my standing questions. Nobody else could write that spec, which is exactly why you need your own rather than a subscription to someone else’s. And the spec is itself under constant revision, because what I need to be watching changes.
My old Macbook, running OpenCode and open weights models via API
Code
Then you generate, and here the structure is adversarial by design: gen agents produce variety, crit agents select the best alternatives out of many different options. This is a basic evolutionary process at work: variation, selection, and retention. What we have not discussed much previously is that, most of the time, you are not going to read the code. There’s too much of it. That sounds like an admission of defeat, and most people seem to respond to it by pretending they read it or insisting to keep on writing the code by hand. I think both of these responses are unhelpful.
What I think you should do instead is to build a battery of tests. If you can encode the goals (what you want to achieve), guidelines (how the agents should go about it), and guardrails (how the agents should not go about it) in a set of deterministic tests, then you are on your way towards building a system that can generate the code that actually does what you want it to do. In situations where this is generating a website or a web app where the behavior is readily observable, this may be relatively easy, and the more the software you are building has a “trust me”-quality to it, the more challenging this is going to be.
Criticism
Crit agents are helpful for making sure you are not just generating the same output as everyone else, but what I want to add here is that criticism is not only agents. This is where human-centered design still has a point and most AI builders are missing the point. IDEO’s designers went into actual theaters and watched actual customers. You have to do the equivalent — put the thing in front of people who need it to work and find out what breaks. Agents reviewing your artifact will catch the internal problems. They will not catch that nobody uses the feature, or how they might be reacting to a feature.
Partially this is done through talking to people, which is time-consuming. To make this easier you can also build the feedback collection mechanism into the application itself. What I am suggesting is that you insert small, in-context prompts inside the app, appearing at the moment something worked or didn’t, so that the thing you shipped is also the thing gathering criticism for you. And again: everything you learn here goes back into context, thus restarting the whole process.