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

  1. Assist Agent calls a tool exposed by your MCP server.

  2. Your server saves a task, starts your agent in the background, and returns a task response promptly.

  3. Pylon pauses that step of the conversation and periodically calls tasks/get with the same task ID.

  4. Your server returns the task’s current status. Once the agent finishes, the response includes its output.

  5. 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:

  1. Authenticate the request and validate the tool arguments.

  2. Create and persist a task with a unique ID and working status.

  3. Enqueue or start the agent’s work independently of the HTTP request.

  4. 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

resultType

task for the initial task response.

taskId

A stable, unique ID that identifies the same work on every poll.

status

Usually working when the work starts.

createdAt

The original creation timestamp in RFC 3339 format.

lastUpdatedAt

The time the task was last updated.

ttlMs

Task retention lifetime in milliseconds from creation; use a positive value or null for no advertised expiry.

pollIntervalMs

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

  1. Open Settings → AI controls → Connectors.

  2. Choose Add MCP connector.

  3. Enter a name, description, and your HTTPS MCP server URL, such as https://mcp.example.com/mcp.

  4. 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.

  5. 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 resultType: "task" response.

“Expires too quickly to resume”

Increase task retention and verify createdAt, ttlMs, and the server clock.

“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 tasks/get a status lookup; start work only when creating the task.

Task completes but no useful answer appears

Return the final MCP tool result inside the completed task’s result field.

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.