Amplitude Experiment connector for AI agents

Tools your experimentation agent reaches for on Amplitude Experiment, scoped per tenant.

CALL ANY TOOL

Feature flags and experiments in one toolkit: flags, variants, cohort and user targeting, mutex groups, holdouts, and deployments. The bearer token stays vaulted.

amplitudeexperimentmanagement_add_experiment_variant_cohorts

Add experiment variant cohorts

Add specific cohorts to this experiment variant's targeting inclusions. This adds to the variant's existing cohort inclusions; it does not replace them. CONFIRMED from Amplitude's docs: POST /api/1/experiments/{id}/variants/{variantKey}/cohorts with body {"inclusions": [...]}, an array of cohort ID strings. CONFIRMED no inclusion-count limit is documented for cohorts on either the Flags or Experiments API docs pages — the 2,000-inclusion cap that exists for user/device inclusions is stated by Amplitude as applying specifically to users on the Flags side, and cohorts aren't mentioned there at all. A successful call returns 200 OK with the literal text "OK", not a JSON body. Rate limit: 100 requests/second and 100,000/day, shared across the whole Experiment Management API (not per-endpoint). CONFIRMED (inferred from the identical flags-side finding, not independently confirmed): a well-formed request with a syntactically valid cohort_id that does not correspond to a REAL, existing Amplitude cohort returns a generic HTTP 400 "Internal server error" from Amplitude, not a clean validation error — unlike user_ids, which accept arbitrary/free-form identifiers without requiring them to pre-exist. Use a real cohort ID from this Amplitude project's Cohorts, or expect this error.

Parameters

Name

Type

Required

Description

cohort_ids

string

Required

Cohort IDs to add to this variant's targeting, as a JSON-encoded array of strings.

string

Required

The experiment's ID.

variant_key

string

Required

The variant's key.

amplitudeexperimentmanagement_add_flag_variant_cohorts

Add flag variant cohorts

Add specific cohorts as inclusions on a variant of an Amplitude Experiment feature flag — explicitly assigning these cohorts to this variant regardless of the variant's rollout weight. UNCONFIRMED: unlike the users endpoint, Amplitude's docs don't mention any documented maximum on the number of cohort inclusions per variant, nor whether this call is additive or replaces the existing cohort list — treat both as unconfirmed until independently live-tested. CONFIRMED (live-tested): this org has Feature Experimentation entitlement. Per Amplitude's docs, a successful call returns a 200 OK response with the literal text "OK" as the body — not a JSON object — so the tool treats the response as raw text rather than parsing it as JSON. Rate limit: 100 requests/second and 100,000/day, shared across the whole Experiment Management API (not per-endpoint). FIXED (was broken, now live-tested): this field is JSON-encoded per its schema, but was previously mapped via a plain body_json_mapping template that sent the raw string instead of a parsed array/object — Amplitude rejected it (e.g. "\"inclusions\" must be an array"). Now uses a jsonnet_template with std.parseJson() to correctly convert it before sending, matching the pattern the Experiments-side tools already used. Confirmed working end-to-end live. CONFIRMED (live-tested): a well-formed request with a syntactically valid cohort_id that does not correspond to a REAL, existing Amplitude cohort returns a generic HTTP 400 "Internal server error" from Amplitude, not a clean validation error — unlike user_ids, which accept arbitrary/free-form identifiers without requiring them to pre-exist. Use a real cohort ID from this Amplitude project's Cohorts, or expect this error.

Parameters

Name

Type

Required

Description

cohort_ids

string

Required

JSON-encoded array of cohort IDs to add as inclusions on this variant.

string

Required

The flag's ID (not its key) — find it in the URL of the flag's page in the Amplitude app.

variant_key

string

Required

The key of the variant to add cohort inclusions to.

amplitudeexperimentmanagement_bulk_delete_experiment_variant_cohorts

Bulk delete experiment variant cohorts

amplitudeexperimentmanagement_bulk_delete_flag_variant_cohorts

Bulk delete flag variant cohorts

amplitudeexperimentmanagement_create_deployment

Create deployment

amplitudeexperimentmanagement_create_experiment

Create experiment

