Agentic ergonomics

Dan Shipper does this thing on his blog where the “Copy for agent” button doesn’t copy the article text. It copies a condensed implementation guide, structured for an AI agent to act on, not read.

You’re not copying content. You’re copying instructions.

I built this same pattern for Triage, a widget that lets users report feedback to an AI that triages it, determines if it’s actionable, and writes the code to fix it. When someone clicks “copy embed code,” they don’t just get a script tag. They get an explanation of what Triage is, guidance on where the embed code should go based on what it renders, what props it accepts, and enough context for an agent to make the right implementation decisions.

The person copying it might not read any of that. But the agent they paste it into will.

When Dan published his guide, I realized we’d arrived at the same pattern independently. That’s usually a sign you’re onto something. When multiple people, building different things, converge on the same solution, there’s probably truth in that direction.

The clipboard is an instruction set now

Think about what copy/paste used to be: move data from one place to another. You highlight text, you copy it, you paste it somewhere else. The text is the same on both ends.

But if the destination is an AI agent, the text doesn’t need to be the same. It can be better. It can include context that the human didn’t need to see but the agent needs to understand. It can include instructions that would be noise in a UI but are signal in a prompt.

The clipboard becomes a bridge between human interfaces and agent interfaces. And the contents of that bridge can be optimized for the destination, not just the source.

The evolution from “copy as markdown”

Last year, the pattern was “copy as markdown.” Browser extensions and tools would grab the raw content of a page and dump it into your clipboard. You could paste that into an LLM and provide your own instructions for how to reference it.

That works. But it puts the burden on the user.

The new pattern flips it. What you copy is the instructions. The content might be summarized, restructured, or linked. The clipboard contains what the agent needs to act, not everything it could possibly read.

Here’s what Dan’s “Copy for agent” button actually copies:

# Agent-Native Architecture: Implementation Guide

A practical reference for building applications where agents are first-class citizens.

---

## Core Principles

### 1. Parity

**Whatever the user can do through the UI, the agent must be able to achieve through tools.**

Create a capability map:

| User Action | Agent Method |
|-------------|--------------|
| Create item | `write_file` or `create_item` tool |
| Update item | `update_file` or `update_item` tool |
| Delete item | `delete_file` or `delete_item` tool |
| Search | `search_files` or `search` tool |

**Test:** Pick any UI action. Can the agent accomplish it?

...

It’s not the full 5,000-word article. It’s a condensed, actionable summary. The agent gets what it needs to implement the concepts, not a wall of text to parse.

What Dan’s pattern looks like in practice

On Dan’s articles, the copy button grabs a structured guide with:

Core principles distilled into actionable tests
Code patterns showing right vs. wrong approaches
Checklists the agent can verify against
Anti-patterns to avoid

The actual article contains extensive context, caveats, validation notes, and mobile-specific considerations. The clipboard version strips that down to what an agent needs to act.

This is subtle and kind of brilliant. The UI stays clean for humans. The payload is optimized for agents. Same button, two audiences.

How I’m using it

Triage’s embed code copy gives you something like:

Install the Triage feedback widget in my project.

