Philosophy

Lytos exists because the dominant way of working with AI assistants — “give them a role, let them play” — doesn’t scale to real software projects. This section explains the trade-offs that shape the method, the problem we started from, and the kind of collaboration we’re aiming at.

The four pieces

Manifesto	The seven founding principles, and why we start from “project framework” rather than “agent persona”.
Sovereignty	Why the project’s knowledge — manifest, skills, rules, memory — should live in files you own, version, and migrate. Not inside a vendor.
Dev roles in the AI era	Developer, lead, trainer — what changes, what doesn’t, and how teams are actually reshaping themselves around AI-assisted work.
Trainer kit	For people teaching Lytos to teams or clients — the learning path, the failure modes, the questions worth asking.

The core trade-off

Most agent frameworks let the AI imagine itself as a developer, reviewer, or architect. Lytos asks the opposite question: what would a project need to look like for any AI — or any new team member — to be immediately effective in it?

That shift has consequences. You stop tuning prompts and start writing a manifest. You stop inventing personas and start writing skills. You stop expecting the agent to remember and start writing a memory file it will re-read every session.

It’s less glamorous. It’s also much more durable.

Where to read next

• If you want the philosophy in three minutes, the Manifesto is where to start.
• If you’re convinced and want to build, the Method section shows what that looks like in practice.
• If you want to see the method running on a real project, every .lytos/ folder in the Lytos repositories is real — not a template.