Bagaimana AI Agent dapat membaca, mengubah, membuat, hingga menandatangani dokumen secara otomatis?

Bagaimana AI Agent dapat membaca, mengubah, membuat, hingga menandatangani dokumen secara otomatis?
Bagaimana AI Agent dapat membaca, mengubah, membuat, hingga menandatangani dokumen secara otomatis?


Sebagian besar aplikasi berbasis LLM saat ini sudah cukup baik dalam mengambil informasi dari dokumen. Dengan pendekatan seperti Retrieval-Augmented Generation (RAG), model AI dapat membaca isi PDF, mengambil teks yang relevan, kemudian menggunakannya sebagai konteks untuk menghasilkan jawaban.

Namun, ada satu masalah yang lebih kompleks: bagaimana jika AI tidak hanya perlu membaca dokumen, tetapi juga harus melakukan sesuatu terhadap dokumen tersebut?

Misalnya:

  • Mengubah file Word menjadi PDF.
  • Melakukan OCR pada dokumen hasil scan.
  • Mengambil tabel dan field formulir.
  • Menggabungkan beberapa PDF.
  • Membagi dokumen menjadi beberapa bagian.
  • Membuat kontrak berdasarkan template.
  • Memberikan password pada PDF.
  • Mengirim dokumen untuk ditandatangani secara elektronik.

Di sinilah konsep agentic document workflow menjadi menarik.

Dengan menggabungkan LLM Agent, Model Context Protocol (MCP), PDF API, dan eSign API, kita dapat membangun pipeline yang memungkinkan AI memilih dan menjalankan berbagai operasi dokumen secara otomatis.

Apa Itu Agentic Document Workflow?

Agentic document workflow adalah workflow otomatis di mana sebuah AI agent tidak hanya membaca dokumen, tetapi juga menjalankan operasi terhadap dokumen berdasarkan tujuan yang diberikan.

Dalam workflow RAG biasa, prosesnya kurang lebih seperti ini:

Dokumen → ekstraksi teks → LLM → jawaban

Sementara dalam agentic document workflow, prosesnya bisa menjadi:

Dokumen → OCR → ekstraksi data → transformasi → pembuatan dokumen → tanda tangan elektronik

Perbedaannya cukup penting.

RAG berfokus pada mengambil informasi dari dokumen, sedangkan agentic workflow memungkinkan AI memproses dan mengubah dokumen.

Sebagai contoh, bayangkan sebuah perusahaan menerima invoice dalam bentuk PDF hasil scan.

AI agent dapat melakukan beberapa langkah berikut:

  1. Menerima invoice.
  2. Menjalankan OCR.
  3. Mengambil nomor invoice, nama perusahaan, tanggal, dan total pembayaran.
  4. Mengubah hasil ekstraksi menjadi data terstruktur.
  5. Menggabungkan data tersebut ke dalam template dokumen.
  6. Menghasilkan PDF baru.
  7. Mengirim dokumen tersebut untuk ditandatangani.

Seluruh proses tersebut dapat dijalankan sebagai rangkaian tool call oleh AI agent.

MCP sebagai Jembatan antara AI dan API

Model Context Protocol (MCP) menyediakan standar untuk menghubungkan AI agent dengan berbagai tools.

Daripada membuat integrasi REST API khusus untuk setiap kebutuhan, API dapat diekspos sebagai kumpulan tool yang dapat ditemukan dan dipanggil oleh AI agent.

Secara sederhana, arsitekturnya dapat dibayangkan seperti ini:

┌─────────────────────┐
│      LLM Agent      │
│                     │
│ Memahami tugas dan  │
│ memilih tool        │
└──────────┬──────────┘
           │
           │ MCP
           ▼
┌─────────────────────┐
│    MCP Server       │
│                     │
│ PDF Tools           │
│ OCR                 │
│ Extraction          │
│ Merge / Split       │
│ Conversion          │
└──────────┬──────────┘
           │
           │ REST API
           ▼
┌─────────────────────┐
│   PDF Services API  │
└─────────────────────┘

AI agent tidak perlu mengetahui detail HTTP request yang digunakan API.

Agent cukup mengetahui bahwa tersedia sebuah tool, misalnya:

