The Well-Architected Framework for intelligent workloads

The Power Platform Well-Architected pillars, applied to an agent. What makes this
card useful is that each pillar turns into a question you can actually ask about
a design, rather than remaining an abstract quality.

The five pillars, as questions

Reliability. What happens when grounding, a connector or the model fails? Is
there a fallback?

Security. What can it reach, as whom, and what leaves the boundary? The
middle clause is the one people skip — an agent acts as some identity, and which
identity that is decides everything about its reach.

Operational excellence. Who owns it, how is it monitored, and how is it
changed safely?

Performance efficiency. What latency will the user tolerate, and what does the
token cost look like at real volume rather than pilot volume?

Experience optimisation. Do people trust it, understand it, and know when it
is unsure?

What good looks like

Reliability and performance. Graceful degradation rather than a dead end. Cost
modelled at target adoption, not at pilot volume — the two differ by an order of
magnitude and only one of them is the number you will actually pay. And a
reminder that every agent hop adds latency and tokens.

Security and operations. The acting identity decided deliberately rather than
inherited by accident. A named owner and an entry in the register. Telemetry
and evaluation, because they answer different questions — telemetry tells you
what happened, evaluation tells you whether it was any good.

Experience. The agent says when it does not know. Users are told they are
dealing with AI. There is a visible route to a human.

Exam trap. Well-Architected questions reward the boring option. Ownership,
monitoring, fallback behaviour and a documented failure path beat a more capable
design with none of them — because the pillar being tested is usually
operational excellence, not capability.

The one line to carry: when a question offers impressive against
well-operated, the exam wants well-operated.