Panduan AWS Bedrock AgentCore: Runtime, Gateway, Memory, Policy

Bayangkan sebuah distributor di Surabaya yang sudah menjalankan integrasi ERP-nya di AWS: Lambda function di depan modul purchasing, Cognito untuk portal internal, dan CloudWatch untuk semuanya. Tim sudah punya asisten procurement yang dibangun dengan OpenAI Agents SDK di laptop developer, dan pertanyaannya adalah di mana agent itu berjalan di production tanpa harus membangun sendiri isolasi session, autentikasi tool, dan audit log. AWS Bedrock AgentCore adalah jawaban yang ditawarkan AWS, dan hal pertama yang perlu dipahami: ini bukan satu produk, melainkan sekumpulan layanan modular yang bisa diadopsi satu per satu.

Panduan ini menjelaskan fungsi setiap layanan AgentCore, kapan harness yang terkelola sudah cukup dan kapan Anda men-deploy kode sendiri ke Runtime, cara merilis agent yang framework-agnostic dengan AgentCore CLI, bagaimana perilaku session, Gateway, dan Policy, serta apa arti ketersediaan region bagi tim di Indonesia. Setiap batas dan flag di bawah berasal dari developer guide AWS, blog AWS Machine Learning, dan referensi CLI per Oktober 2026.

Apa sebenarnya AWS Bedrock AgentCore

AWS menggambarkan AgentCore sebagai platform agentic yang layanannya bisa bekerja bersama atau berdiri sendiri, dengan framework open-source dan foundation model apa pun. Kemandirian itulah pilihan desain yang penting. Anda bisa menjalankan agent di Runtime sambil tetap memakai memory store sendiri, atau hanya memakai Gateway untuk membuka API yang sudah ada sebagai tool MCP bagi agent yang berjalan di tempat lain. Sembilan layanan yang biasanya dievaluasi lebih dulu adalah berikut ini.

Developer guide juga mencantumkan layanan yang lebih baru di sekitar inti ini: Payments untuk transaksi x402 dan Machine Payments Protocol, Optimization untuk A/B test prompt dan deskripsi tool, serta Registry yang mengkatalogkan agent, MCP server, dan skill. Semuanya berguna nanti; tidak satu pun wajib untuk membawa agent pertama ke production. Harganya berbasis konsumsi tanpa komitmen di muka, dan compute Runtime ditagih USD 0,0895 per vCPU-jam dan USD 0,00945 per GB-jam konsumsi aktif menurut pengumuman GA harness.

Harness atau Runtime: siapa yang memegang agent loop

Harness mencapai general availability pada 18 Juni 2026, dan ini mengubah keputusan pertama. Dengan harness Anda sama sekali tidak menulis agent. Anda mendeklarasikan model, system prompt, dan tool, lalu AgentCore menjalankan reasoning loop, eksekusi tool, memory, dan pembuatan respons. CLI membuat project harness secara default; bagian tools adalah yang paling perlu dibaca dengan teliti.

# Harness path: the agent is configuration, AgentCore runs the loop.
npm install -g @aws/agentcore
agentcore create          # wizard: choose "Harness"
agentcore deploy
agentcore invoke --prompt "Summarise yesterday's open purchase requisitions"

# The tools block of the harness config. Each entry is a managed
# capability or an endpoint; there is no orchestration code to write.
"tools": [
  { "type": "agentcore_browser" },
  { "type": "agentcore_code_interpreter" },
  { "type": "remote_mcp",
    "config": { "remoteMcp": { "url": "https://mcp.example.co.id/mcp" } } },
  { "type": "agentcore_gateway",
    "config": { "agentCoreGateway": { "arn": "arn:aws:bedrock-agentcore:..." } } }
]

Harness mendukung model Amazon Bedrock, OpenAI API secara langsung, Google Gemini, dan provider yang kompatibel dengan LiteLLM. Default yang terdokumentasi penting karena menentukan apa yang terjadi saat sebuah field dibiarkan kosong.

• Jika konfigurasi memory dihilangkan, harness menyiapkan managed memory dengan strategi SEMANTIC dan SUMMARIZATION.
• Event memory kedaluwarsa setelah 30 hari secara default, dengan kunci enkripsi milik AWS.
• Isolasi multi-tenant di dalam memory itu ditangani dengan namespace template, bukan satu store per pelanggan.
• Skill bisa dimuat dari skill bawaan AWS, repository Git, atau prefix S3.