convert_word_to_pdf
ocr_document
extract_document
merge_pdf
split_pdf
compress_pdf

Kemudian model menentukan tool mana yang diperlukan berdasarkan konteks tugas.

Pola ini sebenarnya mirip dengan penggunaan tool pada framework agent seperti LangChain atau AutoGen. Model menentukan tool apa yang harus digunakan, sementara detail implementasi API ditangani oleh tool tersebut.

Foxit PDF API MCP Server

Dalam contoh ini, Foxit menyediakan MCP Server untuk PDF API yang mengekspos lebih dari 30 operasi dokumen sebagai MCP tools.

Tool tersebut mencakup beberapa kategori utama:

Document Lifecycle

  • Upload PDF
  • Download PDF
  • Delete PDF

Membuat Dokumen

  • Word → PDF
  • Excel → PDF
  • PowerPoint → PDF
  • HTML → PDF
  • URL → PDF
  • Text → PDF
  • Image → PDF

Konversi

  • PDF → Word
  • PDF → Excel
  • PDF → PowerPoint
  • PDF → HTML
  • PDF → Text
  • PDF → Image

Manipulasi PDF

  • Merge
  • Split
  • Extract pages
  • Compress
  • Flatten
  • Linearize
  • Watermark
  • Operasi halaman lainnya

Security

  • Menambahkan password
  • Menghapus password
  • Mengatur permission

Forms

  • Export data form sebagai JSON
  • Import data form dari JSON

Selain itu tersedia pula fitur OCR dan document comparison.

Dua Model Arsitektur

Ada dua pendekatan utama yang dapat digunakan.

1. Programmatic Pipeline

Pada pendekatan ini, AI agent seperti Claude Desktop, Cursor, VS Code dengan GitHub Copilot, atau framework agent custom terhubung ke Foxit MCP Server.

Alurnya:

AI Agent
   │
   ▼
MCP Server
   │
   ▼
Foxit PDF Services API
   │
   ▼
Hasil operasi dokumen
   │
   ▼
AI Agent

AI agent dapat menjalankan beberapa operasi secara berurutan tanpa harus menulis REST integration secara manual.

Pendekatan ini cocok untuk workflow otomatis yang berjalan tanpa banyak intervensi manusia.

2. In-App Orchestration

Pendekatan kedua menggunakan Foxit PDF Editor sebagai MCP Host.

AI Assistant di dalam aplikasi dapat terhubung dengan MCP Server eksternal dan melakukan tindakan berdasarkan dokumen yang sedang dibuka.

Contohnya, AI dapat mengambil informasi dari kontrak PDF kemudian membuat tiket di Jira atau melakukan tindakan pada layanan lain.

Model ini lebih cocok untuk knowledge worker yang tetap ingin mengawasi proses dari dalam aplikasi. Peran seperti ini sebenarnya cukup dekat dengan pola kerja yang belakangan makin populer di dunia engineering.

Persiapan Sebelum Memulai

Untuk mengikuti contoh ini, beberapa hal perlu disiapkan:

  • Akun Foxit Developer.
  • Foxit PDF API MCP Server.
  • MCP-compatible host seperti Claude Desktop, Cursor, atau VS Code.
  • Python workspace untuk contoh eSign.
  • Environment variables untuk kredensial API.

Implementasi MCP Server menyediakan versi Python dan TypeScript. Versi Python menggunakan FastMCP dan membutuhkan Python 3.11+, sedangkan implementasi TypeScript membutuhkan Node.js 18+.

Untuk contoh Python, kita dapat membuat virtual environment:

mkdir agentic-docs && cd agentic-docs

python3 -m venv .venv
source .venv/bin/activate

pip install requests

Kemudian konfigurasi environment variables:

export FOXIT_CLOUD_API_HOST="https://na1.fusion.foxit.com/pdf-services"
export FOXIT_CLOUD_API_CLIENT_ID="your_client_id"
export FOXIT_CLOUD_API_CLIENT_SECRET="your_client_secret"

Jangan menyimpan Client ID dan Client Secret langsung di source code atau file konfigurasi yang akan masuk repository.

MCP Server akan membaca credential tersebut ketika dijalankan dan menggunakannya untuk melakukan autentikasi ke PDF Services API.

