drpontus

Machine Learning (ML) is not something designers “add” to products. It is something products are increasingly made of. Across contemporary digital systems – productivity environments, decision-support software, operational platforms, and public-sector infrastructure –machine learning drafts content, ranks options, predicts outcomes, monitors conditions, and sometimes executes actions. These systems increasingly shape not just interfaces, but workflows, attention, responsibility, and judgment.

Yet many ML-based systems remain difficult to trust, difficult to understand, and difficult to contest. Users often cannot tell what the system is doing, why it is doing it, or how much authority it actually has.

This is frequently framed as a problem of model quality or explainability. In practice, it is more often a human–machine interaction and design problem.

Before discussing the specific patterns, two distinctions need to be made explicit, because current AI discourse routinely obscures them.

Clearing the ground: agency without anthropomorphism

First, referring to computational systems as a proper agent (e.g. by using languages like “I”, “he/she”, etc.) is a category error.

Machine Learning systems do not possess intention, judgment, or responsibility. Treating them as “agents” in any meaningful deep sense is not only inaccurate – it actively damages design thinking by masking where power and accountability actually reside. Anthropomorphic language invites misplaced trust, emotional attachment, and false expectations, all of which are well-documented failure modes in human–”AI” interaction.

When this article discusses agency, it does so in an interactional and operational sense: what entity initiates actions, “who” constrains options, and where responsibility is located within a system of systems.

Agency here is not a property of the machine. It is a design outcome – produced by interfaces, defaults, workflows, and institutional choices. Any apparent “initiative” of a system is ultimately the result of human decisions embedded upstream.

That being said; sometimes anthropomorphic language may occur in this text in order to make it readable. Since we don’t have an adequate vocabulary for all ML-specific characteristics, we sometimes shortcut to words reserved for human cognition, like “hallucination”, “learn”, “infer”, or even “intend”. But never forget that “intelligence” is a highly problematic word. In fact, statistical pattern recognition would be better understood and assessed if we stayed away from anthropomorphic language altogether.

Tools versus services: a design distinction with ethical consequences

Second, there is a critical distinction between tools and services, and it is often ignored in discussions of the latest generation of large language models (LLMs).

A tool expands user capability while remaining subordinate to user intent. It exposes its controls, allows misuse, and does not enforce values beyond basic technical constraints. A text editor, a compiler, or even a locally run model falls into this category.

A service, by contrast, governs interaction. It dictates allowable actions, decorates or rewrites user input, filters outputs, enforces the service vendor’s values, and reserves the right to change behavior unilaterally. Commercial LLMs, like ChatGPT and Gemini, are services, not tools. They operate within corporate, legal, and economic constraints that shape every interaction – often invisibly.

This distinction matters for design.

Service-based ML systems redistribute agency away from users by default. They constrain exploration, enforce alignment policies, and collapse accountability into terms of service. They are not neutral substrates for design patterns; they are already opinionated systems.

This article advocates for tool-oriented ML design: local models, open-weights systems, or constrained deployments where designers and users can meaningfully inspect, adapt, and contest system behavior. The patterns described below are framed with tools in mind – not opaque, centrally governed services built on unlicensed data extraction.

From deterministic tools to probabilistic interaction materials

Traditional software tools respond to direct manipulation. They wait for instruction, execute deterministically, and stop when the user stops.

Machine learning systems can behave differently.

They “infer” intent from incomplete signals, operate probabilistically, and may continue producing outputs without explicit triggers. They generate results that appear coherent and authoritative even when uncertainty is high.

From a human–machine interaction perspective, this changes how control is exercised and experienced. Interfaces designed for deterministic tools often misrepresent probabilistic systems, creating illusions of certainty or control where neither exists.

Designers working with ML are therefore not just shaping interfaces. They are shaping how decision-making authority is distributed, how uncertainty is surfaced or suppressed, and how responsibility is assigned when outcomes fail.

The three patterns that follow describe recurring configurations of these dynamics. They are not roles played by machines, but design patterns for structuring interaction between humans and computational systems.

