Scylla is designed around a simple boundary: you choose the environment in which an Agent may work, then Scylla applies the project, Policy, credential, and connection rules around that environment.
You do not need to configure every Scylla feature before your first chat. A project, a provider, and a sensible Policy are enough to begin.
1. Add your project
Open the FILES area and use Manage Scope to add one or more project folders to Workspace Scope.
Workspace Scope means:
- the folder is active in the current Scylla application session;
- Scylla and Agents may read and write project files there, subject to normal Windows permissions;
- the project can participate in editor, Git, terminal, build, Skill, and other project operations.
Adding multiple projects does not reduce one project to read-only. All active Workspace Scope projects are available during the session.
2. Choose a Primary project
If more than one project is active, choose one as Primary.
Primary is only a fallback.
If a chat or operation clearly belongs to another active project, Scylla should use that project. Primary is used when no project has otherwise been identified.
Primary is not a favorite, a permission level, or an exclusive project.
3. Use Project Discovery
If you keep repositories under a common folder such as D:\projects, set that as your default project discovery folder.
Scylla can list immediate child folders as candidates so you can add them to Workspace Scope without repeatedly opening File Explorer.
Discovery does not grant access by itself. A discovered project becomes active only after you add it to Workspace Scope and apply the change.
4. Add Knowledge separately
Open Manage Scope from the KNOWLEDGE area to add non-project reference folders to Knowledge Scope.
Knowledge is intentionally separate from project source.
Use Knowledge for material such as:
- architecture notes;
- blueprints;
- plans;
- handoffs;
- research;
- design references;
- operational notes;
- other durable context that should not become part of a project repository.
Knowledge folders are available read/write during the session, subject to Windows permissions, but they are not treated as project roots and are not included in normal project Git operations.
A Markdown file in Workspace Scope is still a project file. A file in Knowledge Scope is Knowledge because of its configured role, not its extension.
5. Connect an Agent Provider
Choose an Agent Provider from the Agent panel and complete that provider's authentication flow.
Provider authentication is owned by the provider. Scylla does not turn a Scylla Account login into an OpenAI, Claude, Cursor, GitHub, or other provider login.
The exact providers visible depend on the Scylla build you installed.
After authentication, select a provider/model combination that the provider makes available.
6. Choose how you want the Agent to work
Scylla distinguishes conversational intent from execution authority.
Depending on the provider and current build, the Agent surface may expose modes such as:
- Execute for work that may request real project operations;
- Plan for planning and analysis without normal execution;
- Ask for question/answer work.
A mode does not override Policy. If Policy says an operation is blocked, selecting Execute does not make it allowed.
7. Review Policy
Before allowing substantial execution, open Security and review the current ALLOW / ASK / BLOCK rules.
The important idea is:
- ALLOW: Scylla may allow the operation without stopping for a Policy prompt;
- ASK: Scylla requires approval at that boundary;
- BLOCK: Scylla refuses the operation.
See Configure Policy.
8. Configure Keyring and Connections only when needed
You do not need to put every credential into Scylla on first launch.
When a project needs SSH, database, service, or other protected credentials, store the secret in Scylla's Keyring and refer to it through a Connection or other approved configuration.
Agents should receive references and brokered results rather than reusable secret values.
9. Open a terminal when you need one
Scylla supports multiple terminal sessions and Windows-oriented terminal profiles, including PowerShell and WSL configurations where available.
A provider being authenticated does not automatically grant unrestricted terminal execution. Terminal/provider execution remains subject to Scylla's current execution and Policy rules.
10. Add MCP only when it adds value
MCP connections are optional.
A connected MCP server can still be unavailable to a project or blocked by Policy. Treat these as separate questions:
- Is the MCP server configured and authenticated?
- Is it available to this project/provider?
- Is the requested operation allowed?
Do not use MCP connectivity as a substitute for project scope or Policy.
Your first useful test
A good first session is deliberately boring:
- Ask the Agent to inspect the active project.
- Ask it to explain a known file.
- Ask it to make a very small edit.
- Review the changed-file activity.
- Ask for Git status or diff.
- Confirm that operations requiring approval behave the way your Policy says they should.
Once that works, add Connections, databases, MCP, Skills, Memory, or broader project scope as needed.
If the Agent cannot see a folder
Check Manage Scope first.
A project that exists on disk is not automatically part of the current Scylla session. Add it to Workspace Scope and apply the change.
For non-project reference material, add the folder to Knowledge Scope instead.
If the provider is signed in but cannot execute
Provider authentication and Scylla authority are separate. Check:
- current Agent mode;
- Workspace Scope;
- Policy;
- terminal execution settings;
- required Connection or Keyring state;
- provider/runtime status.
See Troubleshooting.
Next
Read Configure Policy. If you are joining an organization, continue with Team Invitations and Seat Assignment.