A little over a week ago, I was describing Scylla as a wrapper around an AI coding agent.
That description is already wrong.
The original problem was still real. I have client repositories, internal systems, unfinished products, infrastructure credentials, research, and years of work on the same machine. Some of it belongs to me. Some of it absolutely does not. Using an AI assistant on one project does not create a reasonable argument for giving that assistant broad access to everything else I happen to maintain.
What changed is that I stopped thinking about that problem as a launcher problem.
Scylla has turned into a development workbench built around a much more useful question:
What capabilities does the agent actually need for this task?
That distinction has become the entire point of the application.
The problem was never really the AI model
I use AI constantly in development now. It helps me work through architecture, investigate bugs, change code, reason about unfamiliar systems, write implementation plans, inspect infrastructure, and get through the boring parts of engineering faster.
I do not have an ideological objection to an AI agent being capable.
I have an objection to capability and authority being treated as the same thing.
An agent may be perfectly capable of reading every repository on a workstation, opening a terminal, finding credentials, querying a database, talking to an MCP service, and changing remote infrastructure. That does not mean every one of those actions should become implicitly available because I opened a chat window.
The useful boundary is not:
AI allowed
AI not allowedIt is closer to:
this project
these folders
these reference materials
these tools
this terminal authority
this connection
this credential-backed operationThat became Scylla.
The launcher was the least interesting version of it
The first design was straightforward. I wanted a wrapper that could launch an existing AI desktop application inside a more limited part of Windows.
That path ran into the practical limitations of trying to preserve somebody else’s application model while changing the authority it ran under. The early Win32 prototype was useful because it proved the larger point, but the launcher itself was a dead end.
So I stopped trying to contain another desktop interface and built the workbench I actually wanted to use.
The old Win32 application is gone. Scylla is now a Windows desktop application built with C# and WinUI 3, backed by a native core and broker for the things that need to happen below the UI layer.
More importantly, the agent is no longer the center of the product.
The project is.
A project should define more than a folder in a sidebar
Most development tools use “project” as a convenient grouping mechanism. Scylla treats it as the beginning of an authority boundary.
A project can define the source folders I am working in, the conversations associated with that work, which Knowledge sources are available, which MCP connections can be used, which remote Connections belong to it, and which execution policies apply.
That means switching projects is not supposed to be cosmetic.
If I am working on Client A, there should be a meaningful difference between that environment and Client B. The fact that both happen to exist on the same Windows account should not collapse those boundaries.
This matters even when there is no malicious behavior involved. A capable agent can make a perfectly reasonable decision using context I never intended it to have. The safer design is to make irrelevant material unavailable in the first place.
Knowledge does not necessarily belong in the repository
This became one of my favorite parts of Scylla.
AI-assisted development creates a temptation to put everything the model might need into the source tree. Plans, implementation notes, architecture documents, client requirements, handoffs, research, prompts, instructions, and whatever else might help the next session all start accumulating beside the code.
That feels wrong to me.
Useful context and source code are related, but they are not the same thing.
Scylla has a separate Knowledge layer so I can attach supporting material to a project without pretending that material belongs in the repository. A folder of architecture notes can be useful to the agent without becoming part of the application being shipped. Client documents can be made available deliberately instead of being copied into some .ai-context directory and forgotten.
It also means Knowledge can have its own permissions.
The project repo can be writable while a documentation source is read-only. A reference folder can be visible to me without automatically being available to the agent. The distinction stays explicit.
Credentials should enable an operation, not become model context
This is where Scylla became much more interesting to me.
The application now has an encrypted Keyring for protected values. But the important part is not merely that passwords and keys can be encrypted at rest.
The important part is what happens next.
My preferred model is:
Agent
↓
requests an operation
↓
Scylla policy
↓
Scylla broker
↓
credential is used internally
↓
operation executesrather than:
Agent
↓
receives credential
↓
does whatever it wants with itThat difference is enormous.
If an agent needs to query a database, it does not necessarily need the database password. If it needs to deploy to a server, it does not necessarily need possession of the SSH private key. If it needs to authenticate to a remote service, it does not necessarily need the secret copied into its prompt or inherited environment.
The credential can remain behind the broker while the useful capability is exposed.
That is the direction behind Scylla’s Keyring and Connections architecture.
@prod-db is a much better abstraction than “here is the password”
Consider a very ordinary development task.
I need to SSH into a server, connect from there to an RDS MySQL instance over port 3306, inspect some tables, run a few queries, and understand what is happening.
The lazy agent architecture is:
give the agent a shell
give the shell the SSH key
give the shell the database credentials
hope the model behavesThe architecture I want is:
@prod-dbThat alias can represent a project-scoped connection with:
an SSH route
a database host
a database name
Keyring references
query policy
result policyThe agent can ask Scylla to run:
SHOW FULL PROCESSLIST;or:
SELECT ...without needing to know the password used to make the connection possible.
That also creates a place to express policy.
Maybe the database account itself is SELECT only. Maybe Scylla allows SELECT, SHOW, DESCRIBE, and EXPLAIN automatically, asks before writes, and blocks schema or administrative operations. Maybe the connection only exists inside one project.
That is much more useful than treating a terminal as an all-or-nothing security boundary.
Some of the database and remote execution paths are still being completed, but this architecture is now fundamental to how I think about Scylla.
The terminal is a capability too
Integrated terminals are useful enough that I wanted them inside the workbench.
But the presence of a terminal does not mean an agent should automatically own it.
Scylla can have multiple Windows and WSL terminal profiles and sessions, with policy around whether an agent can execute commands through them. A human terminal and an agent-authorized execution path are not necessarily the same thing.
This gets especially important when protected values are involved.
If I deliberately open a human-only terminal with credentials available to it, that should not quietly become a back door around the rest of Scylla’s permission model. The terminal is another capability that needs an explicit relationship with the agent.
That principle keeps repeating throughout the application:
Connected does not mean authorized for everything.
MCP is useful, but it should not own the security model
I like MCP. It solves a real problem.
Scylla can maintain HTTP and stdio MCP connections, authenticate them, scope them to projects, expose them through agent aliases, and eventually make common services close to one-click setups.
But MCP authentication and agent authority are still separate ideas.
Connecting GitHub does not mean every project should use that GitHub account. Authenticating Linear does not mean every Linear tool should be callable without review. Connecting an MCP service does not mean the agent should automatically receive every capability that server happens to advertise.
Scylla sits between those layers.
The provider owns its account permissions. The MCP server owns its protocol and tools. Scylla still decides whether that connection belongs to this project and whether the agent can use a particular capability.
I think that separation is going to matter more, not less, as MCP becomes normal development infrastructure.
The AI provider is replaceable. The workspace is not.
Scylla currently works with ChatGPT/Codex and Claude.
That matters, but I have become much less interested in making the provider the product identity.
The model will change. The best coding agent will change. Pricing will change. People will have different subscriptions through work and at home. New providers will appear, and some integrations will turn out to be more trouble than they are worth.
I do not want Scylla’s value to disappear because a different model is fashionable six months from now.
The durable part is the workspace around the agent:
Projects
Knowledge
Chat history
MCP
Terminal
Keyring
Connections
STRATAThe provider is plugged into that environment.
That also means I do not need to become an AI reseller. Users can keep their own provider accounts and their own relationship with those companies. Scylla is the workbench around them.
STRATA changed the memory problem
Chat history is useful, but chat history is not project memory.
A conversation contains a lot of transient reasoning. A project accumulates durable decisions, implementation plans, architecture, discoveries, handoffs, constraints, and lessons that need to survive whichever agent or conversation happens to be open today.
That is where STRATA fits.
The line I keep coming back to is:
Scylla is where the developer works. STRATA is how the work remembers.
STRATA provides a local project knowledge index for human-readable material such as plans, blueprints, handoffs, and related documentation. Local STRATA belongs with the desktop workbench. Hosted synchronization can eventually make that same project memory useful across a team.
This is different from shoving the entire chat transcript into a vector database and calling it memory.
The useful question is what deserves to survive.
Scylla is not a magic security sandbox
This matters enough to say plainly.
Scylla is a control and policy layer. It is not an operating-system sandbox, and I do not want to market it as one.
Provider tools and approved commands still run with the authority available to the signed-in Windows user unless a more restrictive external boundary exists. Application policy can prevent accidental or overly broad access. It cannot make arbitrary untrusted code safe.
That limitation does not make the control model pointless.
Most security failures in normal development workflows are not movie-plot attacks. They are excessive permissions, leaked credentials, wrong-account mistakes, copied secrets, accidental context exposure, and tools being given far more authority than the task required.
Making those decisions visible and explicit is useful even when the underlying operating system remains the final authority.
And if Scylla eventually adds stronger OS-enforced isolation, that can strengthen the model without requiring the rest of the application to be redesigned around it.
Narrow is still the point
Scylla has become much larger than the little launcher I started with, but I still do not want it to become Visual Studio.
I do not need another extension marketplace. I do not need to reproduce every debugger, every language service, every remote development feature, and every project system that has accumulated in twenty years of IDE development.
I want the things I repeatedly need while working with AI agents:
a good editor
project files
chat
provider/model selection
Knowledge
MCP
terminals
credentials
remote connections
durable project memoryThat is a surprisingly useful set.
The constraint is helping the product.
Instead of asking “what does a modern IDE have?”, I can ask “what belongs in the controlled path between a developer, an agent, and the systems they are responsible for?”
That keeps Scylla opinionated.
This stopped feeling like a side project
I have been using Scylla almost exclusively for my own AI-assisted development work while building and testing it.
That was the point where my view of the project changed again.
It is one thing to build a tool because a particular security concern bothers you. It is another thing to notice that the resulting workflow is simply better.
The project grouping is useful. The isolated Knowledge layer is useful. Having chat tied to the project is useful. The narrow toolset is useful. MCP connections are useful. The Keyring and broker architecture solve a problem I expect to become much larger as agents gain more authority. STRATA gives me a place for project context that should outlive a conversation.
I started building Scylla because I did not want an AI application wandering across property I had no right to casually expose.
I kept building it because the control model produced a better development environment.
Those are different reasons, and both matter now.
Give the agent capabilities, not your workstation
That is probably the shortest version of where I landed.
An AI agent does not need ownership of my development environment to be useful.
It needs the right project.
The right context.
The right tools.
The right operations.
And, when necessary, a carefully brokered path to the systems involved in the work.
Scylla is becoming the layer where I define those things.
I still want capable AI agents. I still want them editing code, investigating failures, running useful commands, querying systems, and helping me move faster.
I just want the authority behind those actions to remain mine to grant.
That is what Scylla is for.