Designing Agent Experience Outside-In, When the Consumer Can't Complain

Every discipline that ever served a consumer well began by admitting it had been designing from the inside out.

Service design got there first. In January 1984, G. Lynn Shostack published Designing Services That Deliver in the Harvard Business Review and opened on symptoms rather than theory: a shirt back from the laundry with a broken button, a customer service rep who says he will get back to you and doesn’t. Her diagnosis was that services failed because nobody had drawn them. Her fix was the service blueprint, and the line on it that mattered most was the line of visibility — separating what the customer sees from what the organisation does backstage. Twenty-eight years later, Harley Manning and Kerry Bodine named the flip in Outside In (Forrester, May 2012): stop designing around the org chart and the database schema, start from the customer’s goal.

We are making the original mistake again, at speed, for a new consumer. Agent Experience needs the outside-in flip. But the honest version of this argument has to say which half of CX transfers — and which half breaks completely.

The lineage is already written

Mathias Biilmann named AX in January 2025, placing it in an explicit lineage: Don Norman coined user experience in 1993, Jeremiah Lee coined developer experience in 2011, and now AX — “the holistic experience AI agents will have as the user of a product or platform.” His warning is the one worth repeating, because most of the market is doing the opposite:

“Too many companies are focusing on adding shallow AI features all over their products or building yet another AI agent. The real breakthrough will be thinking about how your customers’ favorite agents can help them derive more value from your product.”

That is the difference between decorating a product with AI and treating agents as a consumer whose experience you are accountable for.

The half of CX that transfers

Four CX disciplines carry over cleanly, because each is a design-time decision about a boundary.

The third row is the sharpest transfer. Stop Trying to Delight Your Customers (HBR, 2010) studied 75,000 customer interactions and found that reducing customer effort predicted loyalty better than increasing satisfaction did. Delight was expensive and marginal; friction was cheap to remove and decisive.

Agent effort is the same variable, and easier to read because it arrives on an invoice. Every extra tool the model must disambiguate, every intermediate payload dragged through the context window, every round-trip to re-plan after a call returned the wrong shape — that is effort, priced per token, on every turn.

Shostack’s line is the second transfer, and more literal than it sounds. A blueprint separates front-stage — what the customer sees and judges — from backstage. An agent-facing surface has exactly that line: the handful of task-shaped tools the model reasons over, and the upstream operations, credentials and sequencing that fulfil them. Leave it undrawn and the backstage leaks into the model’s context, one vendor field at a time.

The half that does not transfer

Here is where the analogy has to stop, and where most AX writing quietly cheats.

Outside-in worked in CX because the customer could complain. Half of the discipline was design; the other half was listening — surveys, NPS, Customer Effort Score, complaint logs, churn. When the design was wrong, the customer told you or left, and either signal was legible.

An agent does neither. A confused agent does not file a ticket. It picks a plausible tool, invents a parameter name, retries, and bills you for all three attempts. The failure looks like success: a response came back, the tokens were spent, and the answer was wrong in a way that reads fluent. There is nothing to survey — only a trace nobody read and a line item nobody questioned.

The consequence is hard. When you cannot hear the consumer, you cannot iterate your way to a good experience. CX could afford a mediocre first design because the feedback loop corrected it. AX cannot, so the work moves earlier — into a contract a human reviews before anything runs. That raises the bar in three places a human consumer never needed:

• Descriptions must survive being read out of context. A human reads a button label with the whole screen around it. A model reads a tool description as a line in a list, next to twenty-four near-duplicates.
• Behaviour must be declared, not discovered. Safe? Idempotent? Destructive? A human finds out by trying it once and telling you. An agent finds out in production.
• The credential has to be inspectable. If the surface exposes four operations, a reviewer should establish that the credential authorises four by reading the artifact — not by watching what happens.

None of that is something a protocol gives you. It is design-time work, and it has to land in a file.

What outside-in looks like when you write it down

