The OSBR Handbook
Sign in

Building for AI Users

The software we ship is driven by both people and autonomous agents, so we plan for AI agents as first-class users — alongside humans — from the earliest scoping stage. This standard sets out who we build for; it complements the Development Guide and Quality Gate (which shape how we build and how work is held to a bar), the API Design Guide (the machine-consumable contracts agents call), the Application Security standard (least-privilege and auditability for agent-facing surfaces), and the Design Guidelines (the human-facing legibility that oversight depends on). It is the planning-time face of the AI Usage Guideline. Deviations are allowed, but — as everywhere in the handbook — they must be deliberate and justified in the project's design notes.

This is where OSBR's human⇄AI cooperation stance becomes concrete: design for both users, and keep humans in control. Be Nice: never trap a user — the person at the keyboard, or the humans behind an agent — in a process they cannot escape. Be Kind: make the system legible enough that people can genuinely understand and intervene, not merely rubber-stamp what an agent did. Be Strong: build systems robust enough to be trusted with autonomy, with a human path that holds even when the automation misbehaves.

How to read this policy

1. Goal

Plan every product so that:

  1. Both users are designed for. Humans and AI agents are both intended consumers of what we ship. Interfaces, data, and actions are reachable by machines without scraping, screen-driving, or reverse-engineering — the API-first posture of the API Design Guide, extended to agents.
  2. Humans stay in control. No AI-driven process runs where a human cannot see what it is doing, understand why, stop it cleanly, and take the wheel. This is human oversight as a hard requirement, not a feature bolted on later.

A capability that serves an agent audience but hides behind a human-only GUI, or an autonomous flow whose only off switch is killing the process, fails this goal regardless of how well it demos.

2. Responsibility

3. Two Users: Humans and Agents

3-1. Agents are users, not an afterthought

The industry is standardising on agentic AI — software that plans and acts toward goals with limited supervision — and on open protocols for agents to use tools and talk to one another. Plan for this reality:

You do not have to adopt MCP / WebMCP / A2A on day one. The requirement is to decide deliberately at planning time whether a capability has an agent audience, and to design the interface so that adopting these standards later is a small step, not a rewrite.

3-2. Machine-consumable by design

4. Keep Humans in the Loop

Every AI-driven process MUST provide a human path with four capabilities. Name them in the requirements and test them like any other acceptance criterion.

  1. Observe — a human can see, in near-real time and after the fact, what the agent is doing and has done. Emit structured logs, decisions, and the inputs behind them; standardising on OpenTelemetry keeps agent activity as inspectable as any other service.
  2. Interpret — the human can understand why the agent acted: what goal, what inputs, what tool calls, what alternatives. An action a human cannot interpret cannot be meaningfully approved or overridden, which is why the legibility the Design Guidelines require extends to agent activity too.
  3. Interrupt — the human can pause or stop the process cleanly, at any point, without corrupting state. This draws on the AI-safety notions of controllability and interruptibility: an agent should be safely interruptible — able to be stopped by an operator without the system learning to prevent, resist, or route around that intervention (Orseau & Armstrong, Safely Interruptible Agents).
  4. Take over — the human can assume manual control and complete or reverse the task themselves. Autonomous actions SHOULD therefore be reversible or confirmable (expand/contract, staged commits, undo), consistent with our deploy-safely-and-reversibly stance.

Human-in-the-loop means a human approves each consequential action before it takes effect; human-on-the-loop means the agent acts autonomously while a human monitors and can intervene. Both are legitimate; the choice depends on the autonomy level (§5) and the blast radius of a wrong action. Higher stakes ⇒ closer to in-the-loop. This mirrors the human oversight requirement in emerging AI governance (EU AI Act, Article 14) and the NIST AI Risk Management Framework.

5. Levels of Autonomy

State the autonomy level of each AI-driven feature explicitly, the way the automotive industry names SAE levels of driving automation (J3016) — from driver-assist to full self-driving (SAE J3016). The analogy is deliberate: the hard questions are the same — who is responsible for the task right now, and how fast can control hand back to a human?

A practical OSBR ladder:

Rules:

As with SAE's levels, the value is in the shared vocabulary, not in racing to the highest number. Most OSBR features should sit at L1–L3. L4 is a deliberate, justified choice for a narrow, well-bounded domain.

6. Planning Checklist

Answer these while scoping any feature that an agent might use or that acts autonomously:

If any answer is "we don't know yet," that is a planning gap to close before build — not a detail to discover in production.

References

Agentic AI & interoperability

API-first / machine-consumable design

Human oversight & AI governance

Controllability & interruptibility (AI safety)

Levels of autonomy (analogy)

Observability

Related OSBR standards