diff --git a/.claude/commands/release-notes.md b/.claude/commands/release-notes.md
index e37543a..47b6574 100644
--- a/.claude/commands/release-notes.md
+++ b/.claude/commands/release-notes.md
@@ -35,7 +35,7 @@ Note the generated links section will still compare against the last tag; the pr
 
 Do not write notes from commit subjects alone. Read the PR bodies (`gh pr view <n>`) and spot-check diffs where the description is thin. Classify everything into public-surface changes, fixes, and internals, then check specifically:
 
-- **The compatibility contract.** This is the load-bearing check. The public surface is the one defined in `CLAUDE.local.md` — the facades (`clients/*`), root exports, documented models, error classes, and auth config; generated internals are exempt unless they show up in a facade signature or doc. For every change to it, decide which bucket it is in and say so in the notes: **added** (free, rides a minor), **deprecated** (must name the replacement and the earliest removal major), **removed** (majors only, and only after a deprecation shipped at least one further minor and 90 days earlier), or **changed semantics** (a break, even when the signature is untouched). The integration template pins `>=1,<2`, so anything in the last two buckets breaks real consumers.
+- **The compatibility contract.** This is the load-bearing check. The public surface is the one defined in `CLAUDE.local.md` — the facades (`clients/*`), root exports, documented models, error classes, and auth config; generated internals are exempt unless they show up in a facade signature or doc. For every change to it, decide which bucket it is in and say so in the notes: **added** (free, rides a minor), **deprecated** (must name the replacement and the earliest removal major), **removed** (majors only, and only after a deprecation shipped at least one further minor and 90 days earlier), or **changed semantics** (a break, even when the signature is untouched). The integration template pins the current major, so anything in the last two buckets breaks real consumers.
 - **Regeneration vs. hand edits.** Most of `robosystems_client/` is generated by `just generate-sdk` from the API's OpenAPI spec, and the typed GraphQL models by ariadne-codegen from the checked-in `schema.graphql`. A regeneration that widens the surface is worth a sentence about what the API added — not a per-model enumeration. Say plainly when a release is a regeneration, and don't dress generated-internal churn up as new capability.
 - **Upstream API coupling.** A regeneration tracks a specific RoboSystems API version. If the new surface only works against an API that isn't deployed yet, the notes must say so — integrators will call it the day they upgrade.
 - **Runtime and dependency floors.** A raised Python floor or a dependency major is an upgrade blocker for someone. Note it.
diff --git a/README.md b/README.md
index 9ec7928..2a13233 100644
--- a/README.md
+++ b/README.md
@@ -11,7 +11,7 @@ Official Python client for the RoboSystems financial intelligence platform — a
 - **Async/await support** for high-performance applications
 - **Parquet file uploads** for table ingestion
 - **Streaming support** for memory-efficient processing of large result sets
-- **Financial AI Agent** integration for natural language queries
+- **AI Operator** integration for natural language financial analysis
 - **Comprehensive error handling** with typed exceptions
 
 ## Installation
@@ -20,16 +20,6 @@ Official Python client for the RoboSystems financial intelligence platform — a
 pip install robosystems-client
 ```
 
-## Versioning
-
-This client is `1.x` and follows semantic versioning, with one distinction worth knowing before you pin.
-
-The **stable surface** is the facades (`robosystems_client.clients`), the root exports, the error classes, the auth configuration, and every symbol used by [`robosystems-integration-template`](https://github.com/RoboFinSystems/robosystems-integration-template) — the emit path most integrations are built on. It is frozen for the life of `1.x`; breaking any of it costs a major version.
-
-The **generated surface** — the rest of `robosystems_client.api.*` and `models.*` — is regenerated from the platform's OpenAPI spec and tracks it. Operations there can be added, renamed, or removed on a minor release, and every such removal is named in that release's notes.
-
-So `robosystems-client>=1,<2` is the right pin if you build on the stable surface. If you depend on a generated operation outside it, either pin a minor range (`>=1.7,<1.8`) and read the release notes when you widen, or open an issue to have it promoted — the way something joins the stable surface is by being used in the integration template.
-
 ## Resources
 
 - [RoboSystems Platform](https://robosystems.ai)