Create a new Amplitude experiment. Required: project_id, key. name is technically optional per this tool (Amplitude's docs disagree), but supply it anyway — every documented example includes it. deliveryMethod and rolloutPercentage are not create-time fields — only projectId, key, name, description, variants, bucketingKey, rolloutWeights, targetSegments, deployments, evaluationMode, experimentType are documented as create-time fields. CONFIRMED (live-tested both regions): created experiments default deliveryMethod to "feature" (visible via get_experiment/list_experiments) — real "web"-delivery experiments only come from Amplitude's visual editor and behave differently on update_experiment/create_experiment_deployment (see those tools). Set rolloutPercentage afterward via update_experiment. Complex nested fields (variants, rollout_weights, target_segments) are JSON-encoded strings, not native objects — parsed before sending. `parent_dependencies` looks settable by shape but is CONFIRMED (live-tested) rejected outright with 400 "parentDependencies is not allowed" — don't send it, it's read-only/derived. CONFIRMED (live-tested both regions): `variants`, `rollout_weights`, `target_segments`, `deployments` (a real deployment ID), `bucketing_key`, and `evaluation_mode` all work correctly together in one call with the default `a-b-test` experiment_type. `experiment_type: "multi-arm-bandit"` instead is gated by a third, distinct permission scope — 403 "User does not have permission (experiment_multi_armed_bandit)" — separate from `experimentation` and `experiment_groups`. Response: 200 {id, url}. Rate limit: 100 req/s, 100,000/day, shared across the whole API.

Parameters

Name

Type

Required

Description

key

string

Required

Unique experiment key (slug-like identifier) used to reference this experiment.

project_id

string

Required

The Amplitude project ID this experiment belongs to.

bucketing_key

string

Optional

User property Amplitude uses to consistently bucket the same user into the same variant (e.g. amplitude_id, user_id, device_id, or a custom property).

deployments

array

Optional

Deployment IDs to attach this experiment to at creation time.

description

string

Optional

Human-readable experiment description.

evaluation_mode

string

Optional

Where variant assignment is evaluated: remote (Amplitude's servers) or local (in your SDK).

experiment_type

string

Optional

The experiment's statistical design. No confirmed documented default — Amplitude's own create example uses a-b-test.

name

string

Optional

Human-readable experiment name. Amplitude's docs disagree on whether this is required; this tool treats it as optional but you should supply it.

parent_dependencies

string

Optional

JSON-encoded object describing parent dependency relationships (e.g. mutex group or holdout membership) — observed on live experiment objects via list_experiments but NOT documented anywhere in Amplitude's Create or Update Experiment request schemas. Exposed here defensively for advanced use; Amplitude may ignore or reject this field since it looks read-only/derived rather than settable. Verify behavior with a real call before relying on it.

rollout_weights

string

Optional

JSON-encoded object mapping each variant key to its relative distribution weight, e.g. '{"control": 1, "treatment": 1}' for an equal 50/50 split. Keys must match the variants[].key values above. Pass as a JSON-encoded STRING, not a native object.

target_segments

string

Optional

JSON-encoded array of target segment objects that define who is included in this experiment and at what percentage, evaluated in order. Documented shape per segment: {"name": string (required), "conditions": [{"type": "property" (fixed value), "prop": string, "op": one of is|is not|contains|does not contain|less|less or equal|greater|greater or equal|set is|set is not|set contains|set does not contain|glob match|glob does not match, "values": string[]}] (required), "percentage": number (required), "rolloutWeights": object (required, same shape as rollout_weights above)}. Cohort-based targeting is not supported. Pass as a JSON-encoded STRING, not a native array.

variants

string

Optional

JSON-encoded array of variant objects to bucket users into. Amplitude's documented shape per variant: {"key": string (required), "payload": any JSON (optional), "name": string (optional), "description": string (optional)}. A live-tested list_experiments call against this org showed a richer real-world payload shape for feature-flag-backed experiments — "payload": [{"data": {"mutations": [...]}, "action": "mutate"}] instead of a bare value — use whichever shape matches your use case. Pass as a JSON-encoded STRING, not a native array; this tool parses it before sending. Omit to use Amplitude's own default variant set (unconfirmed what that default is).

amplitudeexperimentmanagement_create_experiment_variant

Create experiment variant

Add a new variant to an experiment. CONFIRMED from Amplitude's official docs (verified against the page's raw rendered source, not just its visible text): POST /api/1/experiments/{id}/variants with body {key, name, description, payload, rolloutWeight} — key is the only required field and can only contain letters, numbers, underscores (_), and hyphens (-). payload is passed here as a JSON-encoded string (any valid JSON element — object, array, or primitive); Amplitude's own docs example shows a bare object, but this org's live-tested data shows a real experiment variant payload shaped like [{"data":{"mutations":[]},"action":"mutate"}] — an array of mutation objects — so don't assume payload is always a plain object. rolloutWeight has no documented numeric range or scale in Amplitude's docs (unclear if it's 0-100, a relative share among variants, or something else) — match the scale your experiment's other variants already use. A successful call returns 200 OK with the literal text "OK", not a JSON body, so this tool does not attempt to parse the response as JSON. Rate limit: 100 requests/second and 100,000/day, shared across the whole Experiment Management API (not per-endpoint). CONFIRMED (live-tested, reproduced 4x): this specific operation returns HTTP 403 "User does not have permission (experimentation)" for this connected account, even though list_experiments (no ID) and create_experiment both work fine with the same credentials. This looks like a role/permission scope on the Amplitude user tied to this Management API key, not an org-wide entitlement gate (contrast with the Profile API's different "org does not have access" 401) — check the Amplitude user's Experiment role/permissions if you hit this.

Parameters

Name

Type

Required

Description

string

Required

The experiment's ID.

key

string

Required

The variant key. Can only contain letters, numbers, underscores (_), and hyphens (-).

description

string

Optional

Description for the variant.

name

string

Optional

Display name for the variant.

payload

string

Optional

Optional payload for the variant, as a JSON-encoded string. Must be a valid JSON element (object, array, or primitive). A real variant payload confirmed live on this org looked like [{"data":{"mutations":[]},"action":"mutate"}] — an array of mutation objects — rather than a bare object, so don't assume the shape without checking your own flag/experiment configuration.

rollout_weight

number

Optional

Rollout weight for non-targeted users. Amplitude's docs don't document a numeric range or scale for this value.

amplitudeexperimentmanagement_create_flag_deployment

Create flag deployment

amplitudeexperimentmanagement_create_holdout_group

Create holdout group

Create a new holdout group. Required: projectId, name, holdoutPercentage. `individualInclusion`/`individualExclusion` are named from the holdout's own point of view — inclusion in the holdout means exclusion from experiments, and vice versa. FIXED (confirmed live both regions): this field was previously sent as a raw string instead of a parsed array via body_json_mapping — now uses jsonnet_template + std.parseJson(). CONFIRMED (live-tested both regions): returns 403 "User does not have permission (experiment_groups)" — a distinct scope from `experimentation`; list_holdout_groups works fine with the same credentials, only creating is gated. `key`, `description`, `evaluation_mode`, `bucketing_key`, `individual_inclusion`, `individual_exclusion` all reach this same block regardless. `experiments`, if provided, needs at least 1 entry — an empty array fails validation, mirroring the mutex-slot minimum. Response: 200 {id, url}. Rate limit: 100 req/s, 100,000/day, shared across the whole API.

Parameters

Name

Type

Required

Description

holdout_percentage

integer

Required

Percentage of users to exclude from associated experiments, integer 1-99 inclusive.

name

string

Required

Display name for the holdout group.

project_id

string

Required

The ID of the Amplitude project to create the holdout group in.

bucketing_key

string

Optional

The user property to bucket users by. Amplitude's docs state this defaults to `amplitude_id` when omitted.

description

string

Optional

Description of the holdout group's purpose.

evaluation_mode

string

Optional

Evaluation mode for the holdout group: `remote` (evaluated server-side per request) or `local` (evaluated client-side from a downloaded ruleset). Amplitude's docs state this defaults to `remote` when omitted.

experiments

string

Optional

JSON-encoded array of experiment IDs (numbers) to associate with this holdout at creation time, e.g. [21197].

individual_exclusion

string

Optional

JSON-encoded array of user or device ID strings to always exempt from this holdout — these individuals remain eligible for associated experiments even if randomly selected into the holdout percentage. Maps to Amplitude's individualExclusion field.

individual_inclusion

string

Optional

JSON-encoded array of user or device ID strings to always place in this holdout — these individuals are permanently excluded from every associated experiment, regardless of random assignment. Maps to Amplitude's individualInclusion field.

key

string

Optional

Unique key for the holdout group. Amplitude auto-generates one if omitted.

amplitudeexperimentmanagement_delete_experiment_deployment

Delete experiment deployment

amplitudeexperimentmanagement_delete_flag_deployment

Delete flag deployment

amplitudeexperimentmanagement_get_experiment

Get experiment

amplitudeexperimentmanagement_get_experiment_variant_cohorts

Get experiment variant cohorts

amplitudeexperimentmanagement_get_experiment_version

Get experiment version

amplitudeexperimentmanagement_get_flag_variant

Get flag variant

amplitudeexperimentmanagement_get_flag_variant_users

Get flag variant users

amplitudeexperimentmanagement_get_holdout_group

Get holdout group

amplitudeexperimentmanagement_list_all_versions

List all versions

List version history across ALL flags and experiments the API key can access, in one global, paginated feed — distinct from amplitudeexperimentmanagement_list_flag_versions and amplitudeexperimentmanagement_list_experiment_versions, which return the version history for one specific flag or experiment and do NOT support start/end/limit/cursor pagination. This global endpoint DOES support all four. CONFIRMED from Amplitude's docs: versions are ordered by creation time, descending, and the response follows {"nextCursor": number, "versions": [{"createdAt": ISO 8601 string, "createdBy": userId number, "version": number, "flagConfig": {...full flag config snapshot...}}]}. UNCONFIRMED: Amplitude's docs only show flagConfig in the example, despite this endpoint's description explicitly covering both flags and experiments — whether experiment-type version entries carry an analogous experimentConfig key (or something else) instead of flagConfig is NOT confirmed by the docs and has not been independently verified. No default value for limit is documented, and no maximum time range for start/end is documented. This org has confirmed Feature Experimentation entitlement (verified via live-tested List Flags and List Experiments calls). Rate limit: 100 requests/second and 100,000/day, shared across the whole Experiment Management API (not per-endpoint). CONFIRMED (live-tested on EU, resolves a previously-open question): experiment-type version entries use the exact same "flagConfig" key as flag-type entries — there is no separate "experimentConfig" key. Distinguish the two only by the snapshot's own shape (e.g. presence of variants[].payload mutation objects) or by cross-referencing the id against list_experiments.

Parameters

Name

Type

Required

Description

cursor

string

Optional

Opaque pagination token from a previous response's nextCursor field. Don't construct this value yourself — pass back exactly what a prior call returned.

end

string

Optional

ISO 8601 formatted end time of versions to return (exclusive). Not explicitly marked required/optional by Amplitude's docs; treated as optional for consistency with limit/cursor on this same endpoint.

limit

integer

Optional

Maximum number of versions to return, capped at 1000. No documented default — omit to use Amplitude's own default page size.

start

string

Optional

ISO 8601 formatted start time of versions to return (inclusive). Not explicitly marked required/optional by Amplitude's docs; treated as optional for consistency with limit/cursor on this same endpoint.

amplitudeexperimentmanagement_list_deployments

List deployments

amplitudeexperimentmanagement_list_experiment_variants

List experiment variants

amplitudeexperimentmanagement_list_experiments

List experiments

amplitudeexperimentmanagement_list_flag_deployments

List flag deployments

amplitudeexperimentmanagement_list_flag_versions

List flag versions

amplitudeexperimentmanagement_list_holdout_groups

List holdout groups

amplitudeexperimentmanagement_remove_all_experiment_variant_users

Remove all experiment variant users

amplitudeexperimentmanagement_remove_experiment_variant_user

Remove experiment variant user

amplitudeexperimentmanagement_update_deployment

Update deployment

amplitudeexperimentmanagement_update_experiment_variant

Update experiment variant

Edit an existing experiment variant — rename its key, or update name, description, payload, or rolloutWeight. All body fields are optional; omit a field to leave its current value unchanged. CONFIRMED FROM RAW PAGE SOURCE (not just visible rendered text): this endpoint is PATCH, not POST — verified directly in Amplitude's rendered doc source, where both the section heading's one-line method summary and the full curl example agree: 'PATCH .../experiments//variants/'. Note that the equivalent Flags API doc page has a genuine docs bug for this same operation: its one-line method summary says POST, but the curl example directly beneath it uses PATCH — if you've seen POST associated with 'edit variant' elsewhere, that's this docs inconsistency, not a different real endpoint; the detailed curl example is the reliable source in both places, and it says PATCH on both the Flags and Experiments pages. payload REPLACES the entire existing payload (it is not merged); pass it as a JSON-encoded string, e.g. the shape confirmed live on this org: [{"data":{"mutations":[]},"action":"mutate"}]. rolloutWeight has no documented numeric range in Amplitude's docs. A successful call returns 200 OK with the literal text "OK", not a JSON body. Rate limit: 100 requests/second and 100,000/day, shared across the whole Experiment Management API (not per-endpoint).

Parameters

Name

Type

Required

Description

string

Required

The experiment's ID.

variant_key

string

Required

The variant's key.

description

string

Optional

Description for the variant.

key

string

Optional

New variant key, if you want to rename this variant. Can only contain letters, numbers, underscores (_), and hyphens (-).

name

string

Optional

Display name for the variant.

payload

string

Optional

Payload for the variant, as a JSON-encoded string. Must be a valid JSON element (object, array, or primitive). This value REPLACES the existing payload entirely — it is not merged. A real variant payload confirmed live on this org looked like [{"data":{"mutations":[]},"action":"mutate"}].

rollout_weight

number

Optional

Rollout weight for non-targeted users. Amplitude's docs don't document a numeric range or scale for this value.

amplitudeexperimentmanagement_update_flag_variant

Update flag variant

Edit an existing flag variant — partial update; a provided `payload` fully replaces the existing one rather than merging. Amplitude's docs are self-contradictory on the HTTP method: the endpoint heading says POST, but the runnable curl example uses PATCH against the same URL. This tool uses PATCH, matching the example and standard partial-update semantics — flip to POST if you see 404/405. A successful call returns 200 OK with the literal text "OK", not JSON. FIXED (confirmed live both regions): this field was previously sent as a raw string instead of a parsed array via body_json_mapping — now uses jsonnet_template + std.parseJson(). CONFIRMED (live-tested both regions): renaming `key` does NOT also rename `name` if `name` was never set explicitly (it had defaulted to mirror the old `key`) — set both explicitly to keep them in sync. Rate limit: 100 req/s, 100,000/day, shared across the whole API.

Parameters

Name

Type

Required

Description

string

Required

The flag's ID (not its key) — find it in the URL of the flag's page in the Amplitude app.

variant_key

string

Required

The key of the existing variant to edit.

description

string

Optional

New description for the variant, shown in the Amplitude UI. Omit to keep the current description.

key

string

Optional

New key to rename this variant to. Can only contain letters, numbers, underscores (_), and hyphens (-). Omit to keep the variant's current key.

name

string

Optional

New display name for the variant, shown in the Amplitude UI. Omit to keep the current name.

payload

string

Optional

New variant payload as a JSON-encoded string. Amplitude accepts any valid JSON element here — an object, a quoted string, or a number. This value REPLACES the existing payload entirely rather than merging with it; omit to keep the current payload. See the tool description for a note on richer payload shapes observed elsewhere in this API.

rollout_weight

number

Optional

New rollout weight for users who aren't individually targeted by this variant. No documented range; Amplitude's own example uses 0. Omit to keep the current weight.

amplitudeexperimentmanagement_update_mutex_group

Update mutex group

For more tools, view docs.

Build your Agent

Drop the toolkit in, point it at the tenant, and your agent can audit flags and roll variants from the first run.

import { ScalekitClient } from "@scalekit-sdk/node";
import { DynamicStructuredTool } from "@langchain/core/tools";
import { createReactAgent } from "@langchain/langgraph/prebuilt";
import { z } from "zod";

const sk = new ScalekitClient(envUrl, clientId, clientSecret);

const { tools } = await sk.tools.listScopedTools("user_123", {
  filter: { connectionNames: ["amplitudeexperimentmanagement"], toolNames: ["amplitudeexperimentmanagement_list_flags", "amplitudeexperimentmanagement_get_experiment", "amplitudeexperimentmanagement_update_flag"] },
  pageSize: 100,
});

const lcTools = tools.map((t) => new DynamicStructuredTool({
  name: t.tool.definition.name,
  description: t.tool.definition.description,
  schema: z.object({}).passthrough(),
  func: async (args) => {
    const { data } = await sk.tools.executeTool({
      toolName: t.tool.definition.name,
      identifier: "user_123",
      params: args,
    });
    return JSON.stringify(data);
  },
}));

const agent = createReactAgent({ llm, tools: lcTools });

import { ScalekitClient } from "@scalekit-sdk/node";
import OpenAI from "openai";

const sk = new ScalekitClient(envUrl, clientId, clientSecret);
const openai = new OpenAI();

const { tools } = await sk.tools.listScopedTools("user_123", {
  filter: { connectionNames: ["amplitudeexperimentmanagement"], toolNames: ["amplitudeexperimentmanagement_list_flags", "amplitudeexperimentmanagement_get_experiment", "amplitudeexperimentmanagement_update_flag"] },
  pageSize: 100,
});

const llmTools = tools.map((t) => ({
  type: "function",
  function: {
    name: t.tool.definition.name,
    description: t.tool.definition.description,
    parameters: t.tool.definition.input_schema,
  },
}));

const resp = await openai.responses.create({
  model: "gpt-4o", input: prompt, tools: llmTools,
});

import { ScalekitClient } from "@scalekit-sdk/node";
import Anthropic from "@anthropic-ai/sdk";

const sk = new ScalekitClient(envUrl, clientId, clientSecret);
const anthropic = new Anthropic();

const { tools } = await sk.tools.listScopedTools("user_123", {
  filter: { connectionNames: ["amplitudeexperimentmanagement"], toolNames: ["amplitudeexperimentmanagement_list_flags", "amplitudeexperimentmanagement_get_experiment", "amplitudeexperimentmanagement_update_flag"] },
  pageSize: 100,
});

const llmTools = tools.map((t) => ({
  name: t.tool.definition.name,
  description: t.tool.definition.description,
  input_schema: t.tool.definition.input_schema,
}));

const msg = await anthropic.messages.create({
  model: "claude-sonnet-4-6", max_tokens: 1024,
  tools: llmTools,
  messages: [{ role: "user", content: prompt }],
});

import { Agent } from "@google/adk/agents";
import {
  MCPToolset, StreamableHTTPConnectionParams,
} from "@google/adk/tools/mcp";

const toolset = new MCPToolset({
  connectionParams: new StreamableHTTPConnectionParams({
    url: "https://mcp.scalekit.com/amplitudeexperimentmanagement",
    headers: { Authorization: `Bearer ${userScopedToken}` },
  }),
});

const agent = new Agent({
  name: "agent", model: "gemini-2.0-flash",
  tools: await toolset.getTools(),
});

Try these prompts

Paste any prompt into your agent to start managing Amplitude experiments from your workflows.

Flag hygiene

Copy the prompt

Copied

List flags that have been at 100% rollout for more than 30 days.

Copy the prompt

Copied

Which flags have no owner or description set?

Copy the prompt

Copied

Show every flag active in the production deployment.

Experiment operations

Copy the prompt

Copied

Which experiments are running past their planned end date?

Copy the prompt

Copied

Add cohort [cohort_id] to the treatment variant of [experiment_key].

Copy the prompt

Copied

Roll [flag_key] to 25% and confirm the new allocation.

Targeting

Copy the prompt

Copied

List users individually targeted into variants on [flag_key].

Copy the prompt

Copied

Show mutex groups and which experiments share each one.

Copy the prompt

Copied

Remove the holdout on [experiment_key] and report the new state.

SEE HOW AUTH WORKS

Your users connect once. Their Amplitude Experiment Management credentials stay vaulted, every call is scope-checked, and every action is logged.

Authorize

Your user connects

Amplitude Experiment Management

once. We tie it to their identity and the meetings they approved — no shared bot account, no org-wide access

Who:

user ‘A’

when:

Once per user

access:

Limited to user

Store

Their

Amplitude Experiment Management

token lives in a vault scoped to them. User A's meetings are never reachable by an agent acting for user B, even on the same connection

vault:

encrypted

scope:

per-user

tokens:

auto-refreshed

Resolve

When your agent calls a

Amplitude Experiment Management

tool, we fetch the right token server-side. It never touches your agent, never appears in the LLM context, never shows up in your logs

speed:

~40ms

check:

before every call

seen by:

nobody

Audit

Every

Amplitude Experiment Management

tool call is logged — who triggered it, which meeting was fetched, what came back. 90 days of history, tied to the user who authorized it

history:

90 days

export:

SIEM-ready

logged:

every call

Test other agents

See the same per-user auth pattern across other connectors.

GTM and RevOps Teams

Revenue forecast commentary

Pulls open pipeline from Salesforce and HubSpot, calculates coverage against quota, flags at-risk stages, posts commentary to Slack, and logs every snapshot to Google Sheets.

GTM and RevOps Teams

Deal intelligence agent

Pulls recent Gong calls, scores deal risk with an LLM, cross-references the record in Attio, and DMs each owner their at-risk deals in Slack. Every read is scoped to that rep's own access.

Engineering Teams

Engineering standup agent

Pulls commits from GitHub and GitLab, tracks issue movement in Jira, and posts a per-engineer standup brief to Slack. Each engineer's activity is read on their own delegated OAuth.

GTM and RevOps Teams

Competitive intelligence briefing agent

Scans Gong calls for competitor mentions, matches each one to its Notion battlecard, and DMs every affected rep a single Slack digest per cycle. Every call runs as the PMM who owns the briefing, never a shared bot.

Why Scalekit

Secure your agent's access. Connectors ship in minutes

01.

Shared tokens break per-user analytics

A shared token looks fine in a demo. In production every call looks like a service account. Scalekit resolves the real user credential so attribution, audit, and scope stay accurate.

// shared token
audit → bot_service_account
user_filter → broken

// scalekit
audit → user_abc
scope → enforced ✓

02.

Authentication is not authorization

03.

Multi-tenancy is architectural

04.

Amplitude Experiment Management today. Others tomorrow.

“Our agents act across Salesforce, Gong, Google Drive, and more, on behalf of every customer. Scalekit behind the scenes meant we can keep adding tools without ever rebuilding how credentials or tool calling work.”

Venu Madhav Kattagoni

Head of Engineering / Von

FAQs

Frequently Asked Questions

Does the agent access Amplitude Experiment Management as the user or as a shared key?

As the user. Each workspace member authorizes once and Scalekit resolves their credential at request time. Audit logs attribute every action to that user, not a shared service account.

Where is the Amplitude Experiment Management bearer token stored?

In Scalekit's managed AES-256 token vault, namespaced per tenant. Refresh is automatic. Revocation is a single dashboard action. Tokens never appear in prompts, logs, or LLM context.

Can I limit what the agent is allowed to do in Amplitude Experiment Management?

Yes. Pass a tool name filter to listScopedTools so the analytics agent only sees the subset you authorize. Pre-API-call scope checks block out-of-policy actions before the request reaches Amplitude Experiment Management.

What happens when a user revokes Amplitude Experiment Management access?

The connection is invalidated on the next tool call. Subsequent requests for that user fail closed with a clear error. Other users in the tenant remain unaffected. The event is logged for audit.

Can the agent change a live rollout without review?

Only if the write tools are in scope. Flag and variant updates are separate tools from the list and get tools, so an audit agent stays read only while a release agent keeps write access. Each write is scope-checked before the Amplitude call and logged with the acting user.

On this page

Tool and actions Framework Compatibility Starter Prompt Auth Lifecycle Try Other Agents Why Scalekit