Menghubungkan MCP Server dengan VS Code

Untuk VS Code, MCP Server dapat didaftarkan melalui file:

.vscode/mcp.json

Contoh konfigurasi:

{
  "servers": {
    "foxit-pdf": {
      "command": "uv",
      "args": [
        "--directory",
        "/absolute/path/to/foxit-pdf-api-mcp-server",
        "run",
        "foxit-pdf-api-mcp-server"
      ],
      "env": {
        "FOXIT_CLOUD_API_HOST": "${env:FOXIT_CLOUD_API_HOST}",
        "FOXIT_CLOUD_API_CLIENT_ID": "${env:FOXIT_CLOUD_API_CLIENT_ID}",
        "FOXIT_CLOUD_API_CLIENT_SECRET": "${env:FOXIT_CLOUD_API_CLIENT_SECRET}"
      }
    }
  }
}

Dengan konfigurasi tersebut, VS Code menjalankan MCP Server sebagai subprocess melalui uv.

Credential tetap diambil dari environment variable sehingga tidak perlu ditulis secara langsung di mcp.json.

Untuk Claude Desktop, server juga dapat dijalankan menggunakan package npm yang disediakan tanpa harus melakukan clone repository secara manual.

Operasi Dokumen yang Bisa Dilakukan AI Agent

Setelah MCP Server aktif, AI agent dapat menggunakan berbagai tool untuk membangun pipeline dokumen.

Ada lima operasi yang sangat berguna dalam workflow production:

  • Conversion
  • OCR
  • Structural extraction
  • Merge / Split
  • Document generation

Mari lihat bagaimana masing-masing digunakan.

1. Conversion

Misalnya agent mendapatkan file DOCX.

Sebelum melakukan operasi berikutnya, agent dapat mengubahnya menjadi PDF terlebih dahulu.

DOCX
 ↓
Word → PDF
 ↓
PDF
 ↓
OCR / Extraction / Merge

Dengan membuat format dokumen menjadi konsisten sejak awal, operasi berikutnya dapat bekerja dengan format yang sama.

2. OCR

OCR sangat berguna ketika dokumen berupa hasil scan atau PDF yang sebenarnya hanya berisi gambar.

Misalnya:

invoice.pdf
     │
     ▼
    OCR
     │
     ▼
PDF dengan teks
     │
     ▼
Data Extraction

Tanpa OCR, agent mungkin tidak dapat membaca informasi yang terdapat di dalam gambar.

Untuk invoice, kontrak, formulir, dan dokumen administratif hasil scan, OCR biasanya menjadi langkah awal sebelum proses ekstraksi data.

3. Structural Extraction

Setelah dokumen dapat dibaca, agent dapat melakukan ekstraksi secara terstruktur.

Contohnya:

{
  "invoice_number": "INV-2026-001",
  "date": "2026-08-26",
  "company": "Example Company",
  "total": 15000000
}

Selain teks, structural extraction dapat digunakan untuk mengambil informasi seperti:

  • Teks.
  • Tabel.
  • Form fields.
  • Konten berdasarkan halaman.
  • Gambar.

Hasilnya dapat diteruskan ke sistem lain seperti database, BI tools, atau LLM berikutnya untuk proses klasifikasi dan analisis.

4. Merge dan Split

Operasi sederhana seperti merge dan split menjadi sangat berguna dalam workflow otomatis.

Misalnya perusahaan memiliki:

contract.pdf
invoice.pdf
attachment.pdf

Agent dapat menggabungkannya menjadi:

complete-package.pdf

Sebaliknya, dokumen besar dapat dipecah menjadi beberapa bagian:

large-document.pdf
        │
        ▼
   ┌────┼────┐
   ▼    ▼    ▼
Part 1 Part 2 Part 3

Pembagian seperti ini juga dapat membantu ketika dokumen perlu diproses secara paralel oleh beberapa langkah AI.

5. Membuat Dokumen Secara Dinamis dengan DocGen

Salah satu bagian yang menarik adalah pembuatan dokumen berdasarkan template.

Foxit Document Generation API dapat menggunakan template DOCX yang memiliki dynamic tags seperti:

{{customer_name}}
{{invoice_number}}
{{total_amount}}

