chore: add basic context about Firezone for AI agents (#10284)

When using an AI-enabled editor (like Zed), it is useful to have a
"rules" file to give it basic context about the project so we don't have
to re-explain it every time.

We can also extend this file with a list of code review instructions /
coding guidelines for Copilot. See
https://docs.github.com/en/copilot/how-tos/configure-custom-instructions/add-repository-instructions#asking-copilot-coding-agent-to-generate-a-githubcopilot-instructionsmd-file.

I expect this file to grow as we learn which info the agents need about
the product to be helpful. In order to use it, people are encouraged to
create locally-ignored symlinks to the `docs/AGENT.md` file.

---------

Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

docs/AGENT.md

@@ -0,0 +1,33 @@
+# AI agent rules for Firezone
+
+## Summary
+
+Firezone is a zero-trust access platform built on top of WireGuard.
+The data plane components are built in Rust and reside in `rust/`.
+The control plane components are built in Elixir and reside in `elixir/`.
+
+## Data plane architecture
+
+At the core of the data plane resides a shared library called [`connlib`](../rust/connlib).
+It combines ICE (using the `str0m` library) and WireGuard (using the `boringtun` library) to establish on-the-fly tunnels between Clients and Gateways.
+The entry-point for the data plane is [`Tunnel`](../rust/connlib/tunnel) which acts as a big event-loop combining three components:
+
+- A platform-specific TUN device
+- A sans-IO state component representing either the Client or the Gateway
+- A platform-specific UDP socket
+
+Packets from IO sources (TUN device and UDP socket) are passed to the state component, resulting in a UDP or IP packet.
+The state component also manages ICE through the [`snownet`](../rust/connlib/snownet) library, so some UDP traffic is handled internally and does not yield an IP packet.
+
+These three components are split into multiple threads and connected via bounded channels:
+
+- 1 thread for reading from the TUN device
+- 1 thread for writing to the TUN device
+- 1 thread for handling IPv4 UDP traffic with 1 task each for sending / receiving
+- 1 thread for handling IPv6 UDP traffic with 1 task each for sending / receiving
+- 1 task on the "main" thread that holds the state and reads / writes from and to the channels connecting to the IO threads
+
+## Code review guidelines
+
+- Assume that code compiles and is syntactically correct.
+- Focus on consistency and correctness.