2pm.spaceConnect it to
everything you already run
Messaging channels, HTTP APIs, databases, MCP servers and sandboxed code — described rather than coded, so an agent can reach the system that holds the answer instead of apologising for not knowing.
Six ways to reach the rest of your stack
Whatever the system is, one of these already covers it.
Any API, described not coded
Give a tool a URL, a method, an auth header and a JSON Schema for its parameters, then grant it to the agents that should call it. Nothing to deploy beyond the endpoint you already have.
Code when describing is harder
Python in a sandbox, callable as a tool: the arguments arrive in ARGS and the result is whatever it prints. For the reshaping, parsing and arithmetic that is faster to write than to explain to a model.
MCP, both directions
Point a tool at any MCP server, discover its tools with one click and switch each on, off or behind approval — and drive this workspace from an external MCP client, including a coding agent building your agents for you.
Agents as tools
Expose one agent to another. A supervisor delegates to a specialist and gets a structured answer back, instead of a second copy of the specialist inside its own prompt.
Channels as integrations
Messenger, Personal Zalo, Telegram, Pancake and a website widget connect as first-class channels. Anything else arrives through the Custom API channel — a webhook in, a webhook out.
See the AI inboxEvents pushed to you
Inbox events reach endpoints you own, so a new message can trigger something in your stack. Delivery is logged, so a receiver that was down is visible rather than lost.
The catalogue
What connects today, by kind.
Messaging channels
- Facebook Messenger, and comments with private reply
- Personal Zalo, with Zalo Official Account coming soon
- Telegram bots
- Pancake accounts
- Website chat widget
- Custom API — webhook in, webhook out
Tool types
- Built-in tools, including Viettel Post, KiotViet and WordPress
- Webhook tools — any HTTP API, with bearer or key auth
- Sandboxed Python functions, offline unless you allow internet
- Human approval and result caching, per tool
- MCP servers — discover their tools, switch each one on or off
- Agent-as-tool delegation
Data connections
- PostgreSQL and MySQL
- Redshift and ClickHouse
- Snowflake and BigQuery
- Tables picked on connect — the model reads only those
Publishing and services
- Facebook Pages and WordPress publishing
- Custom webhook destinations
- Connected app accounts for third-party services
- Viettel Post shipping, with cash on delivery
Programmatic access
- Workspace API keys, scoped to their creator’s permissions
- An MCP endpoint authenticated by the same key
- Outbound webhooks on inbox events
- Per-call logging with cost
Ready to install
- A marketplace of agent templates
- Templates cloned into your workspace, then edited
- Skills and tools shared across every agent
- Apps built on the platform and installed into a workspace
What stops being an engineering project
The integrations you would otherwise have written and maintained.
A connector request in someone’s backlog, waiting on a vendor to build it
Describe the endpoint yourself and the agent can call it the same afternoon
Glue code deployed and maintained for every internal service an agent touches
Webhook tools, plus sandboxed Python for the parts that need it
An agent that can only talk, because nothing it needs is reachable from it
Channels, APIs, databases and MCP servers all callable from the same loop
Copying a specialist agent’s prompt into every other agent that needs it
One agent exposed as a tool the others delegate to
A token pasted into a shared config so a script can reach the platform
Workspace API keys scoped to their creator’s permissions, revocable one by one
Integration questions
What engineers ask before wiring this into an internal system.
With a webhook tool. You give it the URL, the method, the auth header and a JSON Schema for its parameters, then grant it to the agents that should use it — or make it Global for all of them. No code deployed on our side, and none on yours beyond the endpoint you already have.
Yes — Python, in a sandbox, as a tool an agent can call. It is the right answer for the transformations that are easier to write than to describe: reshaping a payload, doing arithmetic a model should not be trusted with, parsing something awkward. Internet access stays off unless you switch it on.
In both directions. An MCP tool points at any server: discover its tools with one click, then choose which ones agents may use and which need approval. And the platform exposes its own MCP server so an external client — including a coding agent — can drive your workspace: create agents, edit documents, query boards, manage skills and tools.
Yes. An agent can be exposed as a tool, so a supervisor can delegate to a specialist and get a structured answer back rather than reimplementing what the specialist already does.
Inbox events can be pushed to endpoints you own, so a new message or a resolved conversation can trigger something in your own stack. Delivery is logged, so a receiver that was down is visible rather than a message you never knew about.
Yes. API keys are issued per workspace and carry the permissions of the member who created them, so a key cannot do more than the person behind it. The same key authenticates the MCP endpoint.
Wire it into the system that has the answer
Describe an endpoint, connect a database, or point it at an MCP server. Free to start, no credit card.