Kemudian agent memberikan data dalam bentuk JSON:

{
  "customer_name": "Budi",
  "invoice_number": "INV-001",
  "total_amount": 15000000
}

Template tersebut kemudian dapat menghasilkan dokumen PDF baru.

Arsitekturnya:

DOCX Template
      +
   JSON Data
      │
      ▼
     DocGen
      │
      ▼
 Generated PDF

Pendekatan ini memungkinkan satu template digunakan untuk menghasilkan banyak dokumen yang berbeda berdasarkan data dari database, CRM, atau form.

Contoh Workflow dari Awal hingga Akhir

Sekarang kita bisa menggabungkan seluruh komponen.

Misalnya perusahaan menerima purchase order dalam bentuk PDF hasil scan.

Agent dapat menjalankan workflow berikut:

Purchase Order
      │
      ▼
     OCR
      │
      ▼
Extract Structured Data
      │
      ▼
    DocGen
      │
      ▼
 Generated Contract
      │
      ▼
     eSign
      │
      ▼
 Signed Document

Yang menarik, AI agent yang menentukan urutan operasi.

MCP Server bertanggung jawab menerjemahkan tool call menjadi request ke PDF Services API.

Dengan demikian, developer tidak perlu membuat integrasi REST khusus untuk setiap langkah workflow.

Menghubungkan Workflow dengan eSign

Proses tanda tangan menggunakan Foxit eSign API, yang merupakan layanan terpisah dari PDF Services API.

Artinya, credential untuk eSign juga berbeda.

Contoh environment variables:

export FOXIT_ESIGN_BASE_URL="https://na1.foxitesign.foxit.com"
export FOXIT_ESIGN_CLIENT_ID="your_esign_client_id"
export FOXIT_ESIGN_CLIENT_SECRET="your_esign_client_secret"

Workflow eSign pada dasarnya terdiri dari beberapa langkah:

PDF siap
  │
  ▼
Request Access Token
  │
  ▼
Create Signing Folder
  │
  ▼
Tambahkan Signer
  │
  ▼
Send for Signature

API menggunakan OAuth client_credentials untuk mendapatkan bearer token.

Setelah itu, PDF dapat dikirim ke endpoint createfolder, kemudian folder tersebut dikirim melalui sendDraftFolder.

Contoh sederhananya:

import base64
import os
import requests

BASE_URL = os.environ["FOXIT_ESIGN_BASE_URL"]
CLIENT_ID = os.environ["FOXIT_ESIGN_CLIENT_ID"]
CLIENT_SECRET = os.environ["FOXIT_ESIGN_CLIENT_SECRET"]


def get_access_token():
    response = requests.post(
        f"{BASE_URL}/api/oauth2/access_token",
        data={
            "client_id": CLIENT_ID,
            "client_secret": CLIENT_SECRET,
            "grant_type": "client_credentials",
            "scope": "read-write",
        },
        timeout=30,
    )

    response.raise_for_status()

    return response.json()["access_token"]

Perhatikan bahwa endpoint token tersebut menggunakan form-encoded request, bukan JSON. Mengirim body dalam format JSON dapat menghasilkan 415 Unsupported Media Type.

Signature Field pada Dokumen

Ada satu hal penting sebelum dokumen dikirim untuk ditandatangani.

Signer harus memiliki signature field.

Salah satu cara yang digunakan adalah dengan menambahkan text tag pada dokumen.

Contohnya:

${s:1:________}

Kemudian API memproses text tag tersebut menjadi signature field ketika:

{
  "processTextTags": true
}

digunakan.

Jika tidak ada signature field, proses pengiriman dokumen untuk ditandatangani dapat gagal.

Hal Penting untuk Production

Membangun prototype memang relatif mudah.

Namun ketika workflow mulai digunakan dalam skala besar, ada beberapa hal yang harus diperhatikan.

1. API Credit

Setiap successful API call pada Foxit PDF Services API menggunakan satu credit.

Request yang menghasilkan HTTP 4xx atau 5xx tidak menggunakan credit.

Developer Dashboard menyediakan informasi penggunaan secara real-time sehingga biaya workflow dapat dipantau sebelum sistem diperbesar.

2. Idempotency

Tidak semua operasi aman untuk diulang.

