Configuration overview
Use project rules, memory, skills, and external tools to make EvoX fit your work.
Configuration means putting lasting requirements in the right place. You do not need to fill every setting at once. Several layers work together:
- Project working rules describe requirements for one project.
- Personalization and memory provide communication preferences and lasting background.
- Skills preserve repeatable working methods.
- MCP and plugins connect tools and external services.
- Subagents handle clearly defined parts of a task.
For a weekly project report, rules can define its structure, memory can supply team background, a skill can organize the steps, MCP can provide project records, and a subagent can independently verify some sources. You do not have to explain every requirement again for each task.
Project working rules
Project rules hold requirements you use throughout a project. Open the workbench under collaboration, select project details, and add, edit, or enable working rules.
Make each requirement concrete and checkable. For example:
- Put user steps before terminology in product documentation.
- Keep source links and mark unverified information as pending confirmation.
- Run relevant checks after code changes and state the verification scope.
- Check the task's authorized scope before publishing or sending content.
A documentation rule might read:
Write for everyday users. Explain the outcome before the steps. Mark unverified features as pending confirmation, and state the applicable version when behavior varies.
When to update rules
When the same issue recurs, save the corrected requirement in the rule. Also update rules when project terminology, deliverable formats, or verification methods change.
Keep one-time goals in the current task. Keep lasting rules short, merge duplicates, and disable temporarily irrelevant entries while preserving their content.
Rules participate in collaboration context for their project. Check the conversation's project and whether rules are enabled. Selecting a different project in the interface does not automatically move an existing conversation.
Configure project working rules
Personalization and memory
Personalization and memory include several distinct controls:
| Content | How it participates | Where to maintain it |
|---|---|---|
| Conversation profile | Names and reply preferences participate directly; language has separate conditions | Conversation-profile area on the Memory page |
| Memory entries | Recalled according to task relevance; saving does not imply use in every task | Memory list and recall testing |
| Style presets | Shape naming and reply tone within selected scopes; Reply tone overrides the profile's reply style | Personalization in Settings |
Suitable lasting information includes:
- Your usual language and preferred form of address.
- Whether you prefer conclusions first or fuller explanations.
- Stable work background, responsibilities, and terminology.
Put requirements specific to one project in project rules. State this task's format, deadline, and special constraints in the task itself.
Profile language normally provides a fallback when input language cannot be determined. Enabling “Always reply in this language” overrides input language. The deliverable-copy scope of a style preset changes titles and summaries only; specify body formatting in the task.
Memory needs inspection and correction. Deleting a chat and managing memory are different operations. Hiding a memory entry does not permanently delete it.
Profile and response style · Memory management
Skills and plugins
A skill turns recurring work into a reusable method. Project rules describe ongoing requirements; skills are useful for particular workflows, such as weekly reports, source verification, or preparing a deliverable from a template.
A clear skill typically includes:
| Part | Weekly report example |
|---|---|
| Purpose and use case | Summarize progress from project records each week |
| Inputs | This week's records, last week's plan, and allowed sources |
| Steps | Extract progress, check unfinished items, organize risks and next steps |
| Output | A consistently structured report with source links |
| Verification | Do not invent progress; flag claims without evidence |
Include templates, references, or scripts when needed. Try a real small task and revise unclear steps before expanding the skill.
Plugins provide installable capabilities and connections, and may include skills or MCP tools. Review their source, dependencies, and access scope, then connect any required accounts after installation.
Add and manage skills and plugins
MCP servers
MCP connects EvoX to external tools and context sources. When a task needs information or actions outside the local workspace, check whether the relevant service provides an MCP server.
A connection can run a local process or access a remote service. Prepare the command, arguments, or MCP endpoint according to the provider's instructions, complete authentication, and inspect the actual tool list.
Installed, connected, and able to complete a task are different states. After connecting, read one permitted item to verify account scope and tool results before trying write operations.
Skills and MCP work together: a skill describes how to prepare the weekly report, while MCP supplies project records. A method alone does not retrieve data, and a connection alone does not define a useful report.
Subagents
Subagents handle independent subtasks, such as checking sources, reviewing files, or researching a focused topic. The main task owns the goal and synthesis; each assistant owns a defined part.
Specify responsibilities, inputs, outputs, available tools, and stopping conditions. For example:
Check factual claims in the supplied paragraphs using only allowed sources. Return confirmed, unverified, and incorrect items with source links. Do not edit the original text.
Short questions rarely need delegation. When assistants work on the same material, define boundaries to avoid duplicate edits, then inspect evidence and reconcile conflicting results.
How configuration works together
Think in terms of requirements, background, methods, tools, and delegation:
| What you need to change | Where it belongs |
|---|---|
| Ongoing requirements for one project | Project working rules |
| Preferred name and lasting reply preferences | Conversation profile |
| Experiences and background useful in later tasks | Memory entries |
| Naming and reply tone | Style presets and their scopes |
| Steps for recurring work | Skills |
| External data and actions | Plugins or MCP |
| Responsibilities for an independent subtask | Subagents |
Configuration does not expand authorization. File access, writes, deletion, and external messages still depend on actual permissions and the task's authorized scope. See Permissions and approvals.
Start here
- Connect a model. Test the connection and send a short question to verify an actual response. See Models and services.
- Tune everyday use. Choose a comfortable theme, language, reading size, and notifications. See Desktop settings.
- Write a few project rules. Start with recurring requirements and verify them in a small task.
- Add lasting preferences. Inspect the profile and memory, keeping stable and accurate background.
- Add capabilities as needed. Turn repeatable methods into skills, connect tools for external information, and configure subagents for independent work.
Change one layer at a time and verify it with a clearly scoped task. This makes the effect easier to observe and unsuitable settings easier to correct.
Standalone Evolver configuration
The sections above describe EvoX Desktop. Running Evolver independently requires separate identity and Hub settings, evolution policies, publishing behavior, and runtime directories.
The app manages its embedded Evolver. Standalone CLI variables do not replace desktop account, permission, or update settings.
Identity and Hub connection · Evolution strategies and loops · Publishing and credits · Directories and deployment