Yesterday’s post on the BFF pattern for context engineering made the scoping argument: one agent’s task, one applied capability. This is the same artifact viewed from the consumer’s side — what the agent sees, and what it is spared.

Here is a support agent’s refund desk, declared in Ikanos. Read it outside-in: exposes is everything the agent knows about; everything else sits behind the line.

ikanos: "1.0.0-beta5"

binds:
  - namespace: billing-env
    location: "vault://secret/support"
    keys:
      BILLING_TOKEN: "billing-service-token"   # a reference, never a literal

capability:
  consumes:                        # backstage — the agent never sees this
    - import: billing
      from: ./shared/billing-api.yml
      # every upstream operation the credential can reach is enumerated there

  aggregates:
    - display: "Refund Desk"
      namespace: refund-desk
      flows:
        assess-refund:
          description: "Assess whether a charge is refundable, and on what policy."
          semantics:               # declared behaviour, not discovered behaviour
            safe: true
            idempotent: true
            cacheable: false
          inputParameters:
            charge-id:
              type: string
              required: true
          steps:                   # three upstream calls, one model turn
            get-charge:
              type: call
              call: billing.get-charge
              with:
                id: "{{charge-id}}"
            list-policies:
              type: call
              call: billing.list-refund-policies
            match-policy:
              type: lookup         # correlate server-side, off the critical path
              index: list-policies
              match: productCode
              lookupValue: "$.get-charge.product_code"
              outputParameters:
                - "windowDays"
          mappings:                # the shape the task needs, not the vendor's record
            - target: amount
              value: "$.get-charge.amount_cents"
            - target: status
              value: "$.get-charge.status"
            - target: refund-window-days
              value: "$.match-policy.windowDays"
          outputParameters:
            amount:
              type: number
            status:
              type: string
            refund-window-days:
              type: number

  exposes:                         # front-stage — the whole agent-facing surface
    - type: mcp
      port: 3001
      namespace: support-copilot
      tools:
        assess-refund:
          description: "Check whether a charge can be refunded, before offering one"
          ref: refund-desk.assess-refund
          hints:
            readOnly: true
            idempotent: true

    - type: rest                   # same flow, human-facing portal
      port: 8080
      namespace: support-api
      resources:
        charge-refund:
          path: "/charges/{{charge-id}}/refund-assessment"
          operations:
            assess-refund:
              method: GET
              inputParameters:
                charge-id:
                  in: path
                  type: string
              ref: refund-desk.assess-refund

Four outside-in properties fall out of the shape, not the tooling:

• The line of visibility is a block boundary. exposes is front-stage; consumes and aggregates are backstage. Shostack drew that line on paper in 1984; here the file enforces it.
• Effort is bounded at design time. Three upstream calls, one exchange with the model. Expose them as three tools and you have tripled the agent’s effort to buy nothing.
• Behaviour is declared, so the agent need not find out. semantics travel with the flow whatever surface projects it; hints map to MCP’s tool annotations.
• One artifact, two consumers. The agent gets MCP, the portal gets REST, from the same aggregates block. The duplication BFFs accepted was in the transport, and a projection removes it.

What the spec covers today

The 1.0.0-beta5 file above is already carrying most of the outside-in weight, and it is worth naming which parts do the work.

The boundary itself. consumes enumerates every upstream operation reachable behind the surface; exposes is the whole front-stage. That split is what lets a reviewer answer “what can this credential do?” by reading, and it is the property a facade written in general-purpose code cannot offer.

Declared behaviour. semantics and MCP hints say up front whether a tool is safe, idempotent, cacheable or destructive. The agent is told, rather than left to discover in production.

Credentials by reference. binds resolves tokens from file://, vault:// or k8s-secret://, so a literal secret in an auth block is a defect a reviewer and a linter can both catch — not a habit.

Checkable, not just readable. Ikanos ships a ruleset, ikanos-rules.yml, that Polychro executes — an open source linter that speaks the Spectral ruleset format but treats any YAML, JSON or Markdown document as a first-class spec, not just OpenAPI. It runs as a GitHub Action over a pull request and inside the editor through the Crafter extension, so the artifact’s claims are enforced where they are written rather than trusted.