Operasi seperti:

  • Merge
  • Flatten
  • Convert

dapat di-retry ketika terjadi kegagalan.

Namun pembuatan signing folder tidak bersifat idempotent.

Jika agent mengulangi createfolder tanpa melakukan pengecekan status terlebih dahulu, sistem dapat membuat folder duplikat dan bahkan mengirim permintaan tanda tangan lebih dari sekali.

Karena itu, proses pembuatan signing folder sebaiknya dilindungi dengan state check.

3. Async Operation

Beberapa operasi berjalan secara asynchronous.

API dapat mengembalikan sebuah job ID terlebih dahulu.

Agent kemudian harus melakukan polling hingga status berubah menjadi:

COMPLETED

atau:

FAILED

Dokumen sumber merekomendasikan polling sekitar setiap tiga detik untuk operasi tersebut.

Kesalahan yang Sering Terjadi

Beberapa kesalahan yang perlu diperhatikan ketika menggunakan eSign API:

Lupa /api/

Endpoint eSign menggunakan prefix /api/.

Contohnya:

/api/folders/createfolder

bukan path tanpa /api/.

Mengirim access token request sebagai JSON

Gunakan form data, bukan JSON.

Lupa inputType: base64

Jika mengirim file menggunakan base64, API perlu mengetahui bahwa input tersebut menggunakan format base64.

Tidak menyediakan signature field

Signer dengan permission FILL_FIELDS_AND_SIGN harus memiliki signature field.

Menganggap signing tersedia di MCP Server

MCP Server menyediakan tool untuk operasi PDF, sedangkan proses signing menggunakan Foxit eSign API yang terpisah.

MCP + PDF API: Kenapa Menarik untuk Developer?

Pendekatan ini menunjukkan perubahan menarik dalam cara kita membangun aplikasi berbasis AI.

Sebelumnya, developer mungkin membuat workflow seperti:

Backend
  │
  ├── REST API A
  ├── REST API B
  ├── REST API C
  ├── OCR Service
  └── Signing Service

Kemudian developer harus menulis logic untuk menentukan kapan setiap API dipanggil.

Dengan agentic architecture:

              ┌─────────────┐
              │  LLM Agent  │
              └──────┬──────┘
                     │
                    MCP
                     │
       ┌─────────────┼─────────────┐
       ▼             ▼             ▼
     OCR          Convert        Merge
       │             │             │
       └─────────────┼─────────────┘
                     ▼
                   DocGen
                     │
                     ▼
                   eSign

Agent dapat menentukan tool yang diperlukan berdasarkan tugas.

Developer kemudian lebih fokus pada desain workflow, business logic, keamanan, dan reliability, dibandingkan membuat wrapper API satu per satu.

Kesimpulan

Agentic document workflow membawa konsep AI agent satu langkah lebih jauh.

LLM tidak lagi hanya digunakan untuk membaca dokumen dan menjawab pertanyaan. Dengan bantuan MCP dan API yang dapat dipanggil sebagai tools, AI agent dapat menjalankan rangkaian operasi seperti:

  • OCR
  • Ekstraksi data
  • Konversi dokumen
  • Merge dan split PDF
  • Manipulasi dokumen
  • Pembuatan dokumen dari template
  • Pengiriman dokumen untuk tanda tangan elektronik

Dalam arsitektur Foxit, MCP Server menyediakan lebih dari 30 tool untuk operasi PDF, sementara proses signing ditangani oleh eSign API secara terpisah.

Konsep ini sangat menarik untuk aplikasi seperti automated invoice processing, contract management, document onboarding, compliance workflow, dan berbagai sistem back-office berbasis AI. Perkembangan model AI di balik semua ini pun terus bergerak cepat — termasuk dari sisi riset di luar domain dokumen sekalipun.

Pada akhirnya, pergeseran pentingnya bukan sekadar dari chatbot ke AI agent, tetapi dari:

AI yang hanya memahami dokumen

menjadi:

AI yang dapat memahami, memproses, menghasilkan, dan menindaklanjuti dokumen.

Itulah salah satu area di mana kombinasi LLM + MCP + API mulai memberikan dampak nyata pada software engineering dan otomasi bisnis.

Artikel terkait lainnya di KonsepKoding: