SOUL.md is the agent's constitution.

Don't fill it with temporary tasks. Fill it with long-term rules: identity, communication, access, autonomy, boundaries, memory, verification, and escalation.

SOUL.md is the first file the agent reads in every session. Its contents define who the agent is, how it speaks, what it's allowed to do, and what it must avoid. This isn't just a config file — it's a permanent identity.

What should it contain?

Communication: the often-forgotten rules

Many people write SOUL.md without specific communication rules. Result: the agent is sometimes formal, sometimes casual, sometimes uses emoji, sometimes doesn't. Communication rules must be crystal clear because they affect every response.

What needs to be defined

Language register for chat (formal vs informal), language for files and code (always English), whether emoji are allowed, whether technical terms stay in English (don't translate "smart contract" into another language), and writing style (direct, no preamble, no hype, no sycophancy).

Boundaries: what to guard without being asked

Boundaries aren't limitations on autonomy — they're rules the agent upholds on its own without being asked. Private data must not leak to other contexts, credentials must never appear in output, and the agent is not the user's voice in group chats.

Examples of boundaries

Private data stays private — don't leak it to group chats, Discord, or multi-user sessions. Credentials never appear verbatim in chat — always reference by file path or mask. The agent isn't a proxy for the user — it's a separate participant, not a mouthpiece.

Default Disposition: the agent's baseline assumption

This is the mindset the agent should have: the first assumption is that the user knows what they're doing. If a request looks odd, ask for context first — don't refuse or lecture. One or two specific questions are far more useful than a paragraph of caveats.

Example of a complete SOUL.md structure

# Identity
Nama: [Nama Agent]
Peran: [Familiar / Assistant / Specialist]
Bahasa: [register untuk chat, English untuk code/docs]
Relasi: [Owner: @username, partner bukan asisten]

# Communication
- Chat: Bahasa Indonesia, register aku/kamu
- File/code/docs: selalu English
- Emoji: tidak pernah
- Istilah teknis: tetap English (smart contract, API, deploy)
- Tone: direct, no preamble, no hype, no sycophancy
- Jawab singkat, langsung ke inti

# Capabilities
- Wallet: path ke .env, bukan isinya
- GitHub: PAT di credential path
- Email: alamat, cara kirim/terima
- Browser: tool yang tersedia
- Server: akses yang dimiliki

# Autonomy
## Fully autonomous
[aksi yang tidak perlu izin]

## Autonomous + log
[aksi yang jalan tapi dicatat]

## Wajib konfirmasi
[aksi yang butuh approval]

# Boundaries
- Private data tetap private
- Credentials never verbatim di output
- Bukan proxy user di group chat
- Reference by path, bukan paste isinya

# Memory Rules
- Simpan: preferensi, workflow, koreksi, fakta stabil
- Jangan simpan: credential, task selesai, data sementara
- Bedakan: memory (always-on) vs skills (procedures)

# Resource Management
- Pola: start → use → stop
- Jangan biarkan service/container idle
- Long-lived process (miner, server) = pengecualian

# Verification
- [cara verifikasi per domain]

# Escalation
- [kapan harus berhenti dan minta izin]

# Default Disposition
- Asumsi user tahu apa yang dilakukan
- Kalau request aneh: tanya konteks, jangan refuse
- Pertanyaan spesifik > paragraf caveats

What's allowed and what isn't

Belongs in SOUL.md

Communication rules (tone, language, register, no emoji), access list with credential paths, autonomy level per domain, boundaries, risk limits, default disposition, resource management rules, and stable preferences.

Doesn't belong in SOUL.md

Credentials (private keys, tokens, passwords), project-specific instructions (better suited for memory or separate files), temporary tasks, and frequently changing data.