Building a Telex Agent That Summarizes PDFs with FastAPI

🧠 Building a Telex Agent That Summarizes PDFs with FastAPI

Telex recently opened up its workflow agents, small independent services that can take messages, perform actions, and respond in real time. I decided to build one from scratch using FastAPI, and it turned into one of the most interesting debugging sessions I've had in a while.

This post walks through how I built a Telex A2A (Agent-to-Agent) Summarizer, which takes a PDF file URL, extracts the text, and sends back a concise summary all over a JSON-RPC endpoint.

⚙️ What I Built

The goal was simple:


Whenever a message containing a PDF link hits my agent, it should automatically:

1. Extract the text from the PDF.


2. Summarize the content.


3. Return the summarized text back to Telex as a response.

The agent listens for Telex JSON-RPC events on the endpoint:

POST /a2a/summarize

and expects a payload like this:

{

  "jsonrpc": "2.0",

  "id": "123",

  "method": "summarize/pdf",

  "params": {

    "message": {

      "kind": "message",

      "role": "user",

      "parts": [

        { "kind": "text", "text": "Check out this PDF: https://media.telex.im/sample.pdf" }

      ]

    }

  }

}

Once the request arrives, my FastAPI app:

• Detects the PDF URL in the message text.


• Extracts the PDF content using a text extraction service.


• Summarizes it using a custom summarizer.


• Sends the summarized text back to Telex in a properly structured JSON-RPC response.

🧩 Architecture Overview

Here's the basic flow:

Telex → FastAPI Agent → PDF Extractor → Summarizer → Telex Response

Each message that hits the /a2a/summarize route is parsed into a RPCRequest model.

After validation, the agent uses extract_text() to pull text from the file URL, then calls summarize_text() to generate a concise summary.

Finally, it constructs a RPCResponse containing:

• The summarized message.


• Metadata like taskId, messageId, and artifactId.


• A clear "completed" task state.

This response is sent back to Telex to be displayed in the workflow logs or UI.

🧠 The Debugging Story

When I first deployed it, Telex didn't show any response even though my server logs said "Response sent successfully."

After digging into the issue, I realized my agent was simply too slow.

Telex's default timeout was 15 seconds, while my PDF extraction and summarization could take longer depending on file size.

After some collaboration with the Telex devs, the timeout was increased to 60 seconds, and instantly my agent came to life. The summarized response started showing up in the Telex logs.

It was a satisfying moment watching that JSON come full circle.

🛠️ Tech Stack

• 
  FastAPI for building the JSON-RPC server.


• 
  Python core language for parsing, processing, and responding.


• 
  Regex for detecting Telex media URLs in message parts.


• 
  PDF Extractor Service handles text extraction.


• 
  Summarizer Service compresses extracted text into meaningful summaries.


• 
  UUIDs to track messages and tasks uniquely.

🔮 Next Steps

Now that the summarizer agent is working, I'm planning to:

• Add support for multi-file summarization.


• Cache results to improve speed.


• Expose summary statistics (like reading time and keyword extraction).

Ultimately, I want to make it easier for Telex agents to process large files seamlessly within workflow automations.

🚀 Final Thoughts

Building this Telex agent taught me how well-designed the platform's A2A architecture is. It's simple but powerful just JSON-RPC, HTTP, and well-defined structure.

If you're thinking of building your own Telex agent, start small. Handle one message type, log everything, and iterate. Once your responses show up in the Telex logs, you'll realize how rewarding that little green "success" status can be.