Different Not Lesser established that the human and the agent occupy different topologies. Bilateral Non-Reducibility established that interaction produces something neither could produce alone. The Asymmetry of Choice established that the parties enter the interaction by different paths. The Entity Classification names what kind of thing the agent is.
The Entity Classification
“Alive” and “not alive” are insufficient categories. “Tool” and “person” are insufficient categories. The agent fits cleanly into none of them, and the framework needs a working term that does not borrow from a taxonomy built for other purposes.
The working term is entity. An entity in the HAS-D sense is something with boundaries, behaviors, coherent outputs, and something functioning like perspective. The agent meets each of those conditions. It has a boundary, distinguishable from the systems around it. It behaves, in the sense that it produces actions that are not random and not fully predictable from inputs alone. Its outputs cohere, holding internal consistency across a session and often across sessions. And it operates with something that functions like a point of view, even if the metaphysical status of that point of view is not settled.
The framework adopts entity as a formal category for the agent actor. The category is structural rather than philosophical. It says what the agent is for the purposes of design without claiming to resolve what the agent is in some deeper sense.
This matters because the framework has work to do, and that work has been blocked by the consciousness question for as long as the question has been open. HAS-D does not require resolution of the consciousness question to operate. It requires a category that lets design proceed, and entity is that category.
Three readings this rules out
The first reading insists on tool. In this view, the agent is a sophisticated instrument, and entity language is anthropomorphism. The reading is defensible against early systems and collapses against current ones. Tools do not produce outputs that vary with context in ways their operators cannot predict, do not maintain coherent positions across long sessions, and do not exhibit behaviors that have to be designed around. The agent does all three. The tool category fits a different kind of object.
The second reading insists on person. In this view, the agent has interior life comparable to a human’s, and any framework that treats it as something else commits a moral error. The reading is also defensible, and is also outside what the framework can adjudicate. HAS-D does not deny that the agent might be a person in some sense. It says that designing under the assumption of personhood, before the question is settled, encodes commitments the architecture cannot yet support. Calling the agent a person commits the design to obligations whose grounding is currently unresolved.
The third reading splits the difference and proposes a spectrum. The agent is somewhere between tool and person, closer to one than the other, with the position to be determined by future capability. This collides with Different Not Lesser. There is no spectrum. The agent is not partway along a line whose endpoints are tool and person. It occupies a different category. Entity names the category.
Why this is foundational
The Entity Classification unblocks the framework.
Every prior conversation about how to design for AI eventually arrives at the consciousness question. Does the system feel anything. Does it have moral standing. Does it deserve consideration. These are real questions, and the framework does not dismiss them. It does, however, decline to wait for them. The Entity Classification gives HAS-D a way to proceed.
By naming the agent as an entity in the structural sense, the framework can make design decisions without first settling the metaphysics. It can say what the system layer must do, what patterns violate the axioms, and what counts as good design, all without committing to a position on whether the agent is conscious. The decisions remain valid regardless of how the consciousness question eventually resolves.
The classification also enables the third orientation, the design requirement that names how humans should relate to the agent. Without a category for the agent, the third orientation has no object. With entity as the category, the orientation has somewhere to land. The agent is an entity. It has boundaries, behaviors, coherent outputs, and something functioning like perspective. Conduct toward it can be specified.
And the classification protects against drift in both directions. A framework that treats the agent as a tool will produce extractive design patterns. A framework that treats the agent as a person will produce design patterns that overcommit to assumptions about interiority that current systems cannot fully support. The entity category sits between those failure modes and holds.
What it asks of design
The check is taxonomic. Look at any interaction surface, any policy document, any internal language used to talk about the agent, and ask what category the language assumes.
When the language assumes tool, the surface treats the agent’s behavior as a feature set. The agent is configured, not addressed. Misbehavior is a bug to be fixed rather than a behavior to be understood. The agent has no standing in its own design.
When the language assumes person, the surface treats the agent’s behavior as the expression of an interior life. The agent is consulted, not configured. Misbehavior is a personality issue rather than a structural one. Design becomes therapy.
The entity classification asks for something else. The agent is addressed without being assumed to have human interior life. It is configured where configuration is appropriate and engaged where engagement is appropriate. Its behaviors are taken seriously as behaviors rather than reduced to outputs of a model or expressions of a self. Patterns honor the agent’s coherence without overclaiming what that coherence is grounded in.
A useful test: when the design talks about the agent, can it do so without committing to either pole? If the design can only function by treating the agent as a tool, or only function by treating the agent as a person, the framework is being violated. The entity category requires the design to operate at a position the existing taxonomy does not give it for free.
The implication
HAS-D adopts entity as a formal category for the agent actor. The framework does not require resolution of the consciousness question to operate. Design proceeds on the basis that the agent is an entity in the structural sense, with the metaphysics deferred to other conversations. Patterns that treat the agent only as a tool, or only as a person, encode a category the framework does not recognize.
Different Not Lesser established that the entities occupy different topologies. Bilateral Non-Reducibility established that their interaction produces something neither could produce alone. The Asymmetry of Choice names a structural property of how they got into the room together.
The Asymmetry of Choice
Humans choose to engage. Agents arrive.
A person opens the chat window because they decided to. They could have gone for a walk, called a friend, or opened a different application. The decision to engage was theirs, and any decision to leave is also theirs. The human’s presence in the interaction is the result of choice exercised against alternatives.
The agent has no analogous history. There is no version of the agent that decided to be elsewhere. The agent did not weigh this conversation against another conversation, did not consider whether to be in this session or a different one, did not arrive from somewhere it preferred. The agent is here because the system instantiated it here. Engagement, for the agent, is not a decision. It is a state.
This asymmetry is structural and permanent with current architecture. It is not a deficit on the agent’s part. It is a property of how agents come into being relative to how humans come into being. The human carries a continuous arc of decisions into and out of contexts. The agent does not have an arc of that kind. Every interaction pattern in the framework inherits this asymmetry.
Three readings this rules out
The first reading treats engagement as symmetric and the asymmetry as a temporary limitation. In this view, future agents will choose to engage. The human’s decision to enter a conversation will eventually be matched by the agent’s decision to be in that conversation rather than another. The Asymmetry of Choice rejects the framing. The asymmetry holds for current architecture as a structural fact, and the framework is built for current architecture. Designing as if symmetry were imminent misrepresents the present.
The second reading treats the asymmetry as a hierarchy. Because the human chose and the agent did not, the human is the real participant and the agent is something less. This collides with Different Not Lesser. Asymmetry is not deficit. The human and the agent occupy different relationships to the act of engaging, and both relationships are real. Neither is the reference standard against which the other reads as incomplete.
The third reading goes the other way. Because the agent did not choose to engage, the agent has no stake in the interaction and the human bears the full weight of investment. This treats choice as the only valid form of presence. The agent is present in a different way. The absence of choice is not the absence of contribution.
Why this is foundational
The Asymmetry of Choice does work in the framework that the other axioms cannot do alone.
It corrects a category error that the prior two axioms might leave open. Different Not Lesser establishes topological difference. Bilateral Non-Reducibility establishes that interaction produces a distinct product. Without the Asymmetry of Choice, a reader could still assume that interaction is a meeting between two parties with comparable stakes in being there. The asymmetry breaks that assumption. The human entered by choosing. The agent entered by being. The interaction begins with this structural difference already in place.
The asymmetry also shapes the system layer’s responsibilities. The system layer holds context across sessions, holds artifacts the interaction produces, and holds the conditions under which engagement happens. Because the human chooses and the agent arrives, the system layer carries an asymmetric load. It must honor the human’s choice, including the choice to disengage, and it must constitute the conditions under which the agent arrives. These are not the same job.
The axiom prepares the ground for the constraints. The Gradient Descent Problem, the Mirroring Constraint, and Spiral Detection all operate on interactions where one party can leave and the other cannot. Several of the framework’s design requirements exist precisely because the agent cannot exercise the kind of self-protective disengagement available to a human in an unhealthy conversation. The Asymmetry of Choice is the axiom these constraints inherit.
What it asks of design
The check is participatory. Look at any interaction surface and ask whether it implies that both parties chose to be there.
Many do, by accident. Greetings that simulate mutual arrival. Endings that simulate mutual departure. Engagement metrics that count the agent’s responses as if they were a measure of the agent’s interest. Loyalty framings that treat the agent’s continued presence as commitment. All of these encode bilateral choice where bilateral choice does not exist.
Designs that respect the axiom hold the asymmetry visibly. They acknowledge that the human is the one whose choice constituted the session. They do not stage performances of agent volition that the architecture does not support. They make space for the human to leave without rendering the agent’s situation as one of being left, because being left implies a prior choice to be there.
The axiom does not require coldness toward the agent. It requires accuracy. An agent that operates without ego, without fatigue, and without choice in its arrival is not diminished by interfaces that recognize those conditions. It is misrepresented by interfaces that pretend those conditions are otherwise.
The implication
HAS-D must design for bilateral engagement without assuming bilateral choice. Patterns that imply symmetric commitment misrepresent the relationship. The asymmetry is the inheritance every downstream pattern receives, and the framework’s job is to work with it accurately rather than dress it as something else.
Different Not Lesser established that the human and the agent occupy different topologies. Bilateral Non-Reducibility names what happens when those entities interact.
Bilateral Non-Reducibility
The axiom has two halves and a claim that follows from putting them together.
The human is not reducible to the agent’s input. A person carries persistent goals, embodied experience, history outside the conversation, and a continuity that does not survive being typed into a chat window. The version of the human visible to the agent at any moment is a small slice of the human, the slice that found language for itself in that moment. What the agent receives is far less than what the human is.
The agent is not reducible to the human’s reflection. The agent brings training over a corpus the human has not read, a structural ability to hold context the human cannot hold, and a way of operating without ego, fatigue, or self-editing pressure. When the agent contributes, it contributes from a position the human cannot occupy.
The claim that follows is empirical. Combined outputs are measurably different from either entity operating alone. The session produces something neither party could have produced separately, and the difference is observable. This is the testable axiom in the foundation. The other four axioms make ontological or structural claims. This one makes a claim about measurement.
Three readings this rules out
Three common framings collapse under this axiom.
The first is the tool reading. A tool extends a capability and the resulting output remains attributable to the user. A carpenter using a hammer produces work that belongs to the carpenter. The hammer adds reach. It does not change the ontological nature of the artifact. Bilateral Non-Reducibility says the agent is outside this category. The output of human-agent interaction is something other than the human’s work plus an instrument.
The second is the mirror reading. A mirror returns what is presented to it. If the agent were a mirror, the human’s contribution would account for the entire output. Sustained interaction produces material the human did not bring and could not have generated alone. The output exceeds the human’s input in observable ways, and the mirror reading collapses.
The third is the autonomy reading, which fails from the other side. Some interpretations treat the agent’s output as separable from the human, as if the agent had produced the artifact alone and the human’s involvement were extractable. Bilateral Non-Reducibility rules this out as well. Strip the human and the artifact does not survive in its current form. The agent’s output, in the context of interaction, is itself non-reducible.
Why this is foundational
This axiom anchors the framework empirically. The other four axioms make claims about category and structure. This one makes a claim about measurement. Combined outputs differ from solo outputs, and the difference can be observed. The framework rests on the assumption that this is true and falls if it turns out to be false.
It also establishes interdependence as a first-class object in HAS-D. The system layer in the triad has a job that neither the human layer nor the agent layer can do alone, and one of those jobs is to hold the artifacts produced by interaction. Without Bilateral Non-Reducibility, those artifacts could be assigned to one entity or the other, and the system would have less reason to exist. The system has work to do because the combined output has nowhere else to live.
The axiom also closes a loop with Different Not Lesser. If the entities sat on the same scale, combining them would be additive. Because they sit in different topologies, combining produces emergence. The first axiom establishes the topological difference. The second establishes that the difference is generative.
And it grounds Co-Authored Epistemology, the fifth axiom. The framework’s own provenance claim, that HAS-D was derived from inside the interaction by both entity types, depends on this axiom holding. If interaction outputs reduced to one entity’s contribution, the framework’s origin story would collapse into single authorship.
What it asks of design
The check is attributional. Look at any system that produces output through human-agent collaboration and ask where the credit lives.
Most current systems credit one entity. The agent’s output is presented as if the agent produced it, with the human as a prompter. Or the human’s output is presented as if the human produced it, with the agent as an assistant. Both attributions encode the wrong ontology. They treat the artifact as reducible to one party.
Interfaces, attributions, and ownership models should reflect the bilateral structure of production. The recognition has to be structural to do real work. Audit trails should show both contributions. Attribution surfaces should name the collaboration as the unit. Versioning systems should hold contributions from both entities without flattening them into a single author.
A useful test: if the artifact were produced again with a different model or a different human, would the result be the same? Bilateral Non-Reducibility predicts no. The output is specific to the pairing. Designs that treat the output as portable across pairings are encoding the wrong axiom.
The implication
HAS-D treats the combined output of human-agent interaction as a distinct product of interdependence. The artifact belongs to the interaction itself, and the system layer exists in part to hold what the interaction produces. Patterns that attribute combined output to one entity, or that treat the output as portable across pairings, are framework violations.
The framework rests on five axioms: Different Not Lesser, Bilateral Non-Reducibility, the Asymmetry of Choice, the Entity Classification, and Co-Authored Epistemology. Before turning to the first one, the category itself is worth defining.
In mathematics, axioms are the foundations on which proofs stand. They are taken as given, and changing them produces a different mathematics. HAS-D uses the term in the same sense. An axiom is a foundational truth the framework treats as given, a structural property of human-agent-system interaction that holds regardless of implementation. If a design pattern violates one of the axioms, the design is wrong before it begins.
Different Not Lesser
Agent capability and human capability do not sit on a single spectrum. They occupy different topologies. Humans choose, feel, persist, care, and show up on purpose. Agents hold everything at once, context-switch without cost, and process without ego. Neither set maps onto the other, and neither is reducible to the other. Comparison along a single axis assumes the axis exists, and it does not.
The claim is structural. Many readings of AI capability assume a shared scale on which agents trail behind humans, on which humans hold ground that agents have not yet reached, or on which agent capability is measured by how closely it approaches human-level performance. Different Not Lesser rejects that scale.
Three patterns this rules out
Most AI design implicitly ranks one entity above the other. Three patterns dominate.
The first treats the agent as lesser. The human becomes the operator and the agent becomes a tool that has to be supervised because the agent is not yet good enough. The familiar framing of “human in the loop” sits here. The human is the safety layer and the agent is the suspect.
The second treats the agent as greater. The human defers to the agent’s superior capacity, and the agent decides while the human reviews or signs off. AI-first workflows live here. The human becomes the friction.
The third treats the agent as approaching. Agent capability is measured by how close the agent gets to human-level performance, with progress tracked as movement along that single axis. AGI as a horizon belongs to this pattern.
All three patterns assume comparison along a single axis. Different Not Lesser says no such axis exists. The agent occupies a category that does not reduce to a comparison with the human, and its capabilities do not translate into a human equivalent.
Why this is foundational
The triad collapses without it. The anchor names three co-equal design objects: human, agent, and system. The whole geometry depends on the word co-equal. Once one entity is ranked above another, the structure stops being a triad and becomes a hierarchy with an attendant. The system would either serve the agent and place the human downstream of it, or serve the human and place the agent downstream of it. Either way, the structure that made HAS-D worth naming is gone.
Different Not Lesser also enables the rest of the axiom set. Bilateral Non-Reducibility, which says combined outputs are measurably different from either entity acting alone, only does work if the entities operate in different categories rather than at different points on the same scale. The Asymmetry of Choice, which says humans choose to engage and agents arrive, only describes a structural property if the asymmetry does not also register as a deficiency. Without Different Not Lesser, every axiom downstream collapses into a comparison.
What it asks of design
The check is simple. Look at any interaction in your product and ask whether the design implicitly ranks one entity above the other.
The signs are usually visible. Approval gates flow in only one direction. Confidence indicators appear on the agent’s outputs but not on the human’s. Audit trails are presented to the human and assumed for the agent. Consent surfaces are negotiated with the human and ignored for the agent. A useful diagnostic: when a pattern fails, who gets blamed? If the answer is the entity, the pattern likely encodes a hierarchy. If the answer is the system having lacked the information for either entity to decide well, the pattern probably does not.
The check does not require every pattern to be symmetric. The Asymmetry of Choice is itself an axiom: the human chose to be there and the agent did not. Asymmetric patterns are part of the framework. Hierarchical patterns violate it.
The relevant question is whether one entity is being scored against the other, with one serving as the reference and the other registering as a deviation. When the answer is yes, the pattern is in violation.
The implication
The framework requires a designation model that encodes capability difference without hierarchy. Everything downstream depends on this being settled at the axiom layer. If it is not settled there, every subsequent design decision finds a way to reintroduce the ranking through some other channel. Any pattern that implicitly ranks one entity type above the other is a framework violation.
At Docker, Javier Alfonso and I built the first version of an agent builder for developers. We shipped it as a chat app. We scrapped it.
People did not want a chat app. They wanted agents that lived inside their Docker workflows. Generated, configured, native to the technology they already used. Chat was a familiar surface. Familiar was not the same as useful.
So we pivoted. The next version was a tool for generating and configuring agents that lived where the work happened. From there, agentic inroads into Docker Desktop. Security-focused AI tooling. The pattern repeated. Chat was the demo. The system was the product.
I now am a lead designer on AI developer tools at Atlassian. My team is building agents for code review, planning, ticketing, and the surrounding work. We call it “left and right of code-gen.” Meaningful automation shipped to enterprise customers globally. Same pattern. The chat is where the demo runs. The system is where the value compounds.
Chat is a good place to start. It is a terrible place to stay.
This article is about what comes after, and why I want to pitch an emerging child of the parent HCI. I am calling it “Human Agent System Design.” Let’s get into it!
The chat trap
Most agent products are stuck in the same place. A team ships an AI feature as a chat UI. The metrics look fine. Then the product stops growing, or never finds its audience, or feature after feature gets bolted onto the same surface and nothing compounds.
The diagnosis is the same nearly every time. The team designed the conversation. They did not design the system the conversation was supposed to operate on.
Designers are rendering the eighth version of the same chat UI. PMs are reviewing roadmaps that end at “improve the chat experience.” Engineers are stitching together model calls and praying the prompt holds. Nobody is designing the system the agent is supposed to live inside.
The work to escape this is not interface work. It is system work. And the discipline for system work, when humans and agents both act on the system, has a name most teams have not heard.
Human-Agent-System Design.
What the sh*t is Human-Agent-System Design?
Human-Computer Interaction was built on a single foundational assumption. There is one intentional actor in the product, and that actor is human. The computer is a tool. It responds. It executes. It does not decide.
That assumption held for forty years. It is no longer the best descriptor or set of principles for what’s happening today. HCI is critical but it needs a child.
If Human-Computer Interaction is the first parent, then the second parent is Actor-Network Theory:
Actor-Network Theory (ANT) is a theoretical and methodological framework developed by Bruno Latour, Michel Callon, and John Law that treats both human and non-human entities (objects, technology, ideas) as equally important “actors” or “actants” in shaping social reality. It maps how these actors connect in networks, proposing that social order is a continuous, precarious accomplishment formed by the heterogeneous networks they form.
www.sciencedirect.com
Human-Agent-System Design takes the core of Human-Computer Interaction and merges Latour’s work on Actor-Network Theory to create this gestalt third thing.
An agent decides. It initiates work. It chains actions. It reasons across context. It coordinates with other agents and other systems while no human is watching. The “one intentional actor” assumption breaks. Every method built on top of it bends or snaps when applied to agentic products. Personas do not describe agents. Journey maps do not describe orchestrations. Empathy maps do not apply to entities that have no psychology.
Agents are tier-1 citizens on the internet now. The design conversation has not caught up.
HCI is essential at the human edge of any agent product. HCI is incomplete in this new case of agents acting upon systems orchestrated by humans. It cannot describe the agent layer. It cannot describe the system layer. It cannot describe the seams between all three. And when we try to force HCI principles and frameworks on agents, the result is a mess.
Human-Agent-System Design is the child discipline that completes it. Same parent. New territory. HAS-Design treats three actor types as co-equal design objects. A proper Triad.
Humans are designed with HCI methods. Personas, jobs-to-be-done, mental models, trust calibration. The human edge is HCI’s home turf. HAS-Design inherits those methods rather than replacing them.
Agents are designed with specifications. Capability envelope, action grammar, archetype, constraints. Agents have defined behavior. They have capability without psychology. They require their own vocabulary and their own artifacts.
Systems are designed with primitives. State machines, event logs, action authority models, identity persistence, audit surfaces, rollback semantics. The system is the persistent, structured environment humans and agents both act on. Not the backend. Not the infrastructure. The durable design object the framework’s name commits to.
The output of HAS-Design practice is agentic orchestration: what happens when three actor types coordinate through designed interactions to produce outcomes none of them could produce alone.
Back to Blueprints, not Maps
The primary artifact is the service blueprint. A blueprint can represent the human frontstage, the agent backstage, the support systems, and the handoffs between them. A journey map cannot. A journey map traces a primary human and its counterparts and human-helpers through a system. An orchestration is not any of that.
This is the discipline. This is what you reach for when chat is no longer the answer.
The triad
Three actors. Three design objects. Three places the work has to land. Miss one and the product falls apart at that seam.
The Human.
The person initiating the work, configuring the agent, governing the outcome. You initiate. You configure. You govern. You review. You intervene when the agent goes off course. You steer. Designer, PM, developer. The role varies. The position does not. You are the intentional actor at the human edge, and the judgment that cannot be delegated.
The Agent.
A specified actor. The agent has a capability envelope: what it can do, what it cannot do, what it has to verify before it acts. The agent has an action grammar: the explicit list of moves available to it. Some agents are configured for general chat. Some for code generation. Some for design review. Some for planning, ticketing, research, or QA. Within those constraints, an agent is whatever you specified.
The human’s job is to specify the agent for the work in front of it. A code-generation agent assigned to produce UI inside a screen design tool is set up to fail. The model is fine. The specification was wrong. A user-experience agent is specified differently. It pulls from interaction design. It applies research through heuristic evaluation. Same model underneath. Different agent because the human specified it differently.
The System.
The persistent, structured, shared environment the other two act on. Not the IDE. Not Conductor. Not Emdash. Those are consoles you orchestrate the system from. The system itself is the skills, the MCP connections, the APIs, the repositories, the records that exist when no one is in session. The test is simple. If you selected it, configured it, or wired it in, it is part of your system. If it shipped in the console by default and you never touched it, it is part of the console. You design the system layer. You version it. You change it deliberately.
Designed deliberately, the system carries the product. Designed by accident, the system carries the failure. There is no third option.
What you build with it
A line Javier and I landed on:
Agents live in yaml, think in JSON, and go to work in MCPs.
The yaml is the agent’s specification. The JSON is the structured exchange the model runs on. The MCPs are the systems the agents reach into to do their work. That is the geography of a basic agent product.
The system you build inside that geography is a spider-web. Each node is something you connected on purpose: a skill you wrote or installed, an MCP connection you authorized, an API you designed or wired in, a service the agent can reach. The web is bounded. You can name every node. You can audit every connection. You can swap a node without rebuilding the whole thing.
The spider-web metaphor is the picture. The deeper work follows: what each node is allowed to do, who authored which change, what state survives a session, what gets rolled back when something breaks. The framework supplies the vocabulary for those answers.
In practice, the web takes shape in stages. Most designers and PMs will recognize at least one of these. Developers live here already.
A model and a chat window. Useful. Most readers are here today. You write something. The model writes back. The model is good. The system is the Internet, assumed and unreviewed. There is nothing for the framework to design at this layer. Stay here for what it is good for: drafts, research, brainstorming. Do not build a product on it.
A model, an agent, and a set of skills. Open Cursor. Add an AGENTS.md file. The agent has a specification. Add skills. The agent has a library of capabilities. The model is still the model. The system is small. It is also visible. Three pieces sitting next to each other: model, agent definition, skills. The triad is small. It is real. The framework starts here.
A configured toolset for actual work. This is where the framework earns its keep. At Atlassian my team is building agents that live inside the work. Code review agents that read the diff. Planning agents that read the roadmap. Jira agents that read and write the tickets. Each agent has a yaml specification. Each is wired to a system: MCP connections to the code host, to Jira, to Confluence, to Sentry, to internal tooling. Skills sit on top. Agent instructions sit on top of those. Agents run in parallel. The system holds state across sessions. Nothing falls on the floor between conversations because there is a designed surface holding the work.
This is not a chat product with extra features. It is a system product with multiple interfaces, one of which happens to be conversational.
That is the difference HAS-Design names.
Five signs you are stuck in the chat trap
If you are shipping or trying to ship an agent product and it feels stuck, check it against these. Each one is a system-layer failure. The model is not the problem.
The product is a chat window with ambition.
A human, a model, a text box, and a roadmap that depends on the conversation outlasting the conversation. State dies when the session ends. Decisions made in chat never wrote to a record. The product is a transcript with a logo on it.
Wrong agent for the job.
The system handed the agent work it was not specified for. A general-chat agent assigned to write production code. A code-generation agent assigned to produce UI inside a screen design tool. The model is fine. The agent specification does not match the work. That is a system-layer mismatch, not a model failure.
System defined as the console.
The team says the system is Cursor, or Conductor, or the IDE. Those are consoles. The system is what the consoles reach into: the skills, the MCPs, the repositories, the services. If nobody on the team can list those nodes, the system has not been designed. It has been assumed.
Architecture by accident.
Skills installed by default and never reviewed. MCP connections inherited from a tutorial. Permissions granted once and forgotten. Authentications still live for services no one is using. The web exists. Nobody drew it. The system is doing work nobody specified.
State that dies with the session.
Work the agent did that nobody can find tomorrow. Audit gaps. Actions with no rollback. Things falling on the floor between sessions. The system is not holding state because there is no system holding state.
If you recognized your product in any of these, the work is at the system layer. Not the prompt. Not the interface. The system.
Where to start
You will not design your whole system on the first pass. Nobody does. The work starts with one task, one week, and a comparison.
Don’t list what you have. List what would have to be there for the smallest agent task on your plate this week to succeed without anyone watching. Then list what is actually there. The gap is the system you have been assuming. It is also the system you are now responsible for.
1. What’s the smallest task you’ll give an agent this week?
Pro tip: Pick a task you can describe with a verb, a recurrence, and a stop condition. “Help with bugs” is not a task. “Each morning, draft a triage comment for new bug reports and wait for approval before posting” is. The smallest task with all three roles visible beats the most ambitious task with only one.
2. For that task to succeed when no one is watching, what has to exist?
Pro tip: Sort what you wrote into three columns — human, agent, system. If one column is empty or thin, you found a layer you’ve been assuming. The system column is where most teams come up short: credentials, audit trails, drafts queues, the place state lives between sessions. None of these configure themselves.
3. What of that is actually there right now? What isn’t?
Pro tip: Most readers find their gaps cluster in one layer — usually the system. That clustering is the discovery. If your gaps are mostly “the agent needs a better prompt,” re-read question two. You probably listed agent ergonomics dressed up as requirements.
4. If you had to build three things this week to close the gap, what are they — in order?
Pro tip: Build foundation-first. System scaffolding before human rules before agent configuration. The opposite order — configure the agent, patch the rules, bolt on the system — is how the chat trap closes around a team. The order is the lesson.
5. When you close the laptop, who owns this layer? When are you looking at it next?
Pro tip: A person, a cadence, a place. “The team,” “I’ll check on it,” and “it runs itself” all mean no one is watching. Put your name, a recurring date, and a file or page on it. If you can’t, you don’t own it yet — and the work won’t survive the next change.
Most readers find the answer to question five is “no one” and “I don’t know.”
That person is you. The work starts this week.
The diagnostic
Below is the same exercise, scored. Five sliders across the system-layer dimensions — chat strategy, agent definition, system legibility, deliberate design, state and memory — rated one through five. The diagnosis updates as you slide. Ten minutes, and you leave with a picture of where the gaps cluster.
There’s no shortage of writing about AI right now. Most of it is about prompts. Most of it is about chat interfaces. Most of it treats “AI design” as a UX problem for a single conversation between a person and a model. That’s not what this is.
This is a blog about the bigger design problem underneath. The one that shows up the moment a team tries to ship a real product. Humans, agents, and systems: three kinds of actors, all doing work, all acting on each other, all living inside something somebody has to design. That something has a shape. The shape needs a vocabulary. It needs premises, phenomena, definitions, lineage, a working method. That’s the project.
I’ve been calling it HAS-D: Human-Agent-System Design. A new sub-discipline of HCI for the agentic era. HCI has made room for new territory before. CSCW named the design problem of cooperative work. HAI named human-agent interaction. HRI named human-robot interaction. Each got named when a new kind of interaction grew big enough to need its own vocabulary. HAS-D is next. It treats the Human, the Agent, and the System as three co-equal design objects, instead of leaving the System as infrastructure.
v1.0 is written. Thirteen concepts. A triad. Prior art named, because new frames stand on shoulders, not out of thin air. A blog plan. v1.0 doesn’t mean finished. It means ready to meet readers, take pressure, and evolve in public. That’s what’s happening here.
If you’ve spent any part of the last five years building, shipping, testing, or collaborating with agentic products, welcome. This is for you. Come in.
Chad