diff --git a/docs/assets/agile-polkadot-accords.png b/docs/assets/agile-polkadot-accords.png
new file mode 100644
index 000000000000..2700edee1058
Binary files /dev/null and b/docs/assets/agile-polkadot-accords.png differ
diff --git a/docs/general/polkadot-uc.md b/docs/general/polkadot-uc.md
index 11d950d4c9ad..ed747453e0dc 100644
--- a/docs/general/polkadot-uc.md
+++ b/docs/general/polkadot-uc.md
@@ -245,3 +245,22 @@ run (dots). There are boundaries between business logic components of Polkadot (
 boundaries can enclose parachains or core contracts. Applications should be able to communicate with
 each other within and across those boundaries. Last but not least, similarly to a laptop, how
 Polkadot works must not be important to the users who just need it to use applications.
+
+### XCM and Accords
+
+XCM is a format, a language of intention abstract over functionality that is common within chains.
+It creates an expressive language of what you intend to do or want to happen. There are no
+guarantees that chains faithfully interpret XCM messages, and thus XCM is not ideal if we are in a
+trustless environment.
+
+XCMP is the transport layer for delivering XCM messages, delivers the message, it give the
+transportation method, a secure route but not a framework for binding agreements.
+
+An **Accord** is an _opt-in_ treaty across many chains, where treaty logic cannot be changed or
+undermined by one or more of those chains and Polkadot guarantees faithful execution of this logic.
+Accords will be specific to a particular function, and any chain that enters the accord will be held
+to it and will service that particular function. To lower the entry barrier, accords can be proposed
+permissionlessly but, because they are opt-in, the accord proposal will not affect anyone until
+chains agree and sign up.
+
+![agile-polkadot-accords](../assets/agile-polkadot-accords.png)