AI & agents — Ask DynoStudio, Agent mode, MCP Gateway

Ask DynoStudio turns plain English into a PartiQL draft you review and run from the editor. Agent mode investigates questions such as “why is this export slow?” and proposes reads, indexes, or models for your approval. The MCP Gateway connects Claude Code, Cursor, or another MCP client to your table context and query tools. Connected clients can execute SELECT queries after obtaining an analyzer-issued plan, within the gateway’s session limits, and single-item writes only in a session you arm.

Turn it on

• Settings → AI & agents — one switch for this user on this machine. It is deliberately not a workspace setting: “do not send my data to a model” is a statement about you, not about a workspace someone else may also open.
• Pick a provider — Bedrock runs under the active stage’s own AWS identity, in the Region set in Settings (default us-east-1) — not necessarily the stage’s Region — with the model’s price read from the public AWS price list and shown beside the picker. The default model id, global.amazon.nova-2-lite-v1:0, is a global cross-Region inference profile, so AWS may serve a request from another commercial Region; if residency matters, pick a model id scoped to your geography. Embeddings run in the active stage’s Region. Local talks to an OpenAI-compatible server on this machine — Ollama, LM Studio and vLLM are auto-detected on their default loopback ports — so no prompt leaves it. There is no bundled key and no Kanject-hosted inference.
• Pick a model — the Bedrock roster is discovered from your account; Amazon Nova 2 Lite is the default because it needs no third-party model-access form. Any Bedrock model id can be typed in. Embeddings for EMBED() and re-embed jobs use Amazon Titan Text v2 by default, with Titan v1 and Cohere Embed v3 (English or multilingual) as alternatives.

The disclaimer the app shows on every AI surface applies here too: AI can make mistakes — check queries and answers before you rely on them.

Ask DynoStudio

Describe what you need and get an analyzer-checked draft. The composer builds its prompt from schema and access patterns; the model drafts a PartiQL statement; the same analyzer that checks your own statements checks the draft against the connected descriptor. The result card shows analyzer facts — Query or Scan, which index, what it reads — never model narration.

• Four entry points, one gate — the standalone PartiQL console, a table’s Browse lens, the Board, and ⌘K (“Ask DynoStudio”).
• Insert, never Run — the card’s terminal action is Insert into editor. There is no Run action on the card by design: running is your keystroke, through the normal “Executes as” disclosure.
• No row data — row values are absent from the prompt by construction, not by a flag defaulting to off. Every draft asserts the No row data chip, and View exact AI payload shows the wire verbatim: what the UI reveals and what is sent are the same object.

Agent mode

State an objective — why is this export slow, which index would serve this access pattern, what should this model look like — and the agent investigates. It works through a closed vocabulary of actions that the studio dispatches — the model never invokes a tool itself — and proposes; you approve.

• Investigation depth — Low, Medium or High beside the model picker sets the budget one objective may spend. Six meters show it live: rounds, model calls, actions, active time, tokens in and tokens out. (Depth changes budgets, not the model’s own reasoning — the ledger says so.)
• Rows — off by default, remembered per stage for the current app session only. With Rows on, the records a Kanject index lookup returns (up to 25) enter the agent’s context while it investigates, with no separate approval; a bounded sample still runs only when you approve it. With Rows off, the agent sees a lookup’s counts and whether a record exists, never the record.
• Next questions — a ranked, dismissible strip of suggested follow-ups above the composer, drawn from your own workspace. Model re-ranking of the deck is opt-in and capped.
• Dock faces — Browse, Query and Model open inside Agent mode, so evidence and proposal sit side by side.

MCP Gateway

Turn on Serve local agents and DynoStudio hosts a Model Context Protocol server on this machine that exposes the studio’s deterministic capabilities — never a raw DynamoDB connection. It binds to loopback only, issues a per-session bearer token shown exactly once, and is off by default.

get_schema            list_tables          get_modelget_model_diagram     propose_model        get_design_notesget_access_patterns   inspect_table_health inspect_usageinspect_metrics       preview_write        execute_writeverify_write_outcome  plan_bulk_operation  explain_queryrun_query             lookup_kanject_index

Five guarantees are rendered in Settings and are not configurable, by design — they bound what a mistake can do, not whether one happens:

Explain before run   execution needs a plan the analyzer issuedSELECT only          run_query refuses writes; one-item writes need an armed sessionStage pinned         changing tabs never retargets a connected agentRows off by default  granted explicitly, per sessionEvery call journaled tool, stage, outcome and cost stay on this machine

• Gateway console — one click runs a wall-by-wall transport self-test of the endpoint; one more prints the exact connection snippet for the client you run (Claude Code, Cursor, or plain curl).
• Journal — every call records tool, stage, outcome and cost, with no bearer token, credential or row data on the record.
• Egress caps — a session’s reads are bounded by row count, bytes, RCU and time; a VECTOR_DISTANCE search is refused through the gateway today.

What the model sees

• Ask DynoStudio — schema and access patterns. Row data is absent by construction; the exact payload is inspectable.
• Agent mode — schema, access patterns, design notes and row-free runtime statistics (counts, capacity, latency, CloudWatch digests). Row values only while Rows is on for that stage: up to 25 records per Kanject index lookup, and a capped sample after your approval.
• MCP Gateway — schema, plans and statistics for every approved session; query rows only if you grant them for that session. The connected client sends what it receives to its own model.
• Inferring a model from a live table — no model at all. The sample is read and clustered on your machine, in every edition, with AI & agents off. When Agent mode proposes the inference, the rows still stay local; the inferred shape becomes schema the agent can see, like any model.
• Re-embed jobs — send row values selected by an explicit, user-authored recipe ({Title}\n{Description}) to an embedding model one item per call, never batched or chunked. Query history stores a digest of a query vector, never the floats.
• Names are schema — table, entity, attribute and index names, and the literal prefixes in your key templates (ORDER#…), reach the model whenever you use Ask DynoStudio, Agent mode or the gateway. They are not row values, but they are yours; treat them accordingly.
• DynoStudio’s model provider — a local model keeps prompts on your machine. Bedrock uses your account and the active stage’s identity, in the Region set in Settings. Connected MCP clients use their own model configuration.
• Switch off — every AI entry point is refused and nothing is sent, in every edition.

Editions

• Community — carries the AI & agents switch (a privacy control has to exist at every edition) but not the AI surfaces; the Ask and Agent entry points offer the Professional upgrade.
• Professional, Business, Enterprise — Ask DynoStudio, Agent mode, the MCP Gateway, the Gateway console and the DynamoDB expert. For Ask and Agent mode, bring your own Bedrock access or local model. AWS bills Bedrock usage separately; local inference has no per-request provider fee.

Related: Vector similarity search · CREATE / DROP VECTOR INDEX · Targeted reads · Tables, indexes & replicas.