Deploy agent OpenAI Agents SDK ke AgentCore Runtime

Runtime bersifat framework-agnostic karena kontraknya hanya HTTP biasa. Untuk protokol HTTP, server Anda listen di 0.0.0.0 port 8080, menerima POST di /invocations dengan body JSON dan mengembalikan JSON atau Server-Sent Events, serta menjawab GET di /ping dengan status kesehatan. Python SDK bedrock-agentcore sudah mengimplementasikan kontrak itu, jadi agent OpenAI Agents SDK yang sudah ada hanya butuh wrapper tipis.

# app/ErpAssistant/main.py
from bedrock_agentcore.runtime import BedrockAgentCoreApp
from agents import Agent, Runner, function_tool

app = BedrockAgentCoreApp()

@function_tool
def open_purchase_orders(vendor_code: str) -> list[dict]:
    """Read-only lookup. Writes go through Gateway, where Policy can see them."""
    return erp_client.open_pos(vendor_code)

agent = Agent(
    name="Procurement assistant",
    instructions="Answer purchasing questions. Never create or approve documents.",
    tools=[open_purchase_orders],
)

# The decorator registers this as the POST /invocations handler.
# BedrockAgentCoreApp also answers GET /ping on port 8080 for you.
@app.entrypoint
async def invoke(payload, context):
    prompt = payload.get("prompt", "")
    result = await Runner.run(agent, prompt, max_turns=8)
    return {"result": result.final_output}

if __name__ == "__main__":
    app.run()

AgentCore CLI sekarang berupa package npm yang membutuhkan Node.js 20 atau lebih baru, ditambah Python 3.10 atau lebih baru untuk kode agent. Perintah create menerima Strands, LangChain_LangGraph, GoogleADK, OpenAIAgents, dan VercelAI sebagai framework, serta Bedrock, Anthropic, OpenAI, dan Gemini sebagai model provider. Di baliknya, deployment memakai AWS CDK.

agentcore create \
  --project-name ProcurementAgents \
  --name ErpAssistant \
  --language Python \
  --framework OpenAIAgents \
  --model-provider OpenAI \
  --memory none \
  --build CodeZip           # zip to S3, no Docker needed

agentcore add credential    # stores OPENAI_API_KEY for the deployed runtime
agentcore dev               # local server + agent inspector, hot reload
agentcore deploy --dry-run  # see what CDK will create first
agentcore deploy
agentcore status            # prints the agent runtime ARN
agentcore logs --since 30m --level error

Dua detail menghemat waktu. Build default CodeZip mengunggah zip ke S3 dan tidak butuh Docker; jika memilih build Container, image harus ARM64, dan ini hal pertama yang perlu dicek ketika container yang jalan di laptop x86 gagal health check setelah deploy. Lalu di Windows, perintah agentcore lama dari package pip bedrock-agentcore-starter-toolkit bisa menutupi CLI npm di PATH, jadi uninstall dulu sebelum mempercayai output versinya.

Session: 8 jam, 15 menit idle, dan ID 33 karakter

Setiap session Runtime mendapat microVM sendiri dengan compute, memory, dan filesystem terisolasi, dan microVM itu dihentikan serta memorinya dibersihkan saat session berakhir. Session berhenti setelah 15 menit tanpa aktivitas secara default atau setelah masa hidup maksimum 8 jam di microVM, yang bisa diatur antara 60 sampai 28.800 detik lewat CLI. Session ID yang dikirim minimal 33 karakter, dan memakai ulang ID itulah yang mengarahkan request kembali ke microVM yang sama dan masih hangat.

import json
import boto3

client = boto3.client("bedrock-agentcore", region_name="ap-southeast-1")

# AgentCore does not map sessions to users. Your backend does.
# The id must be at least 33 characters; a short one is rejected.
session_id = f"tenant-{tenant_id}-user-{user_id}-{conversation_uuid}"

response = client.invoke_agent_runtime(
    agentRuntimeArn=AGENT_ARN,
    runtimeSessionId=session_id,   # same id = same microVM, warm context
    payload=json.dumps({"prompt": "Which POs for V0042 are overdue?"}).encode(),
    qualifier="DEFAULT",
)
body = b"".join(chunk for chunk in response["response"]).decode("utf-8")

# Wrong: a fresh uuid4() per request. Every call lands on a new microVM,
# pays a cold start, and loses whatever the agent held in memory.

Apa pun yang disimpan agent di memori proses atau disk lokal hilang ketika microVM berhenti. Session yang sudah berhenti bisa dilanjutkan pada invoke berikutnya dengan microVM baru, tetapi hanya data di mount session storage yang dikonfigurasi yang bertahan melewati siklus itu. Riwayat percakapan dan fakta yang harus bertahan lebih lama dari session tempatnya di AgentCore Memory atau database Anda sendiri. AgentCore juga tidak menegakkan user mana yang memiliki session mana, jadi portal ERP multi-tenant harus menyimpan pemetaan itu, beserta batas session per user, di backend-nya sendiri.

Gateway dan Identity: mengubah API ERP menjadi tool MCP

Gateway adalah bagian AgentCore yang paling langsung cocok dengan infrastruktur AWS yang sudah ada. Lambda function yang sudah membungkus API purchasing menjadi tool MCP cukup dengan mendaftarkannya sebagai gateway target beserta tool schema. Di sisi inbound, gateway berperan sebagai OAuth resource server yang memvalidasi token dari IdP Anda. Di sisi outbound, target Lambda dan Smithy memakai IAM role, sedangkan target OpenAPI memakai API key atau OAuth client credentials.

import boto3

control = boto3.client("bedrock-agentcore-control", region_name="ap-southeast-1")

# Inbound: Gateway is an OAuth resource server. Point it at your IdP.
gateway = control.create_gateway(
    name="erp-tools",
    roleArn=GATEWAY_ROLE_ARN,
    protocolType="MCP",
    authorizerType="CUSTOM_JWT",
    authorizerConfiguration={
        "customJWTAuthorizer": {
            "allowedClients": [COGNITO_APP_CLIENT_ID],
            "discoveryUrl": COGNITO_DISCOVERY_URL,
        }
    },
)

# Outbound: a Lambda that wraps the ERP API becomes one MCP tool.
# The schema is the contract the model sees; keep it narrow.
control.create_gateway_target(
    gatewayIdentifier=gateway["gatewayId"],
    name="PurchaseOrders",
    targetConfiguration={
        "mcp": {
            "lambda": {
                "lambdaArn": PO_LAMBDA_ARN,
                "toolSchema": {
                    "inlinePayload": [{
                        "name": "create_po_draft",
                        "description": "Create a DRAFT purchase order. Never posts.",
                        "inputSchema": {
                            "type": "object",
                            "properties": {
                                "vendorCode": {"type": "string"},
                                "amountIdr": {"type": "integer"},
                            },
                            "required": ["vendorCode", "amountIdr"],
                        },
                    }]
                },
            }
        }
    },
    credentialProviderConfigurations=[{"credentialProviderType": "GATEWAY_IAM_ROLE"}],
)

Ada dua konsekuensinya. Model tidak pernah memegang credential ERP; model memegang koneksi MCP ke gateway, dan gateway yang memegang role. Karena setiap tool call kini melewati satu titik, semuanya bisa dicatat, dicari, dan diatur di satu tempat. Untuk katalog tool yang besar, gateway juga menyediakan tool bawaan x_amz_bedrock_agentcore_search, sehingga agent bisa menemukan tool yang tepat lewat query bahasa alami alih-alih memuat semua schema ke context.

Policy: batas deterministik di luar prompt

Instruksi seperti jangan pernah membuat purchase order di atas 50 juta rupiah adalah permintaan kepada model, bukan kontrol. Policy di AgentCore memindahkan aturan itu ke gateway: policy engine dipasang di gateway dan setiap tool call dievaluasi sebelum dijalankan. Policy ditulis dalam Dogwood, bahasa open-source yang kompatibel dengan Cedar, sehingga policy Cedar biasa tetap berjalan tanpa perubahan, dan policy juga bisa dirancang dalam bahasa alami lalu divalidasi terhadap tool schema.

// Action names are <TargetName>___<tool>. No wildcards in action names,
// and the resource must be a specific gateway ARN when actions are named.
permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"PurchaseOrders___create_po_draft",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:ap-southeast-1:123456789012:gateway/erp-tools-a1b2c3"
)
when {
  principal.hasTag("role") &&
  principal.getTag("role") == "buyer" &&
  context.input.amountIdr <= 50000000      // integer schema = Cedar Long
};

// Incident switch: forbid always beats permit.
forbid(
  principal,
  action,
  resource is AgentCore::Gateway
);

Model evaluasinya singkat, dan aturan ketiga adalah yang paling sering mengejutkan.

• Deny by default: request hanya diizinkan jika ada permit yang cocok, jadi engine tanpa policy menolak semuanya.
• Forbid menang: forbid yang cocok selalu menolak request meskipun ada permit yang juga cocok, dan inilah yang membuat tombol darurat insiden bisa diandalkan.
• Permit tidak saling beririsan: dua permit pada satu action adalah alternatif, jadi untuk mewajibkan dua kondisi sekaligus, letakkan keduanya dalam satu permit atau tulis batasannya sebagai forbid unless.

Realitas region untuk Indonesia: AgentCore tidak ada di Jakarta

Region Asia Pacific (Jakarta), ap-southeast-3, sama sekali tidak muncul di tabel region AgentCore. Bagi tim di Indonesia, pilihan praktisnya adalah Asia Pacific (Singapore), ap-southeast-1, yang mendukung hampir semua layanan. Untuk Runtime, cakupan Malaysia lebih luas dari dugaan banyak orang, tetapi region itu tidak punya harness dan Memory.

Ada dua konsekuensi operasional. Session agent, memory record, dan trace tersimpan di Singapura walaupun database ERP tetap di Jakarta, sehingga tool call melintasi batas region dan review klasifikasi data Anda harus mencakup apa saja yang bisa dibaca agent. Selain itu, latensi dari agent ke API yang di-host di Jakarta menambah waktu setiap tool call, sehingga lebih baik memakai sedikit tool yang kasar daripada banyak tool yang cerewet. Jika data tertentu tidak boleh keluar dari Indonesia, buat tool tersebut hanya mengembalikan ringkasan atau identifier, bukan record mentah.

Bedrock Managed Agents dan memilih jalur Anda

Di DevDay pada 29 September 2026, OpenAI menyoroti Bedrock Managed Agents, limited preview yang pertama kali diumumkan pada April, yang mengambil fitur inti OpenAI Agents API, bisa disesuaikan untuk AWS, dan terhubung langsung ke resource AWS. Ini adalah opsi ketiga di samping harness dan Runtime, ditujukan bagi tim yang menginginkan model agent hosted milik OpenAI sementara data dan tata kelolanya tetap di dalam AWS. Karena masih preview, cek daftar region-nya sebelum membuat rencana; tidak ada apa pun di tabel region AgentCore yang menandakan deployment Jakarta akan segera hadir. Urutan yang masuk akal untuk tim yang AWS-first adalah sebagai berikut.

1. Buat prototipe di harness dengan model Bedrock atau OpenAI, tool lewat Gateway, dan memory default, lalu ukur apakah loop berbasis konfigurasi itu sudah cukup.
2. Pindah ke Runtime ketika Anda butuh orkestrasi di level kode, dengan framework yang sudah biasa diuji tim, seperti OpenAI Agents SDK atau LangGraph.
3. Letakkan setiap aksi tulis di balik Gateway dengan Policy engine, uji aturannya dalam LOG_ONLY, lalu beralih ke enforcement.
4. Evaluasi Bedrock Managed Agents hanya jika Anda memang menginginkan model OpenAI Agents API di AWS dan beban kerja Anda masih sesuai dengan batasan sebuah preview.

Kesalahan yang umum adalah mengadopsi semuanya sekaligus. Runtime plus Observability sudah merupakan deployment pertama yang lengkap; Memory, Gateway, dan Policy ditambahkan ketika muncul kebutuhan yang konkret, dan desain modular memang dibuat untuk itu.

AgentCore paling mudah dipahami sebagai jawaban terpisah untuk masalah yang terpisah: harness atau Runtime untuk tempat loop berjalan, Memory untuk apa yang bertahan setelah session, Gateway dan Identity untuk cara menjangkau tool, dan Policy untuk apa yang tidak boleh dilakukan agent. Pilih set terkecil yang menjawab kebutuhan hari ini, deploy ke Singapura jika Anda berada di Indonesia, dan tegakkan batas di gateway, bukan di prompt.