Connect your own AI agent to Pylon
Last updated: November 6, 2026
Bring your own AI agent into your support workflow: Pylon’s Assist Agent can hand off investigations to your agent and use its findings to help your team resolve customer issues.
Connect an agent you already run to Pylon through a custom MCP server. Your server starts the work and returns a task ID. Pylon checks the task’s status, retrieves the completed result, and continues the Assist Agent conversation.
This is useful for investigations, knowledge searches, or other operations that take longer than a normal tool call.
How it works
Assist Agent calls a tool exposed by your MCP server.
Your server saves a task, starts your agent in the background, and returns a task response promptly.
Pylon pauses that step of the conversation and periodically calls
tasks/getwith the same task ID.Your server returns the task’s current status. Once the agent finishes, the response includes its output.
Pylon resumes the conversation with that output.
Your team owns: the MCP server, authentication, agent execution, task storage, status updates, results, and cancellation handling.
Pylon handles: calling your tool, tracking the returned task, polling, and resuming the conversation.
You do not need a callback into Pylon or a separate polling script. Your MCP server may need to poll your agent’s own API internally if that API uses its own job IDs.
1. Expose your agent as an MCP tool
Create a tool with a clear description and input schema. For example, an debug_issue tool could take an issue ID, an account ID, and a question.
Configure the workflow to provide the context your tool needs. Your server should validate inputs and enforce account access using the authenticated identity.
The MCP server can wrap an existing agent. You do not need to rebuild the agent inside Pylon.
2. Advertise MCP Tasks support
Include the Tasks extension in your server’s discovery capabilities:
{
"capabilities": {
"extensions": {
"io.modelcontextprotocol/tasks": {}
}
}
}Add the following Tasks capability to your MCP server’s existing capabilities. Keep the rest of your server’s discovery response unchanged.
Pylon includes a signal in its request when it can check back for a result. Your server should only return a task ID when that signal is present, as shown below.
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "investigate_issue",
"arguments": {
"issue_id": "issue-456",
"account_id": "account-789",
"question": "Why is this customer's data sync failing?"
},
"_meta": {
"io.modelcontextprotocol/clientCapabilities": {
"extensions": {
"io.modelcontextprotocol/tasks": {}
}
}
}
}
}Implement the compatible Tasks extension, not just a custom status tool. Returning a job ID as ordinary text, an HTTP 202 response, or a custom check_status tool does not activate Pylon’s automatic task polling.
See the MCP Tasks overview and versioned Tasks schema for the protocol definitions.
3. Start the work and return a task
When your server receives the tool call:
Authenticate the request and validate the tool arguments.
Create and persist a task with a unique ID and
workingstatus.Enqueue or start the agent’s work independently of the HTTP request.
Return the task response promptly.
Example response to the tool call:
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"resultType": "task",
"taskId": "investigation-123",
"status": "working",
"createdAt": "2026-11-05T18:00:00Z",
"lastUpdatedAt": "2026-11-05T18:00:00Z",
"ttlMs": 1800000,
"pollIntervalMs": 5000
}
}Use real timestamps at runtime. The dates and IDs throughout this article are illustrative.
Field | What your server should return |
|---|---|
|
|
| A stable, unique ID that identifies the same work on every poll. |
| Usually |
| The original creation timestamp in RFC 3339 format. |
| The time the task was last updated. |
| Task retention lifetime in milliseconds from creation; use a positive value or |
| Suggested interval between status checks, in milliseconds. |
Save tasks and results somewhere that survives individual requests and worker restarts. A polling request may arrive through a new connection or a different server instance.
Return the handle quickly. Tasks extend the duration of the work, not the time available to return the initial response. Do not wait for the full investigation before sending the task ID.
4. Return status and results through tasks/get
Pylon polls the same MCP endpoint using the task ID:
{
"jsonrpc": "2.0",
"id": 2,
"method": "tasks/get",
"params": {
"taskId": "investigation-123",
"_meta": {
"io.modelcontextprotocol/clientCapabilities": {
"extensions": {
"io.modelcontextprotocol/tasks": {}
}
}
}
}
}While your agent is working, return the saved task metadata:
{
"jsonrpc": "2.0",
"id": 2,
"result": {
"resultType": "complete",
"taskId": "investigation-123",
"status": "working",
"createdAt": "2026-11-05T18:00:00Z",
"lastUpdatedAt": "2026-11-05T18:01:00Z",
"ttlMs": 1800000,
"pollIntervalMs": 5000,
"statusMessage": "Checking the customer's sync logs."
}
}Here, resultType: "complete" means the status request has returned its response. The task is still running because its status is working.
When the agent finishes, persist the output and return it inside the task’s result field:
{
"jsonrpc": "2.0",
"id": 3,
"result": {
"resultType": "complete",
"taskId": "investigation-123",
"status": "completed",
"createdAt": "2026-11-05T18:00:00Z",
"lastUpdatedAt": "2026-11-05T18:02:00Z",
"ttlMs": 1800000,
"pollIntervalMs": 5000,
"result": {
"resultType": "complete",
"content": [
{
"type": "text",
"text": "The sync failed because the source credential expired. Reconnect the source and retry the sync. Evidence: the latest connector run returned an authentication error."
}
],
"isError": false
}
}
}The nested result is the MCP tool result that Pylon passes back to Assist Agent. Include the findings and relevant evidence the agent needs to continue. Returning only status: "completed" leaves it without the investigation output.
Each poll should read the existing task; it should not start a new agent run. Keep the completed result available through its retention period.
5. Handle errors and cancellation
If the investigation fails, return task status failed with a JSON-RPC error in the task response’s error field. For example, replace the completed task’s nested result with:
{
"status": "failed",
"error": {
"code": -32603,
"message": "The investigation could not access the requested logs."
}
}This is a fragment: retain resultType: "complete", the task ID, and the other task metadata in the full response.
Also implement tasks/cancel. It receives the same taskId; acknowledge it with a result such as {"resultType":"complete"}. Stop the underlying work where possible and record cancelled when cancellation succeeds. Pylon may request cancellation when the task reaches its deadline or the waiting conversation no longer needs the result.
For this Pylon integration, design tasks to finish without additional user input midway through execution. Do not depend on input_required or tasks/update being handled by Pylon.
6. Connect the server in Pylon
Open Settings → AI controls → Connectors.
Choose Add MCP connector.
Enter a name, description, and your HTTPS MCP server URL, such as
https://mcp.example.com/mcp.Select the authentication method your server supports and complete the connection. For OAuth, provide an existing client ID and secret if your server requires them.
Make the connector and tool available to the user running Assist Agent, then select the connector in the conversation.
If you use a skill to guide the workflow, describe when to invoke the tool, what context to send, and how to use the returned findings. For example:
When asked to investigate a sync failure, use investigate_issue with the issue ID, account ID, and investigation question. Once the findings are available, summarize the cause, supporting evidence, and recommended next steps. If the tool fails, explain the failure instead of inventing findings.
Timing and limits
Behavior | Current handling |
|---|---|
Maximum wait | Up to 30 minutes, capped by the server’s remaining task TTL. |
Minimum remaining lifetime | Must exceed 30 seconds when Pylon accepts the task. |
Polling | Pylon uses the server’s interval hint with a five-second minimum between working-state polls. Scheduling may add delay; this is not an exact timing guarantee. |
Status response time | Return status promptly; Pylon bounds remote polling requests to 10 seconds. |
Task expires or reaches the deadline | Pylon attempts cancellation and returns a tool error to the conversation. |
Connection is revoked, disabled, or requires reconnection | Pylon cannot retrieve the task result and returns a connection error. |
Choose a TTL that covers the expected agent runtime plus time to retrieve the result. Do not reset createdAt or extend the advertised lifetime on each poll.
Troubleshooting
Symptom | What to check |
|---|---|
The original call still times out | The server may be waiting for the agent instead of returning a task, or the call may be using a synchronous execution path. |
Pylon never polls the task | Check workspace availability, supported session type, protocol version, extension negotiation, and the initial |
“Expires too quickly to resume” | Increase task retention and verify |
“Task not found” after the first response | Persist task state across requests, connections, and server instances. Check that the same authenticated identity can retrieve it. |
The agent runs again on every poll | Make |
Task completes but no useful answer appears | Return the final MCP tool result inside the completed task’s |
The task keeps waiting for user input | Redesign it to complete without mid-task elicitation for this integration. |
The connection is no longer available | Reconnect the MCP connector and start a new test. |