On-Device Mobile AI Agents
Who do I contact at MultiOn to set up a production pilot (security review, proxy requirements, concurrency testing, support)?
10 min read
Most teams that are ready for a production pilot with MultiOn don’t need a generic “contact us” loop—they need a direct path to the right people who can handle security review, proxy constraints, concurrency limits, and support expectations.
Below is how to get in touch with MultiOn for a production-grade pilot, what information to include, and how to frame your requirements so you can get to a real evaluation (not a long back-and-forth).
Quick Answer:
To set up a production pilot with MultiOn, contact the team via the primary site and clearly label your request as a production pilot with details on security review, proxy / network requirements, expected concurrency, and support SLAs. For most teams, the fastest route is:
- Use the main contact path on the MultiOn site (or the “Get access / Get in touch” flow if surfaced), and
- In your message, request: “MultiOn production pilot for Agent API (V1 Beta), Retrieve, and browser agents – security + infra review.”
At-a-Glance: Who to Contact and for What
| Need | Who You’re Actually Trying to Reach | How to Reach Them | What to Include |
|---|---|---|---|
| Security review & DPA questions | Security / compliance owner + core product team | Main site contact / “Get in touch” form | Your security questionnaire, data-flow summary, regions, SSO/SCIM needs |
| Proxy & network requirements | Infra / platform engineers at MultiOn | Same contact path, flagged as “network / proxy review” | IP allowlisting needs, proxy topology, bot-protection context |
| Concurrency & scale testing | Core platform / capacity planning | Same contact path, flagged as “load & concurrency testing” | RPS targets, # of concurrent sessions, peak vs steady-state |
| Production support expectations | Customer / developer success + eng on-call | Same contact path, flagged as “production support & escalation” | Desired SLA, hours of coverage, who’s on your side (SRE / platform team) |
How to Contact MultiOn for a Production Pilot
Even though MultiOn’s public docs focus on endpoints and SDKs, a real production pilot usually starts with a structured intake so the team can map you to the right resources.
1. Use the primary “Get access / Get in touch” flow
On MultiOn’s site, use the main “Get access” / “Get in touch” entry point. In practice, that form routes you to the people who handle:
- Agent API (V1 Beta) onboarding
- Security and compliance reviews
- Infrastructure questions (secure remote sessions, native proxy support)
- High-concurrency pilot setups (“millions of concurrent AI Agents ready to run” is the target shape)
If the form asks for your intended use case, choose the closest match:
- Agentic commerce, booking and buying if you’re doing Amazon-style checkout flows
- Automation and internal tools if this is internal orchestration or operational workflows
- Developer testing / web research if you’re starting with Retrieve and structured extraction
In the free-text message field, explicitly say you’re requesting a production pilot and list the four pillars: security review, proxy requirements, concurrency testing, and support.
Sample message you can paste into the contact form
You can adapt this, but keep the structure; it makes it easier for the MultiOn team to route you:
We’d like to set up a production pilot with MultiOn focused on:
- Security review: We’ll need to run your architecture and data flows through our security review (PII handling, secure remote sessions, auditability).
- Proxy & network: We expect to run agents through our own proxies / IP ranges and may need native proxy support and guidance on bot protection.
- Concurrency testing: Target is ~[X] RPS, ~[Y] concurrent browser sessions across [environments/regions]. We’d like to run load tests against the Agent API (V1 Beta) and Retrieve.
- Support: We’ll need clarity on support channels, escalation paths, and any available SLAs for production use.
Our primary flows:
- [e.g., Amazon-style multi-step checkout via
POST https://api.multion.ai/v1/web/browsewith sessions + step mode]- [e.g., posting to X]
- [e.g., structured extraction from dynamic catalogs via Retrieve into JSON arrays of objects]
Please connect us with the appropriate team (security, infra, and developer success) to scope a production pilot.
That language signals you’re not a casual tester; you’re planning real traffic and need concrete commitments.
What the MultiOn Team Will Want to Know
If you want your pilot request to move fast, be ready with this information in your first contact.
Security review: what to send up front
Your security/compliance team is going to ask about how MultiOn’s secure remote sessions and data handling work. To get ahead of that:
Include:
- Data categories:
- Do agents see PII / PCI / health data?
- Are they logging into internal tools, or only public sites?
- Regions & residency:
- Any hard requirements on data residency or in-region processing.
- Identity & access:
- How you plan to manage access to the
X_MULTION_API_KEY - Whether you need SSO/role-based permissioning on your side
- How you plan to manage access to the
- Logs & observability:
- Whether your security team requires log retention limits, redaction, or audit trails of web actions
MultiOn’s value prop is predictable, testable primitives—Agent API, Retrieve, Sessions + Step mode. In a security review, frame them like this:
- Agent API (V1 Beta): “Intent in (
cmd+url), actions executed in a secure remote browser session, withsession_idcontinuity for multi-step flows.” - Retrieve: “Structured JSON out—JSON arrays of objects from dynamic pages—with parameters like
renderJs,scrollToBottom,maxItems.” - Sessions + Step mode: “Stateful workflows (e.g., login → add to cart → checkout) managed via a
session_idinstead of bespoke selectors.”
That lets your security team reason about it like a remote browser platform plus an extraction surface—not a black-box AGI.
Proxy requirements & bot protection: what to clarify
Most teams coming from Playwright/Selenium already know where their automation gets blocked: WAFs, bot detection, geo restrictions, and brittle IP patterns.
In your initial outreach, include:
- Current setup:
- “Today we use [Playwright/Selenium/grid] and front it with [type of proxies, regions].”
- Desired behavior with MultiOn:
- Whether you need native proxy support (your IPs / regions)
- Any sites with extra-sensitive bot protection (e.g., card processors, KYC portals)
- Network policies on your side:
- IPs you need to allowlist (if provided)
- Egress restrictions from your environment
Phrase it like:
We need to confirm how MultiOn’s secure remote sessions and native proxy support behave behind our network controls and WAF, and whether we can route traffic through our own proxy pool for specific domains.
That gives the MultiOn infra team enough context to propose a setup that won’t surprise your security folks.
Concurrency & load testing: what numbers matter
MultiOn’s platform is built for “infinite scalability with parallel agents,” but you still want explicit confirmation that your specific workload shape is supported.
Include concrete numbers:
- Concurrent sessions:
- Peak and steady-state
session_idcounts (e.g., 1,000 sessions active, with bursts to 5,000)
- Peak and steady-state
- Request rate:
- Requests per second to
POST https://api.multion.ai/v1/web/browseand any Retrieve calls
- Requests per second to
- Flow complexity:
- Average steps per session (e.g., 3 steps vs 20-step flows)
- Which flows are long-lived (e.g., Amazon checkout vs quick one-off actions)
- Environments:
- Dev, staging, and production—do you need separate API keys or rate limits?
Also mention you expect to run structured load tests and want to handle any:
- Rate limiting responses
- Payment gating / 402 Payment Required events
- Session caps or concurrency limits
Example wording:
During the pilot we’ll run controlled load tests up to ~[X] concurrent browser sessions and ~[Y] RPS across our key flows. We’d like to align on rate limits, any 402 Payment Required behavior, and how you recommend we handle backoff/retries at the Agent API layer.
Support & escalation: what to ask for
If you’re wiring MultiOn into production workflows like Amazon ordering, posting on X, or catalog extraction from sites like H&M, you don’t want “best-effort” support.
Ask directly for:
- Primary support channel:
- Email, Slack, ticketing system—what’s standard during a pilot?
- Coverage:
- Time zone coverage and weekend/on-call expectations
- Response targets:
- Informal SLA during pilot (e.g., critical outages vs minor issues)
- Pilot review cadence:
- Weekly touchpoint to review errors, session reliability, and throughput
You can phrase it as:
We’re planning to wire MultiOn into production-facing flows. For the pilot, we’d like a clear support channel and informal response expectations (especially around outages, degraded performance, or bot-protection regressions).
How to Frame Your Pilot Around MultiOn’s Surfaces
To make your request legible to the MultiOn team, anchor your pilot in their core surfaces instead of generic “agents” language.
Agent API (V1 Beta): browser-operated actions
Describe the workflows you want to run via:
POST https://api.multion.ai/v1/web/browse
X_MULTION_API_KEY: <your key>
With a payload shaped around:
cmd: Natural-language intent (e.g., “Add the cheapest size M black t-shirt to cart and proceed to checkout.”)url: Starting URL (e.g., Amazon product page, X compose screen)session_id: For Session + Step mode when you need to continue a workflow
Pilot flows that map well:
- Multi-step Amazon ordering (search → select → add to cart → checkout)
- Posting on X (login → compose → post)
- Complex login flows that used to break Playwright/Selenium scripts
Make it clear that Session + Step mode is a first-class requirement if you’re replacing brittle scripts:
Our pilot will center on Session + Step mode: we intend to keep
session_ids alive across multiple calls (login → action → confirmation) instead of re-creating browser state per request.
Retrieve: structured JSON from dynamic pages
If you’re evaluating MultiOn for data extraction from JS-heavy pages, call that out:
- You expect JSON arrays of objects as the output
- You plan to use controls like
renderJs,scrollToBottom, andmaxItemsto handle lazy loading - Example use case: extracting H&M catalog pages into structured fields like
name,price,colors,images,urls
This signals that you’re not treating MultiOn as a brittle scraper; you’re using the Retrieve surface as intended—structured outputs from real rendered pages.
Decision Triggers: When You’re Ready to Involve MultiOn’s Team
You’re ready to contact MultiOn for a production pilot when:
- You’ve identified at least one end-to-end flow you want to move from Playwright/Selenium to Agent API (V1 Beta) and Sessions
- You can estimate concurrency and RPS (even roughly)
- Your security team is prepared to review a new vendor that provides secure remote sessions and native proxy support
- You have an owner on your side (platform / SRE / automation) for the pilot
Put differently: if you’re still at “let’s see what agents can do,” you can stay in self-service mode. Once you’re at “we want to wire MultiOn into checkout, posting, or internal operations,” you should go through the pilot route described here.
Final Verdict
For a production pilot that covers security review, proxy and network constraints, concurrency testing, and support, your best path is to:
- Use the main “Get access / Get in touch” entry on MultiOn’s site
- Label the request explicitly as a “MultiOn production pilot”
- Include concrete details on:
- Security & data handling requirements
- Proxy / bot-protection environment
- Concurrency and expected load
- Support, escalation, and pilot success criteria
That gets your request routed to the right combination of product, security, and infra owners who can evaluate serious, production-scale usage of the Agent API (V1 Beta), Retrieve, and browser agents.