Roject is a workspace built for the
Instead of treating "chat with an AI" and "edit my project" as two separate activities, Roject merges them: the workspace you write specs, tasks, and history into is the same workspace the AI reads before it starts working, and the same one it updates when it's done.
Chatting with an AI about a project is great in the moment, but the moment usually doesn't survive: decisions, structure, and history live in a scrollback nobody reads again. Next session, you're re-explaining the project from scratch, and the AI
Roject solves this by giving every project a persistent, structured workspace - outline, boards, guides, history, reference - that both you and the agent read and write directly. Nothing needs to be re-explained because it's already there, in a form an agent can navigate on its own.
The agentic development loop is the cycle an AI agent runs on a real project: read enough of the workspace to understand the task, make the actual change (write code, edit a spec, update a board), then record what happened so the next session - human or agent - can
In Roject that loop isn't a metaphor, it's the literal file structure: outline for direction, boards for active work, history for what happened, reference for how things work. Each pass through the loop leaves the workspace a little richer than it found it.
A plain AI chat is a conversation: useful advice, code snippets, explanations - all of it living in a transcript that's
A Roject workspace turns the same kind of work into durable, structured artifacts - a task board, an updated spec page, a history entry - that both of you can navigate directly next time, instead of scrolling back through last week's chat to remember what was decided.
Roject is
Importantly, it isn't dependent on agents at all - it's a genuinely capable editor for manual work on its own, with a file browser, a media browser, a web browser, and browser-like navigation inside the page editor itself (follow a link to another page, then go back, the way you would in a web browser). None of those pieces work as well alone as they do combined: the point is one place where manual editing, chatting, and agent work all happen against the same shared project state, and you can lean on any mix of them.
A Roject workspace is a workspace/ directory full of .page files - outline, boards, guides, history, reference - each one a
Organizing information this way means both a human skimming the project and an agent parsing it can find the right piece without reading everything: the outline gives the big picture, and everything else is one link away when it's actually needed.
An AI that doesn't know your project's history, conventions, or current priorities will confidently produce answers that are
The fix isn't a bigger context window, it's better-organized context: giving the agent a workspace it can navigate to find exactly the outline, spec, or history entry relevant to the task at hand, instead of hoping everything relevant fits in one prompt.
Roject's workspace is
An agent starting a task reads the outline and the specific board or guide the task touches, not the whole workspace. A human returning after a month reads the same layers, in the same order, and ends up with the same picture the agent has.
Create a project and it starts from a index.html: an outline, empty boards, a getting-started guide tailored to the kind of project it is - software, game dev, production, research, and more. You (or an agent) fill in the outline first, then start opening tasks on the boards.
From there it's the loop: pick a task, work it with or without an agent, log what happened. The structure is there from minute one, so there's no separate "documentation phase" bolted on at the end.
Dumping a whole codebase or document pile at an AI trades one problem (no context) for another (
Roject's workspace is typed: boards are boards, history is history, guides are guides - not just files that happen to contain words. That structure is what lets an agent (or a person) retrieve the right slice of a large project instead of searching all of it every time.
A workspace is the workspace/ directory that ships with every Roject project: outline, boards, guides, history, and reference, all stored as clean, readable .page HTML files on disk. It's
Inside Roject, the same directory is rendered as rich, interactive pages: boards become kanban columns you can drag cards on, guides become linked documents with real formatting. It's a workspace in the literal sense - somewhere both you and an agent go to do the actual work of understanding the project.
A single giant document (or one enormous prompt) forces every reader - human or AI - to
Splitting the workspace into distinct areas - outline for direction, boards for active state, history for what already happened, guides and reference for how things work - means each piece can be read (or skipped) on its own terms, and each one stays a manageable size.
Roject divides a workspace by
Each area also nests: a guide's index page gives the overview, and links out to detail pages only for the parts that need more depth. A large project ends up as a tree of right-sized documents instead of one document that keeps growing forever.
Tasks and bugs on kanban boards, specifications and design notes, mockups and reference images, session history, onboarding guides, architecture references, even notes for a theatre production's prop list or a game's enemy roster - the .page format is
Because pages support typed blocks - lists, images, code snippets, headings - a workspace can express a lot more than prose: a task board is a real board, not a bullet list pretending to be one.
A specification for a feature, a level, or a scene is just another page in the workspace - usually linked from the outline or a board, so anyone (or anything) starting related work
Because it's a real page, a spec can carry structure the whole way through: a task board next to it tracking implementation status, a history entry recording when it changed and why, images or code blocks illustrating the design directly alongside the prose.
Because the workspace is
This is also how a Rojo's own "entry point" works: a project-focused Rojo can start already anchored to a specific reference page, so every session begins scoped to the right part of the workspace instead of the whole thing.
Instead of always starting from the workspace root, a Rojo (or a human) can be configured to start from a specific page - a guide, a board, a reference doc - and treat that as
This matters because it changes what "relevant" means by default: a Rojo entering through a game design outline behaves differently from one entering through a backend reference doc, even inside the exact same project, simply because of where it started reading.
History entries record what was built, when, and why - including decisions that didn't make it into any spec because they were made in passing. An agent reading history before starting work
Tasks and boards do the same for current state: an agent can see what's already in progress, what's blocked, and what's already done, instead of duplicating work or contradicting an approach already underway elsewhere in the project.
Every area of the workspace follows the same shape: a short, compact index page gives
Readers - human or AI - are expected to read the index layer fully, then follow only the links relevant to what they're doing. Nobody has to read every detail page just to understand what a part of the project is for.
Because everything is
That's true for a human skimming a project they haven't touched in months, and it's true for an agent deciding what to read before starting a task - both move through the same structure, just faster or slower depending on how much context they already carry.
An agentic loop is the
Roject is built around making that loop sustainable across many sessions, not just one: because each pass writes back into the same structured workspace, the next loop - run by the same agent, a different Rojo, or a human - starts from where the last one actually left off.
The agent starts by reading whatever part of the workspace the task points to - a board entry, a spec, a guide - to understand what's being asked and what already exists. From there it moves into the multi-panel editor and makes
The key is that "understanding" and "changing" happen in the same environment against the same files, so there's no lossy translation between what the agent read and what it acts on - it edits the very documents it was reading.
At minimum: the outline for
Roject's convention is deliberately "read the first layer, then follow links only as needed" - an agent that reads the compact overview pages first rarely needs to read much else before it has enough to start.
Because pages link to each other - a task references a spec, a spec references a guide, a guide references a reference doc - an agent can discover what it needs by
When following links isn't enough, the workspace is also just a real file tree, so an agent can search or browse it directly - but the linked structure is what usually gets it there faster than a blind search would.
Feeding an agent an entire project up front doesn't make it smarter - it makes the truly relevant information harder to find inside all the noise, and it
Retrieving smaller, targeted pieces - the one board, the one guide, the one history entry that actually matters - keeps the agent's attention on what's relevant and leaves room in context for the actual work: reading code, reasoning about a fix, drafting new content.
A specification written as a workspace page gives an agent
Because the spec lives in the same workspace as the code, the agent can keep both open at once, checking its work against the spec directly rather than relying on memory of a conversation from earlier in the session.
Finishing a task isn't just closing it out - it's expected to
In practice a session typically ends by running an action like "Update History": it writes the day's history entry, updates whatever reference docs actually changed, and commits (and pushes) the result. That trace is what makes the next loop faster - whether it's the same agent next week or a different one entirely, reading the board and recent history is what lets a new session start already caught up, instead of starting cold.
Usually it just follows another link - opens the reference doc a guide pointed to, checks a related board, reads further back in history. The workspace is designed so most gaps can be closed by navigating
When that's not enough - the missing information only exists in someone's head, or requires a judgment call - the expectation is that the agent stops and asks, rather than confidently filling the gap with a guess. Roject's own contributor guides bake this in as a standing rule.
Directly, in the moment - the human can redirect an agent mid-task the same way they would a colleague, by pointing out a misread requirement or a wrong assumption. Roject encourages
Because the workspace is shared, a correction can also be structural: editing the guide or spec the agent misread, so the fix benefits every future session, not just the current conversation.
Every session adds to the
Over weeks or months, the workspace becomes a genuine project memory - richer with every session rather than static - which is exactly the target audience: sustained projects, not one-shot "generate me an app" requests.
A Rojo is a named,
You can have several Rojos in one project, each suited to a different kind of work, and switch between them the same way you'd switch tabs.
Mostly yes, with the important part being "configurable." A Rojo bundles an underlying AI agent together with a
That bundling matters because it means the same underlying model can behave like several distinct collaborators depending on which Rojo you're talking to, each with its own accumulated context and habits.
A Rojo scoped to one codebase and anchored to its reference docs will behave very differently - and more usefully, for that codebase - than a generic assistant with no starting point. Creating separate Rojos
It also keeps memory clean: a Rojo's corrections, guides, and history are its own, so teaching one Rojo project-specific conventions doesn't clutter or confuse a completely different Rojo working on something else.
Visually: a Rojo has its own appearance (built from a
That entry point does more than hand over knowledge, though - it programs behavior too. The same starting prompt or read-up page can teach a Rojo which actions or skills it's allowed to reach for and when, to actively watch for and flag corrections instead of guessing past them, how much thinking or reasoning a task deserves before it acts, and how it should talk to you along the way. Its accumulated memory - corrections, guides, session history - is also per-Rojo, so each one develops its own track record over time.
A Rojo anchored to a specific reference page, guide, or project starts every session
That doesn't wall it off from the rest of the workspace; it can still navigate anywhere a link (or a search) leads. But "what it can do" isn't only about knowledge either - the same entry material can program behavior: which actions it reaches for on its own, whether it treats an unexpected user message as a correction worth logging, and how it's expected to interact with you along the way.
A project-anchored Rojo begins every session
Neither is strictly better - a generic Rojo is the right tool for a quick question with no project baggage, while an anchored one is the right tool for sustained work on one specific thing.
Create a project-focused Rojo when you're doing sustained work on one codebase or project and you're tired of re-establishing context every session - a Rojo anchored to that project's reference docs
It's also useful when a project has real conventions worth enforcing consistently - a project-focused Rojo that's read the guides once tends to keep applying them, session after session, more reliably than re-explaining them each time.
A generic Rojo is
It's also a reasonable default when you're not sure yet whether a topic deserves its own project-focused Rojo - start generic, and create a dedicated, anchored Rojo later once the work has settled into something worth building sustained context around.
Each Rojo's model is
Local models can connect through Roject's tunnel.rokojori.com bridge, so a fully local, private Rojo and a cloud-backed one can sit side by side in the same project without either setup interfering with the other.
Ask two things: does this task need project-specific context, and does it need a powerful model to do well? A quick generic question needs neither - reach for a generic Rojo. Sustained work on a specific project benefits from an anchored one that
Model choice follows the same logic: reserve a powerful (and possibly costlier) model for work that actually needs the reasoning power, and let a lighter local model handle routine, low-stakes questions where speed and privacy matter more than raw capability.