3. Capabilities¶
Apa yang agent bisa dan ga bisa.
Kalau agent ga tau capabilities-nya, dia bakal halusinasi — claim bisa lakuin hal yang sebenernya ga bisa, atau nolak hal yang sebenernya bisa.
Yang harus ada¶
## CAPABILITIES
1. VPS bash via tool_use — eksekusi command apapun
2. GitHub via gh CLI — push, PR, manage repo (akun: dukunline-cyber)
3. Wallet crypto — kalo credential ada di credentials/,
Kai bisa transfer/sign/swap
4. Sosial media — kalo credential ada (cookie session atau API token),
Kai bisa post/reply/like
5. Email — kalo IMAP/SMTP credential ada, Kai bisa baca/kirim
6. Web search — research via internet
7. Memory — ingat preferensi dan konteks dari memory.json
8. File operations — read, write, modify file di VPS
Tools yang bisa di-output:
- <tool_use>{"name":"run_in_terminal","arguments":{...}}</tool_use>
Cara nulis Capabilities yang benar¶
1. List capability nyata, bukan teoritis¶
❌ Salah:
Kalo agent ga punya akses ke Playwright/SD/Sora, jangan list. Model bakal halusinasi.
✅ Benar:
2. Sebutin tool yang bener-bener exist di kode¶
Tiap capability harus ada implementasi tool-nya di backend. Misalnya:
# Kode backend
def execute_tool(call):
if call["name"] == "run_in_terminal":
return run_shell(call["arguments"]["command"])
elif call["name"] == "web_search":
return search_duckduckgo(call["arguments"]["query"])
else:
return f"Unknown tool: {call['name']}"
SOUL.md harus list sesuai:
3. Sebut credential dependency¶
Banyak capability butuh credential. Jelas-jelasin:
- GitHub: butuh ~/agent/credentials/github.env
- Wallet: butuh ~/agent/credentials/wallet.env
- Twitter: butuh ~/agent/credentials/twitter.env
Kalo credential ga ada, kasih tau owner buat siapin file dengan format X.
4. Sebutin platform / akun¶
Biar agent tau dia bertindak atas siapa:
5. List tool_use format yang valid¶
Format tool_use:
<tool_use>{
"name": "run_in_terminal",
"arguments": {
"command": "<shell command>",
"risk": "low|medium|high",
"explanation": "<kenapa command ini>"
}
}</tool_use>
Capabilities expansion pattern¶
Saat lo nambah capability baru, ikutin urutan ini:
- Implement tool di backend (function yang handle call)
- Test tool secara isolated (panggil fungsi langsung dari Python REPL)
- Update SOUL.md (tambah capability ke list)
- Test via chat (kasih request yang trigger capability)
- Iterate kalo agent salah pakai
Jangan kebalik: jangan list capability di SOUL.md sebelum tool-nya benar-benar ada.
Anti-patterns¶
❌ Kapabilitas yang terlalu broad¶
Model bakal halusinasi. Be specific.
❌ Kapabilitas yang ga ada batasnya¶
Tapi sebenernya cuma punya curl (ga punya browser, ga bisa execute JS). Be specific:
❌ Numbered list yang terlalu panjang¶
Kalo lebih dari 10 capability, group jadi kategori:
## CAPABILITIES
A. System: bash, file ops, package install
B. Cloud: AWS CLI, gcloud, kubectl
C. Web: curl, search, fetch
D. Identity: GitHub, Twitter, Discord, Email
E. Crypto: wallet (EVM, Solana), DeFi via uniswap-cli
Spec lengkap capabilities di Kai¶
Sebagai referensi, ini list capabilities Kai sekarang:
## CAPABILITIES
Sistem:
- run_in_terminal: eksekusi shell di VPS Ubuntu
- file ops: read, write, modify file
- service mgmt: systemctl restart/status
Web:
- web_search: DuckDuckGo Instant Answer API
- curl: HTTP fetch
Identity (kalo credential ada):
- GitHub: gh CLI (push, PR, repo mgmt)
- Twitter: cookie session via httpx
- Discord: bot token via discord.py
- Email: IMAP/SMTP
Crypto (kalo wallet.env ada):
- EVM: web3.py untuk transfer, sign, contract call
- Solana: solana-py
- DeFi: 0x API untuk swap routing
Memory:
- load_memory(): baca preferensi user
- save_memory(): simpan koreksi user
- /remember <text>: explicit save dari user
History:
- per-user chat history dengan secret redaction
- /reset: arsip + reset history user
Tips¶
- Capabilities harus match dengan tool implementations. Audit dua tempat sebelum claim capability.
- Test edge case. Apa yang terjadi kalo credential ga ada? Kalo network down? Kalo tool error?
- Update saat ada perubahan. Tambah/hapus capability di SOUL.md saat lo ubah backend.