Agents Are Your Customers

Design software for agent-first usage

· Updated 2026-02-09
aiagents

Going forward, I think it is smart to assume agents will be your primary users.

This means your API must be your primary focus - ahead of UI, anything else, since the agent will use the API or its derivative (a CLI). When developing, test with and for agents.

According to Steve Yegge:

Beads has evolved a very complex command-line interface, with 100+ subcommands, each with many sub-subcommands, aliases, alternate syntaxes, and other affordances.

The complicated Beads CLI isn't for humans; it's for agents. What I did was make their hallucinations real, over and over, by implementing whatever I saw the agents trying to do with Beads, until nearly every guess by an agent is now correct

Another interesting consequence of building for agents is that you should price for use, not per seat (SaaS). Caleb John termed it B2CC - Business to Claude Code.

Parity and Atomic Primitives

Every.to's guide on agent-native design crystallized two concepts I found extremely insightful.

Design for Parity

When the agent is the primary executor the #1 design constraint is parity: anything a user can accomplish via the UI must also be achievable by the agent via tools

Atomic Primitives (AP)

The Every.to post articulates something I do but didn't have the terminology for it. When designing for agent use, you use atomic primitives - small, composable operations.

A primitive tool does one clear thing. A simple example of "Create a draft blog post from these notes and publish it next Monday."

Coarse tool (bad for agents):

  • ❌ write_and_publish_post(notes, date)

Primitives (agent-native):

  1. create_post(status="draft") -> post_id
  2. set_title(post_id, title)
  3. set_body(post_id, body_markdown)
  4. add_tags(post_id, ["x","y"])
  5. schedule_publish(post_id, datetime)
  6. get_post(post_id) (verify)

Test for Parity and AP

Here is the key. To test if you have parity and atomic primitives, you as yourself the following: To change behavior, do you edit prompts or refactor code?. If the answer is refactor, you have missed one/both of these goals.

Why are these so important?

This design allows for composability - you can create new features just by writing new prompts. Furthermore, the agent can do things you didn't explicity design for (emergent behaviour)