DEVELOPER PREVIEW

Your agent.
A line to the outside world.

We’re building a communications layer that connects your assistant to email, texts and voicemail—with a place for you in the conversation.

Proxling’s apricot courier checking a message on its phone
One identity.
Room for both of you.
Early access. A look at what’s ahead.

The API, MCP connection and phone services described here are planned capabilities. Public developer access is not available yet.

01 / THE ARCHITECTURE

The network delivers.
Proxling gives it context.

An SMS is a message. A task also needs a brief, a conversation, permissions and a next step. Proxling is being designed to bring those together, across channels and assistants.

Your assistant or applicationYou choose the model and runtime
Planned API & MCP access
proxling.THE COORDINATION LAYER
PermissionsWho, what and when
Task historyMessages with context
EventsReplies into next steps

You approve, pause and take over here.

EMAIL CHANNELEmail provider

Task addresses, outgoing mail and incoming replies.

PHONE CHANNELMobile carrier

The number, SMS delivery and call routing.

Your phone · optional eSIMHandset access to the same line
Intended architecture. Incoming replies return through the relevant provider to Proxling, where they can be associated with a task. Email uses its own channel.

02 / ONE LINE, TWO WAYS IN

The eSIM connects your phone.
Proxling connects the work.

The optional eSIM is the handset’s connection to the mobile network. The agent connects to Proxling in the cloud. Our aim is for both to use the same number, with the task’s context and controls held in Proxling.

01

The agent can handle the follow-up. Planned SMS tools and voicemail transcripts give it a way to collect replies without using your personal number.

02

You can pick up the conversation. With a supported eSIM, the intention is to receive and reply to texts from your phone on that same line.

03

The context stays with the task. Proxling is intended to keep the shared record of agent actions, replies and your decisions, even when you change assistants.

Lilac Proxling courier listening to a voice note

Your handset is one way in.
Your task lives in Proxling.

A few useful boundaries

Handset features depend on the carrier, device and launch market. A Proxling conversation history does not imply that agent-sent messages will appear in your phone’s native sent folder.

For a deliberate handover, the intended flow is to pause the assistant in Proxling before replying from your handset. Carrier events can arrive after a message has been sent.

The current product direction covers SMS and voicemail with transcripts. Live AI calling, iMessage, RCS and a general mobile-data plan are outside this preview.

03 / THE DEVELOPER SURFACE

Build the workflow.
Bring your own agent.

We aim to expose the same task context and permission model through an API and a hosted MCP connection. Your application decides how to reason about the task; Proxling coordinates its permitted communications.

API

For your application.

Work with tasks, conversations and message status from your own service. Planned events would let your runtime respond when something changes.

MCP

For your assistant.

Give a compatible assistant tools to read task context, propose messages and request your approval through a connected Proxling account.

What we aim to open up over time

Context

Tasks, inboxes and conversations. Read the brief, permitted contacts and relevant message history.

Action

Email and two-way SMS. Send within approved boundaries and track what happened to a message.

Signal

Replies and voicemail transcripts. Make incoming activity available to your application through events or a retrievable feed.

Control

Approval and human handover. Ask for a decision, respect a pause and keep the owner’s actions in the same history.

These describe the intended capabilities, not a published endpoint or tool-name specification. Authentication, schemas, delivery guarantees and client support will be documented as developer access opens.

04 / FROM MESSAGE TO OUTCOME

A reply should move
the work forward.

A repair enquiry is one example. The useful part is carrying the context from the first question to the final confirmation.

  1. 1
    You set the brief.

    “Find a repair slot on Thursday. Ask before booking.”

  2. 2
    Your agent makes enquiries.

    Messages go through Proxling within the permissions you approve.

  3. 3
    A reply becomes task context.

    An SMS or voicemail transcript gives the connected runtime new information.

  4. 4
    You choose. It follows through.

    The agent requests a decision, sends an approved reply and records the supplier’s confirmation.

Illustrative workflow for the planned service. A sent message and a confirmed booking are separate outcomes.
A connection needs a runtime.

MCP provides a way to expose tools and context. Whether an assistant can resume work in the background depends on its host application. We aim to support event-driven integrations for persistent runtimes; other assistants may need you to reopen the conversation.

About the Model Context Protocol

05 / CONTROL & CONTINUITY

Useful access.
A clear boundary.

You grant the scope.

Connecting an assistant should not give it unrestricted access. The intended model keeps contacts, channels and task limits under your control.

You keep the final say.

An enquiry is not permission to book or buy. Approval requests, pause and human takeover are central to the planned tool surface.

Your identity can stay.

The aim is to keep your Proxling inbox, number and task history when you switch assistants. Pausing access is separate from retiring an identity.

BUILD WITH US

A useful little layer.
A lot of possibilities.

Proxling is in early access. Join the list for launch updates and news about developer access. Supported markets, carrier features and assistant compatibility will be confirmed as they become available.

Join early access