The Drafter: supporting exploration without collapsing authorship

A Drafter is a pattern designed to support exploration.

It expands the space of possibilities by generating alternatives, variations, or partial structures. This pattern appears in early-stage ideation, text generation, exploratory analysis, and prototyping – contexts where the primary goal is sense-making rather than selection.

Well-designed Drafters feel provisional. Their outputs are interruptible and incomplete. They are clearly framed as material to think with, not answers to accept. Authorship remains with the human, not because the system is weak, but because the design deliberately resists closure.

The value of a Drafter is productive divergence. It is not the job of the Drafter to be factually correct. (Machine Learning is probabilistic – for factchecking you’re better off using regular information retrieval anyway.)

Design failure occurs when a Drafter is presented as authoritative. When exploratory outputs are polished into final form too early, users stop interrogating them. What began as a thinking aid quietly becomes a judgment proxy. Do not outsource the user’s judgment to the Drafter – instead; enhance the problem space for the user.

A Drafter should make users feel more capable, not merely faster. If interaction rewards acceptance over reflection, the pattern has failed.

The Decider: compressing complexity without displacing judgment

Deciders are systems designed to support convergence.

They rank, score, predict, or recommend. They are used where complexity must be reduced in order to act: prioritization, forecasting, risk assessment, planning.

Deciders inevitably encode assumptions. Every ranking reflects value trade-offs. Every prediction carries uncertainty. The design challenge is not eliminating uncertainty, but making it visible and negotiable.

Responsible Deciders support human judgment rather than replacing it. They expose why a recommendation exists, surface confidence or disagreement, and allow users to explore alternatives. Crucially, they preserve the human’s role as the final decision-maker.

Failure arises when outputs are framed as objective truth, when context is stripped away for the sake of simplicity, or when ignoring a recommendation feels like misuse. In these cases, responsibility shifts silently from human to system.

Deciders do not remove responsibility. They help users making decisions. Design determines whether that help is explicit or hidden.

The Deputy: delegation, boundaries, and accountability

Deputies are systems that execute actions on a user’s behalf.

They monitor conditions, trigger responses, and manage workflows over time. This is where ML systems most clearly reshape responsibility, because actions may occur when the user is absent.

The central design problem of Deputies is not capability, but scope.

Trustworthy Deputies have explicit boundaries, reversible actions, and visible audit trails. They escalate rather than decide when stakes increase. Their behavior is inspectable after the fact, not just configurable beforehand.

Design failures include silent background execution, blurred lines between suggestion and action, and the absence of meaningful shutdown mechanisms. Delegation without legibility is not assistance—it is abdication.

Once a system can act without asking, ethics is no longer abstract. It is embedded in thresholds, defaults, and escalation rules. These are design choices that truly matter.

Hybrid systems and pattern drift

In practice, real ML-based services may combine all three patterns.

A system may generate options, rank them, and then execute the result – with continuous human intervention. Hybrid designs are not inherently problematic. The risk lies in unmarked transitions between patterns.

When exploratory drafting turns into implicit judgment, or recommendations turn into automatic execution, users lose agency without noticing. These shifts are rarely intentional; they emerge as systems evolve and defaults harden.

Without a clear pattern language, this drift is difficult to detect and harder to resist.

Designing interactional power, not intelligence

These patterns are – like all technology – not neutral. They encode both explicit and implicit decisions about authority, responsibility, and accountability.

For designers working in human–machine interaction, this is not an abstract ethical debate. It is everyday design work. Patterns provide a way to reason about ML systems without anthropomorphism or hype, and without hiding behind model complexity.

They also make it easier to say no – to inappropriate automation, premature delegation, or false certainty – while still designing systems that are genuinely useful.

Before deploying any ML-based system, it is worth asking a simple question:

If this system produces a harmful or incorrect outcome, does the interface make it clear where control actually resided?

If the answer is unclear, the design is unfinished.

As machine learning becomes infrastructural, design remains one of the few places where human values can be concretely enforced – not through slogans or alignment rhetoric, but through careful, explicit interaction patterns.