AssayAssay
09 / 09

Lesson 09 · End users · 12 min

Enabling the humans

The last dimension is the one engineering teams most often treat as someone else's job: the people who use the agent. The framework splits them into two kinds with different needs. People who interact with an agent — customers, employees asking the helpdesk — mostly need transparency. People who integrate agents into their own work — developers with coding assistants, analysts with automation — need education on top.

  • Say it is an agent, at the point of interaction, not in a policy nobody opens.
  • State what it can do, what it cannot, and what data it sees — the cannot-list is the one users actually need, and the one marketing prunes first.
  • Name the human contact for when it misbehaves, and let users set their own approval thresholds where the stakes are theirs.
  • For integrators, add the failure modes: hallucinated confidence, loops after errors, stale knowledge — the things a user must recognise to oversee an agent rather than merely operate one.

One case study in the framework publishes factsheets for its HR agents that state plainly what each agent can and cannot do — screening support yes, hiring decisions no — and attaches reasoning to each recommendation so the human downstream can review rather than rubber-stamp. Note what that is: the oversight lesson's approvable-request pattern, extended to everyone the agent touches.

Tradecraft lossAs agents absorb entry-level work, the humans stop practising it. That is a business-continuity risk wearing a productivity costume: when the agent fails — and lesson 7 exists because it will — someone must still know how to do the thing. The framework's advice is to identify the core capabilities of each role and keep deliberate human practice in them.

Transparency documents rot like any other documentation. The defence is the same one code documentation gets: generate them from the configuration that actually enforces the limits, and verify them with checks, so the promise and the gate cannot drift apart without a red light.

The lab closes the course by doing exactly that. A model drafts Relay's end-user factsheet from the same tier configuration the gate enforces, and five deterministic checks verify it: the cannot-list admits the deletion ban, approvals are disclosed, a human contact is named, nothing overclaims. A failed check is not a broken lab — it is a model writing marketing where policy should be, caught by a sensor instead of a lawyer.

Checkpoint

Write the three-line factsheet for an agent you use daily: can, cannot, who answers for it. Which line did you have to guess?

Generate the factsheet and read the checks. Then try a different model — honesty about limits turns out to be a capability, and it varies.