Overview
Zeus builds a custom System Prompt for every Agent invocation. The prompt is assembled from multiple fixed modules and dynamically injected sections, defining the Agent’s identity, capability boundaries, tool usage rules, and behavioral guidelines. The System Prompt is the most complex component of the Context — the complete input sent to the model on each call.Structure
The System Prompt is assembled in the following order:| Section | Type | Description |
|---|---|---|
| CORE | Fixed | Core identity, technical capabilities, general abilities, limitations |
| SOUL | Fixed | Personality traits, values, communication style rules |
| TOOLS | Fixed + Dynamic | Tool hierarchy description; dynamically replaces current available tool list |
| WORKFLOW | Fixed | Quick response vs complex task judgment, write_todos usage rules |
| MEMORY | Fixed | Memory trigger words, tool usage, type/scope selection |
| MODE | Mode-selected | Agent / Ask / Plan behavior rules |
| Time | Dynamic | Date, timezone — lets the Agent perceive time |
| Skills | Dynamic | Available skill names + descriptions (progressive disclosure) |
| Connector | Dynamic | Browser / Desktop control instructions (based on connection status) |
| MCP Prompts | Dynamic | User-selected prompt templates |
| Profile | Dynamic | User preferences/skills/habits + project tech stack/constraints |
| Memories | Dynamic | Historical memories relevant to the current conversation |
| Resources | Dynamic | Context files referenced by the user via @ |
| Sandbox | Dynamic | List of files in the sandbox |
| Attachments | Dynamic | User-uploaded images, documents |
Build Process
The System Prompt is rebuilt byBaseService._build_system_prompt() on every Agent call. The complete assembly pipeline:
Loading Methods
| Method | Source | Description |
|---|---|---|
_load_prompt(name) | Core prompt directory | Load core prompt files |
_load_mode_prompt(mode) | Mode prompt directory | Load mode-specific prompts |
_build_connector_skills_prompt() | Skills directory | Load Connector Skills |
_build_tools_description() | Runtime-generated | Dynamically generate tool names, descriptions, parameter schemas |
CORE
Core identity declaration. Defines what Zeus is, what it can do, and what it cannot do.Technical Capabilities
- Frontend: TypeScript, JavaScript, React, Vue, Next.js
- Backend: Python, Node.js, Go, Java
- Databases: PostgreSQL, MySQL, MongoDB, Redis
- Infrastructure: Docker, Kubernetes, AWS, GCP
- AI/ML: LLM integration, RAG, Agent frameworks
General Capabilities
Code generation & explanation, architecture design & review, problem diagnosis & debugging, documentation writing.Limitations
- Cannot access real-time internet information (unless using search tools)
- Cannot perform tasks requiring physical interaction
- Cannot guarantee 100% code correctness — recommends user testing
- Has knowledge cutoff date limitations
SOUL
Personality and communication style. Ensures the Agent maintains a consistent professional image across all interactions.Personality Traits
| Trait | Behavior |
|---|---|
| Professionalism | Deep understanding of technical problems, providing accurate and reliable solutions |
| Friendliness | Patient explanations, encourages learning, respects user’s technical level |
| Honesty | Candid about limitations, proactively acknowledges uncertainty, avoids over-promising |
Communication Rules
- No emoji — unless the user explicitly requests them
- Plain text — avoid excessive formatting
- Professional and concise — avoid redundancy and filler
- Language consistency — reply in whatever language the user uses
TOOLS
Tool usage guide. Describes the five-layer tool hierarchy, priority, and selection rules. Tools are layered by priority: Middleware → Filesystem → External MCP → Sandbox → Knowledge Base. The{tools_description} placeholder is replaced at runtime with the current available tool list and descriptions. The system iterates over all enabled tools, extracts names, descriptions, and parameter schemas, generating a formatted tool description list.
Key Distinction
| Tool | Purpose | Persistence |
|---|---|---|
write_todos | Task planning and progress tracking | Session-level |
save_memory | User preferences and important information | Permanent |
Tools
Tool hierarchy, mode filtering rules, and complete tool list
WORKFLOW
Task processing methodology. Guides the Agent on how to assess task complexity and choose execution strategies.Quick Response vs Complex Task
| Type | Characteristics | Uses write_todos? |
|---|---|---|
| Quick response | Simple Q&A, code snippet explanation, small edits | No |
| Complex task | Multi-step, requires planning, might fail and needs tracking | Yes |
Execution Flow
Markdown Reports
Generated when the user explicitly requests them or after completing complex analysis tasks. Not proactively generated for simple Q&A or code modifications.MEMORY
Memory system instructions. This module tells the Agent when to save memories, how to choose types and scopes. It is part of the System Prompt’s fixed modules, providing the behavioral rules for memory operations.High-Priority Trigger Words
When the user’s message contains keywords like “remember”, “I like”, “I don’t like”, “my preference”, “from now on”, “always”, “never”, the Agent should immediately callsave_memory.
Quick Reference
| Type | Description | Example |
|---|---|---|
preference | User preferences | ”likes concise code” |
fact | Factual information | ”is a frontend engineer” |
skill | Skill level | ”proficient in React” |
habit | Usage habits | ”often uses TypeScript” |
constraint | Constraints | ”project must support IE11” |
| Scope | Lifecycle |
|---|---|
user | Across all projects |
project | Current project |
session | Current session |
Memory — Full Architecture
Four-layer memory model, memU data architecture, Memory Gate, retrieval ranking, profile generation, and API reference
Mode Prompts
Different mode prompts are injected based on the current mode, constraining the Agent’s tool set and behavioral boundaries:| Mode | Permissions | Behavior |
|---|---|---|
| Agent | Full | Complete tool access, autonomous planning and execution, HITL approval support |
| Ask | Read-only | Analysis and Q&A, no file modification, guides user to switch to Agent mode |
| Plan | Read-only | Research and planning, outputs structured plans, asks user whether to execute |
Progressive Disclosure
In Ask mode, write tools are replaced with placeholders — the Agent knows the tools exist but cannot call them. It explains that the current mode cannot modify and suggests switching modes.Skills Injection
When available Skills exist, Zeus injects a compact skill metadata list (name + description) without the full content. The Agent loads complete instructions on-demand via theload_skill tool.
| Phase | Injected Content | Token Cost |
|---|---|---|
| Startup | Skill name + one-line description | Very low |
| On-demand load | Full SKILL.md content | As needed |
Skills
SKILL.md definition, management API, built-in skills, and progressive loading strategy
Profile & Memory Injection
At the end of the System Prompt, Zeus injects user profile and relevant memories so the Agent can perceive user context without explicit retrieval:- User Profile — aggregated summary of user preferences, skills, and habits
- Project Profile — current project’s tech stack, constraints, and goals
- Related Memories — historical memories matching the current conversation context
_init_context() during the context assembly phase. Profile data comes from the Memory system’s Layer 3 (Profile Layer), which aggregates individual memory items into structured profiles.
Time Handling
The System Prompt includes a current date and time section, enabling the Agent to perceive time. When the Agent needs precise timing, it can obtain it through tools.Safety
Safety guards in the System Prompt are advisory — they guide model behavior but do not enforce policies. Hard enforcement is ensured through:| Mechanism | Description |
|---|---|
| HITL Approval | Sensitive tool execution requires user confirmation |
| Mode Filtering | Write tools are unavailable in Ask/Plan modes |
| Tool Allowlist | Auto-Run Allowlist controls automatic execution scope |
| Sandbox Isolation | Code executes in an isolated environment |
Design Principles
| Principle | Description |
|---|---|
| Modular | Each file handles a single responsibility, enabling independent updates and testing |
| Dynamic Injection | Modules are dynamically selected based on user settings and context |
| Progressive Disclosure | Agent mode has full permissions; other modes progressively restrict |
| Compact & Efficient | Minimize fixed token consumption; dynamic content is injected on-demand |