AgenticOS Projects: a shared AI chat for your team

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.

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.

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.

Whichever agent answers, a run in a project chat works in the project's container rather than in a workspace of its own.

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.

This is the part that makes it feel different. Several people can be in a project's chat at once.

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.

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.

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.

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.

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.

A few limits worth knowing before you plan a team around it.

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.