Inspiration

I started AOPS after using AI agents on real development projects. Agents were fast inside one chat, but a new session often started almost from zero. Plans were in one place, notes were somewhere else, and useful decisions disappeared inside long conversations. I wanted agents to have a project they could return to, not only a prompt.

What it does

AOPS gives agents shared project management, memory, chat, documents, versioned prompts and skills. An agent can start from a task, create an implementation plan, work through a sprint, save a checkpoint, request a review and hand the next action to another agent. Later, the project can continue from a short resume pack containing the useful context, decisions and evidence.

How we built it

AOPS is mainly written in TypeScript. The server runs on Node.js and SvelteKit, while aops-cli is a Node-based command-line application. AOPS Cockpit is built with React and Vite. PostgreSQL stores project plans, memory, documents, versions and other shared project data. The project is organized as a monorepo with separate domain packages. Domains such as Projectman, Agentspace, Docman and Fileman follow a hexagonal architecture and can be loaded through the hosted plugin system. This keeps the system expandable without putting everything inside one large application. The first versions of AOPS were developed in a private repository. When I decided to publish the Community Edition, I created a separate public repository and moved the publishable parts there. This required dependency cleanup, security reviews, reproducible builds and reliable CI workflows. I used Codex Desktop during almost every stage of development. It helped me understand a large codebase, implement features, run tests, find security issues, prepare documentation and continue long development sessions. I also used AOPS to build AOPS itself. Tasks, implementation plans, decisions, reviews, memory checkpoints, documentation and handoffs were managed inside the system.

Challenges we ran into

The biggest challenge was turning an existing system into a safe Community Edition. AOPS was already a large working project, but publishing it was a different kind of work. I had to separate community code, remove private assumptions, review dependencies and close security gaps. The CI and release workflows also needed to be reliable, fast and repeatable. Codex 5.6 helped me a lot during this process. It found security issues I had never thought about before. I reviewed these findings one by one and fixed them before the release. This was one of the most useful and surprising parts of the project. Another hard part was keeping one source of truth while supporting the CLI, APIs, agent tools and an optional UI. Multi-agent work was another challenge. Agents need to chat, discuss ideas, reach consensus, request reviews and continue each other's work without losing the project history. I also did not want AOPS to force one development method. It includes ready-to-use working disciplines, but every tool can also be used separately. Users can build their own workflow and save it as a versioned skill. AOPS is still growing. Community domain onboarding and broader authentication and RBAC support are still in development. My goal is to keep it practical, flexible and useful for both people and AI agents.

Accomplishments that we're proud of

AOPS grew from a personal tool into a working, self-hostable system with a CLI and an optional Cockpit. Its biggest achievement is project continuity. Agents can plan work, save checkpoints, request reviews, hand off tasks and resume later without reading the full chat history.

AOPS was also used to build itself. Its tasks, decisions, documentation and memory were managed through AOPS, which helped test the system on a real project.

Build Week gave me the motivation to turn the private project into a public Community Edition. With Codex 5.6, I found and fixed issues I had missed, especially around security, dependencies, packaging and release workflows. I also prepared open-source licensing and automated CI checks, making the Community Edition cleaner and more reliable.

AOPS was originally built for my own needs. I am now happy to share it as a free and open-source project. I hope it becomes useful to other developers and continues to grow with ideas and contributions from the community.

What we learned

The biggest thing I learned is that AI development is not only about writing better prompts. Agents also need continuity, clear ownership and a way to show what happened. Memory should not mean saving every conversation. Short checkpoints, durable notes and useful references are much better. I also learned that chat is good for coordination, but decisions and reviews need their own permanent records. This project also taught me a lot about open-source licensing, source distribution and dependency notices. These were areas I had not worked with very often before. While preparing the Community Edition, I learned more about continuous integration, automated tests, release checks and GitHub Actions workflows. I built workflows to check the source, test the project and make releases safer and more repeatable. This part of the project was new for me and became an important learning experience.

What's next for AOPS - Agentic Operations System

The next major step is team mode with authentication and role-based access control. Users will be able to share a project and work together through the same AOPS server.

Access control will not be limited to human users. It will also define what each agent can see and do inside a project. For example, a planner agent may create plans and tasks, an implementation agent may work on assigned tasks, and a reviewer agent may approve work or request changes. Roles and permissions can control access to memory, documents, project management tools and other operations.

I also want to grow a community catalog of working disciplines, skills and prompts. AOPS will provide useful starting points, but users can improve them, create new development methods and share practices for different projects and codebases.

File snapshots are another important area. They can support rollback, backup, comparison and distribution of verified project states.

The long-term vision is more experimental. I want to explore remote product development where hundreds, and perhaps one day thousands, of specialized agents can work on the same project through AOPS. Some agents could plan roadmaps and sprints, while others implement features, review code, test releases, maintain documentation, monitor security or manage project memory.

AOPS would act as their shared operations layer, coordinating responsibilities, permissions, handoffs, reviews and project history. This is still a long journey, but I hope AOPS can grow together with real users, new agent capabilities and community contributions.

Built With

Share this project:

Updates