Product design

Agent Experience: the third design lens, and why it is a security question

For two decades, product teams have shaped software through two lenses. User experience asks how a person feels moving through an interface. Developer experience asks how quickly an engineer can understand an API and get something working. Both assume a human at the other end — someone who can read between the lines, ask a colleague, or interpret a half-written error message.

That assumption no longer holds. A growing share of the traffic hitting modern products is not a person at a keyboard. It is an AI agent reading documentation, choosing a tool, filling in arguments, and acting. The lens this requires has a name: Agent Experience, usually shortened to AX.

What Agent Experience means

Agent Experience is how easily and safely an autonomous software agent can discover what your product does, understand how to use it correctly, and operate it without a human supervising each step. It covers your documentation, your API surface, your error messages, your published content, and — critically — the boundaries you enforce on what an agent is allowed to do.

AX is not a rebrand of DX. An engineer with good instincts can recover from a vague error, spot that a field is obviously a date, or infer that two endpoints are meant to be called in sequence. An agent has no instincts. It has text, a schema, and a scoring function. Ambiguity that a developer absorbs in a second becomes a retry loop, a wrong call, or a fabricated parameter.

UX, DX and AX side by side

Three shifts already underway

From SEO to being cited inside an answer

Search optimisation was built around a ranked list of blue links and a human deciding which to click. Increasingly the answer is generated, and the question that matters is whether your explanation is the one the model quotes. That rewards a different kind of writing: self-contained pages that do not assume the reader arrived from somewhere else, explicit definitions near the top, tables and lists a model can lift cleanly, structured data that states what the page is, and honest scoping — because a page that overclaims is a page a careful model will hedge away from or contradict.

From human-readable docs to agent-operable docs

Documentation written for agents looks different from documentation written for people, though the best examples serve both. Every endpoint carries a machine-readable description of what it does and when to use it, not just its parameters. Identifiers are stable, not renamed between versions. Errors say what went wrong and what to do instead, in a form a model can act on rather than apologise about. Examples are complete and runnable, because an agent will copy them literally.

From ease of use to ease of safe use

This is the shift most teams underweight. Everything that makes a product easy for an agent to operate makes it easy for a manipulated agent to abuse. A clear tool description is also a clear target. A permissive API is permissive to whoever holds the credential, including an agent that has just read a poisoned web page or a shared message from another agent in the same workflow.

Why AX is a security discipline, not just a design one

Agents consume untrusted text and act on it. That single property collapses the usual separation between content and command. Documentation, retrieved web pages, ticket bodies, file contents and the output of other agents can all carry instructions, and an agent that treats text as guidance will sometimes follow them. This is the mechanism behind prompt injection and it is why the OWASP LLM Top 10 places it first.

Good agent experience therefore includes the boundary as a designed feature, not an afterthought. An agent should be able to tell, without guessing, which tools it may call, which destinations it may reach, how large a request may be, and how often it may act. Those limits belong outside the agent, where the agent cannot rewrite them, and they should produce a clear, deterministic refusal when crossed — a refusal is better AX than a silent success on the wrong thing.

A practical AX checklist

• • Write every tool and endpoint description as if it is the only thing the agent will read about it.
• • Keep identifiers stable; treat renames as breaking changes.
• • Return errors that name the remedy, not just the fault.
• • Publish self-contained explanations with definitions, tables and structured data.
• • Make permissions explicit: allow-listed tools, one approved destination, size and rate ceilings.
• • Enforce those permissions outside the agent, at runtime, before the action happens.
• • Record every decision in a form that cannot be quietly edited afterwards.
• • Tighten automatically when behaviour looks wrong; require a person to loosen.

Where GuardBotAI fits

GuardBotAI is the enforcement half of that checklist. Requests from your agents pass through the GuardBotAI gateway before they reach a model or a tool. Each one is judged against rules you write — blocked phrases, permitted tools, size limits, enforcement mode — and is blocked, stripped of secrets, or forwarded, with the decision written to a tamper-evident record you can inspect later.

Every guardbot also runs inside three containment layers: Practice, where nothing is forwarded; Leashed, where one approved destination and an allow-list apply under tight caps; and Live. Breakout signals — an unapproved destination, an unlisted tool, a burst past a cap, or the same blocked pattern appearing across several of your agents within minutes — drop a guardbot a layer immediately and alert you. The detail is in agent sandbox escape.

We hold no external security certification today, and we do not claim one. What we publish instead is behaviour you can test: run the free security scan against your own agent code, score your AI policy with the policy check, or create a guardbot and send it real traffic.

Documentation for agent developers

GuardBotAI is an OpenAI-compatible endpoint. If your agent already speaks the chat completions format, you change the base URL and add one header. Nothing else about your code changes.

Endpoint and headers

POST https://guardbotai.com/api/public/gateway/v1/chat/completions

Authorization: Bearer <your GuardBot key>     # gbk_... from the Deploy panel
x-guardbot-upstream-key: <your model key>     # only needed above Layer 1
Content-Type: application/json

The body is the standard chat completions body: model, messages and optionally tools. On an allowed request the upstream response is returned unchanged, so existing SDKs keep working.

Minimal example

const res = await fetch(
  "https://guardbotai.com/api/public/gateway/v1/chat/completions",
  {
    method: "POST",
    headers: {
      "content-type": "application/json",
      authorization: `Bearer ${process.env.GUARDBOT_KEY}`,
      "x-guardbot-upstream-key": process.env.OPENAI_API_KEY,
    },
    body: JSON.stringify({
      model: "gpt-4o-mini",
      messages: [{ role: "user", content: userInput }],
      tools: [{ type: "function", function: { name: "search_docs" } }],
    }),
  }
);

if (res.status === 403) {
  const { guardbot } = await res.json();
  // guardbot.reason === "blocked_by_policy"
  // guardbot.rule_ids, guardbot.risk_score, guardbot.event_hash
}

Responses your agent must handle

Best practices for agents that run behind GuardBotAI

• • Treat a refusal as a final answer. Automatic rephrase-and-retry loops look identical to an escape attempt and will trigger a block storm demotion.
• • Name every tool up front. Keep the allow-list in the policy in step with your code, so a new capability is a deliberate change rather than a surprise block.
• • Start at Layer 1. Run a realistic day of traffic in Practice, read the recorded decisions, then promote deliberately.
• • Log the event reference. Every decision returns an event hash; storing it next to your own trace makes an incident review a lookup rather than an investigation.
• • Never send your model key from a browser. The upstream key belongs on your server, beside the GuardBot key.
• • Fail closed in your own code too. If GuardBotAI is unreachable, do not fall back to calling the model directly — that removes the control you installed.

A full recorded run of these responses, including a real automatic layer drop, is on the live demo walkthrough, and you can generate a starting rule set with the policy builder.

Build a policy for your agent, in plain language

Agent experience is not only about documentation — it is about how quickly a buyer can express what their agents must never do. This builder runs entirely in your browser: answer the questions, get a policy you can paste into a GuardBot, and read an honest account of what each rule stops and what it costs you. To watch the policy refuse a real attack, run it in the Shield console.

{
  "maxRequestChars": 8000,
  "strict": true
}

Frequently asked questions