A chat with an AI model is a one-person thing. You ask, it answers, and then you copy the answer into Slack so the rest of the team can see it. Somebody asks a follow-up in their own chat, with half the context, and the brief you uploaded an hour ago is not in theirs.
Projects are how Vstorm AgenticOS handles work that belongs to a team rather than to one person: a launch, a monthly report, a client engagement. This article walks through what a project holds, what changes for the agents working in it, what it looks like when three people and three agents share one chat, and where the limits are. Drafted with AI assistance, edited and verified by the author.
What AgenticOS is
AgenticOS is an open-source (Apache-2.0) system for a company's AI agents that you run on your own servers. People build agents in a browser, give them documents and tools, and use them in chat, in Slack and through an API, with the model provider of their choice, including local models through Ollama. I build it at Vstorm.
What a project holds
A project is a home for ongoing work, and it holds two things every chat started in it shares.
Files, in one container. You upload a brief, a spreadsheet or a whole folder once, and every chat in the project, today's and next week's, works on the same copy. A file an agent writes in one chat is there in the next. The Files tab is a tree beside a reader that opens Markdown, PDFs, images, spreadsheets and code in place.
Instructions. Every agent answering in the project reads them after its own instructions: the tone, the deadlines, where the brand guide is. The agent is still what it is. It is just working on this.
A project also has a default agent, the one a new chat starts with. Any agent can still answer in a project chat, so the default only decides where a chat begins.
In the demo I use below, the project is called Fall launch. It holds brief.md (the launch date, the audience, a $40,000 budget and the rule that every time-saved claim needs a customer quote), channels.csv, a brand book and a checklist. Its instructions say to read those files before answering, that the budget is in US dollars, and that when a teammate replies to a plan, the agent should say whose change it applied.
What changes for the agents
Whichever agent answers, a run in a project chat works in the project's container rather than in a workspace of its own.
- An agent with no sandbox is given the project's, so a plain chat agent can read and write the project's files.
- An agent with its own sandbox is moved into the project's container. Its approval settings carry over, so an author who set Always ask on the shell keeps that gate.
- The project's name, description and instructions are added after the agent's own instructions.
When the deployment runs a sandbox service, the container is a real sandbox session, so the files can be run as well as read. That matters for the coding agent: an agent can hand a task to Claude Code or Codex, which then works in the same container, on the same files the team uploaded. I will write about that part next week.
Working in one chat together
This is the part that makes it feel different. Several people can be in a project's chat at once.
- A bar over the transcript shows who else has the chat open.
- While one person writes, the others see "Tom is typing" over their composer.
- A question one of them asks, and the agent's answer, appear for everybody in the chat as they are written. Nobody waits for a reload to see what the agent did.
- Reply works on any message, a person's or an agent's. It quotes the message above the composer, and the quote travels with the reply.
In the demo, Maya asked the Chief of Staff agent to draft the launch plan from brief.md and channels.csv. It wrote the plan into the project as launch-plan.md, laid out the first week day by day, and finished with questions it could not answer from the files: who has a customer quote, whether the referral credits apply to every sign-up, and which dates it had assumed.
Tom had the chat open at the same time. He replied to the plan: referral credits only for referrals that convert, cap Google Search at $6k and move $2k to the webinar.
Who said what
The agent is told the chat may have several people in it, and it reads each person's turn under their name. So when Tom replies, the agent knows the change is Tom's, and it knows what "yes, do that" refers to.
The Chief of Staff answered Tom by name, applied his change and the referral rule to launch-plan.md (now revision 2), asked the Finance Analyst agent to recheck the numbers, and kept the total at the $40,000 cap. Then it listed what was still open and for whom: Julia needs to say what the extra webinar budget buys, and nobody has supplied a customer quote yet.
That last part is the instruction doing its job. A plan that names whose change it applied, and leaves the decisions it cannot make to the people who can, is a plan a team can keep working on.
Each message carries its author's name and face, so a thread several people worked on says who asked what. Renaming, archiving or deleting a chat stays with whoever started it.
Sharing and permissions
A project is private to whoever created it until they share it, with the same Share dialog an agent uses: people, departments or the whole organization, each at a level.
- read lets someone see the project, its files and its instructions.
- use lets them chat in it, upload files and remove them.
- edit lets them change the instructions and the default agent, share the project and delete it.
A project's chats belong to its members. Whoever can see the project can read every chat in it, and whoever can work in it can continue them. A chat is not shared on its own by link: you share the project. If somebody loses access, their chat stops reaching the project's files on its next turn.
How the live part works
The presence bar and the live answer are a view, not the record: the transcript in the database is. Someone who opens the chat halfway through an answer gets everything so far and then the live stream. How that works across several API instances, with Redis, is Friday's article.
What it does not do
A few limits worth knowing before you plan a team around it.
- Without a sandbox service there is no shell. The project keeps its files as a stored workspace that reads and writes the same way. Two chats writing to it at once each keep what they wrote, and where both changed one file, the later write stands. The coding agent is left out of runs there, and the agent is told why.
- Questions an agent asks one person stay with that person. If the agent asks Maya to approve a step, the question waits on Maya's session. Somebody else in the room cannot answer it for her.
- It is not a document editor. The shared thing is the conversation and the project's files. Two people do not type into one message together.
- Deleting a project removes its container and every file in it. Its chats survive as ordinary chats outside any project.
Running it yourself
AgenticOS installs with Docker Compose on your own machine or server. It runs with a hosted model provider or with your own models through Ollama or an OpenAI-compatible server such as vLLM. Self-hosted does not mean every part is local: each provider, parser or tool you configure is a destination you choose.
Projects arrive in the release after this article's date. The repository and the full docs for projects:
If you try it with your team, I would like to hear which part of your work you put in a project first.
I'm Kacper, Principal Engineer and Open Source Tech Lead at Vstorm. I build AI agents and open-source tools in the Pydantic AI ecosystem. Find me on LinkedIn or GitHub.
Top comments (0)