And approval — the thing readers expect to find as a governance: field — is deliberately not one. It lives in the lifecycle: a review gate on the YAML, then a second gate where least-privilege credentials are bound. A step on the path to production, not a runtime condition the agent might route around. That same lifecycle is why a capability with no consumes block at all runs as a callable mock server: you can build and exercise the entire front-stage before an upstream exists.

What comes next

Two gaps are worth naming, because a surface whose limits are legible is the whole argument.

Resilience is designed, not shipped. There is no retry, timeLimiter or resolution policy in beta5 — the resolution-policies blueprint works these out as mock, failover and cache families sharing one scenarios catalog, with retry exhaustion as the trigger that gives failover a precise definition. Until it lands, a flaky upstream is your orchestration layer’s problem.

Sequences need a layer above. As Jean-Jacques Dubray puts it, allowed calls and safe sequences are not the same thing — enumeration bounds the moves, not the paths. A capability can be individually correct at every step and still be walked somewhere unwanted. That belongs in human-legible invariants above the artifact, and no semantics flag substitutes for it.

Which is the outside-in point, and the reason to write the boundary down rather than leave it implicit. The value of a declared surface is not that it expresses everything, but that a reviewer can tell what it expresses — including where it stops, and what still needs a different layer.

Where this leaves the analogy

Outside-in is the right instinct and it is forty years old. What changes is the ratio. CX split its effort between designing the journey and listening to the people on it; AX gets one of those. The listening half degrades into traces and invoices — real signals, but slow, indirect, and silent about the near-misses where the agent guessed right for the wrong reason. So the design half carries more weight, and the only way to carry weight at design time is to write the contract down where somebody can check it.

Forrester’s 2025 CX Index found customer experience quality at an all-time low, attributed partly to disappointing technology implementations — in a discipline with mature measurement and forty years of practice. That is the field with the feedback loop. Worth being clear-eyed about a field without one.

The takeaway

• Outside-in is not new and not an AI idea. Shostack drew the service blueprint in 1984; Manning and Bodine named the flip in 2012; Biilmann applied it to agents in 2025.
• Four CX practices transfer: journey mapping, the line of visibility, effort over delight, and governance with an owner — all design-time decisions about a boundary.
• The measurement half does not. A confused agent does not complain; it retries, guesses, and bills you. The failure reads like success.
• So the work moves earlier. Descriptions that survive being read out of context, behaviour declared rather than discovered, credentials a reviewer can enumerate.
• The line of visibility becomes a block boundary. exposes is what the agent sees; consumes and aggregates are what it is spared.
• Approval is a gate in the lifecycle, not a field in the file. Putting it in the spec moves the decision back inside the box the reviewer is trying to see into.
• Say where the artifact stops. A surface whose limits are legible beats one that claims everything and can be read by nobody.

Shostack’s symptoms were all the same failure: a service nobody had drawn. Point an agent at three hundred undrawn endpoints and you get the 2026 version, with a bill attached.

Further reading

• 🧭 Designing Services That Deliver — G. Lynn Shostack, HBR, January 1984
• 🔄 Outside In: The Power of Putting Customers at the Center of Your Business — Harley Manning and Kerry Bodine, Forrester, May 2012
• 🤖 Introducing AX: Why Agent Experience Matters — Mathias Biilmann, January 2025
• 📉 Stop Trying to Delight Your Customers — Dixon, Freeman and Toman, HBR, 2010
• 🔐 The capability lifecycle — from mocked APIs to trusted production
• 🧱 Applied capabilities: the BFF pattern for context engineering
• 🧩 Agents undid twenty years of API curation. Put it back with capabilities.
• 🔍 Dynamic tool discovery and the limits of finding the right tool
• 🎓 Track 1 — context engineering, hands on · ⚙️ Ikanos