## Widget Script
Add this script tag before the closing </body> tag (or in your app's head/layout).
IMPORTANT: The type="module" attribute is required.
<script type="module" src="https://triage.codebasehealth.com/widget.js"></script>

## Widget Component
Place this element wherever you want the "Report an issue" button to appear:
<triage-button
  public-key="your-key"
  agent-id="your-agent-id"
></triage-button>

## How It Works
1. User clicks the button wherever you placed it in your UI
2. A voice feedback panel opens near the button
3. User can speak or type their feedback
4. Feedback is submitted to an AI that triages it and writes the fix

## Framework Notes
- React/Next.js: Add the script to your layout
- Vue/Nuxt: Add script to nuxt.config or app.vue
- Plain HTML: Add both snippets where you want the button

A human reading that might skim most of it. An agent reading it has everything it needs to install the thing correctly on the first try.

The alternative is the agent guessing where to put it, getting it wrong, the human getting confused, and everyone wasting time. Front-loading the context means fewer round trips.

Agentic ergonomics

We have a whole field called ergonomics, designing physical things for human bodies. Chair height, keyboard angle, monitor distance. Decades of research on how to make tools fit humans better.

We have UX, designing digital things for human minds. Information hierarchy, interaction patterns, cognitive load. Decades of research on how to make software fit human thinking better.

We don’t have a word for designing things for agents. But we need one, because agents are users now, and they have different needs than humans.

What agents need:

Explicit context (they can’t always infer from visual layout)
Structured instructions (they parse text better than vibes)
Complete information (they waste time clicking around to find what’s missing)
Clear boundaries (what should they do? what shouldn’t they?)

What’s different for agents:

UI doesn’t matter, but information hierarchy still does (context windows have limits)
Progressive disclosure still helps (for the same reason, don’t dump everything at once)
Emotional design doesn’t matter (they don’t have feelings about your brand)
Discoverability matters, but works differently (agents read docs and skills better than browsing UIs)

Agentic ergonomics is the practice of designing for these differences. Agents don’t need a UI at all. They use CLIs, skills, MCP servers, llms.txt files, APIs. The interface layer that humans require is often just friction for agents.

Patterns that are emerging

The copy-for-agent pattern is one. Here are others I’ve noticed:

Prompt-ready error messages: Instead of “Error: Invalid input,” make it “Error: Invalid input. The ‘email’ field expected a valid email address but received ‘notanemail’. To fix this, ensure the input matches the format ‘user@domain.com’. Common causes include: [list].”

Humans can parse either one. Agents are way more effective with the second.

Imagine throwing agentic error messages into console logging. Or surfacing a “copy error for agent” button in the UI when something breaks. The user clicks, pastes into their agent, and the agent has everything it needs to debug.

Agent-facing documentation: Not just “here’s how to use this,” but “here’s how to install this, here are common patterns, here’s what usually goes wrong, here’s how to debug it.” llms.txt, MCPs, and SKILLS are an early version of this.

I’m building something in this direction with Driftless, generating skills and agent-ready instructions from human-written documentation. The docs stay readable for humans. The skills are optimized for agents.

Structured clipboard payloads: When copying code snippets, include metadata: what language, what framework, what version, what the code does, where it typically goes. The human sees code; the agent sees code plus everything it needs to use it correctly.

Explicit affordances: Instead of assuming the agent will figure out what actions are available, tell it directly. “You can: create, read, update, delete. You cannot: bulk delete, export. Rate limits: 100 requests per minute.”

The two-audience problem

The tricky part is serving both audiences at once. Humans and agents often look at the same interfaces, and they need different things.

Too much agent-friendly context clutters the UI for humans. Too little and agents struggle. The copy-for-agent pattern is elegant because it’s invisible: the human sees a clean button, the agent gets a rich payload.

This is early

We’re at the “cramming desktop apps into browsers” phase of agentic design. Most people are still thinking about agents as an add-on to human workflows, not as a primary user to design for.

But the patterns are emerging. Copy-for-agent. Prompt-ready errors. Agent-facing docs. Structured payloads. These are the early vocabulary of a field that doesn’t have a name yet.

I’m calling it agentic ergonomics until someone comes up with something better. The practice of designing tools, interfaces, and content for AI agents as first-class users.

Your copy button might be the first place to start.

How this blog does it

You might have noticed the “Copy for agent” button at the top of this post. It’s not decorative. Click it, and you’ll get a condensed implementation guide for the patterns in this article, not the full 2,000 words.

Here’s how I built it:

The generation pipeline uses a pre-build script that scans every blog post. If a post doesn’t have agent-ready copy yet, it sends the content to Claude (Opus 4.5) with instructions to condense it into an actionable implementation guide. The result gets written back to the post’s frontmatter as an agentCopy field. Once generated, it’s committed to git, so it only runs once per post.

// The prompt that generates agent copy
const SYSTEM_PROMPT = `Transform a blog post into a structured,
agent-ready format that an AI coding assistant can act on immediately.
Focus on ACTIONABLE patterns, not prose to read.
Keep it under 600 words.`;

The component is a simple Astro component that reads from frontmatter and copies to clipboard. The tricky part is Safari compatibility. Safari requires clipboard writes to happen synchronously within the user gesture handler, not in an async callback. Since the content is already loaded on the page (from frontmatter), we can write synchronously. For older browsers, there’s an execCommand('copy') fallback with a temporary textarea.

Astro’s content collections use Zod schemas. If you don’t declare a field in the schema, it gets stripped out during parsing. One line addition: agentCopy: z.string().optional().

The whole thing took about 30 minutes to implement. Now every post on this blog can have agent-optimized copy, generated automatically, served through a button that humans barely notice but agents will use constantly.

That’s agentic ergonomics in practice: invisible to humans, essential for agents.

Building something for agents? I’d love to hear what patterns you’re discovering: @davekiss