A few practical patterns/gotchas that tend to matter for this kind of setup:

1. Bedrock doesn't have a native Genie connector, so the usual approach is to implement the call as a Bedrock Agent action group backed by a Lambda function. The Lambda wraps Databricks' Genie Conversation API (start a conversation, ask a question, poll for the answer) and returns Genie's response text - and optionally the generated SQL and result table - back to the Bedrock agent as the action group's output.

2. Auth across multiple Databricks accounts: you'll need per-account credentials (a Databricks service principal with OAuth M2M is preferable to a long-lived PAT), and your Lambda needs to select the right workspace host / credentials / Genie Space ID depending on which account the request is meant for. Keeping an account -> workspace URL -> Genie Space ID mapping as agent/Lambda configuration keeps this manageable as it grows.

3. Genie Space scoping: each Genie Space belongs to one workspace and a defined set of tables. If your multiple accounts correspond to different data domains, "one Genie Space per account" is usually the natural mapping, and the Bedrock agent's job becomes mostly routing + credential selection rather than anything Genie-specific.

4. Latency/async handling: Genie calls are asynchronous under the hood (start conversation, then poll for message status), so if you're wiring this as a synchronous Bedrock action group, budget for polling with backoff inside the Lambda, and set your Lambda/Bedrock timeouts generously enough to cover that.

5. Least privilege: scope the Lambda's execution role/secrets so it only has access to the credentials for the account(s) it's actually allowed to route to, rather than one broad credential with access across all accounts.

If you can share whether you're using action groups vs. a custom orchestrator on the Bedrock side, that would help narrow down more specific guidance.