[kaxil]

The common.ai docs say nothing about memory, so it looks like the provider has none. Agents here already run on Pydantic AI, so pydantic-ai-harness's Memory capability works through capabilities= today, with no new code in the provider. This PR adds a page that shows how, and says how Strands and ADK agents use their own memory.

The new page, memory.rst under Features, has two examples in example_agent_memory.py:

• A recurring AgentOperator with SqliteMemoryStore. A daily triage agent keeps notes on failure causes across Dag runs.
• Per-customer memory with PostgresMemoryStore. A mapped task gives each customer its own namespace, and the database credentials come from an Airflow connection.

The second example is your own agent in a @task, not AgentOperator. PostgresMemoryStore takes an asyncpg pool, the pool has to be awaited into existence, and it only works on the event loop that created it. A pool built in the Dag file can't be handed to AgentOperator, which runs the agent with run_sync. The task uses asyncio.run, not an async def task, so the example still works on the Airflow 2.11 floor.

The page leads with where the store lives. Celery and Kubernetes workers don't share a disk, so a local SQLite file or FileStore is gone by the next run. The store table says which store fits which deployment.

Checked in breeze with pydantic-ai-harness 0.24.0, the floor the code-mode extra already uses:

• A note written in one run reaches the next run's request inside a <memory> block.
• The SQLite file is shared across two dags test runs.
• The Postgres table holds acme/main/MEMORY.md and globex/main/MEMORY.md from the mapped run.

Those runs used the test model, which calls every tool with generated arguments, so read_memory fails on a made-up file name. The Dags have not been run against a real model yet.