Quasar product guideQuasar product guide · Rev. 2 ·

Quasar product guide

What Quasar is and who it is for

Quasar is project-management software built so AI coding agents and people run the same project through the same rules. It covers issues, sprints, planning, documents, client quotes and documentation releases, and offers a REST API and an MCP server beside the web app. This chapter covers: - what problem Quasar solves; - who it fits: software teams and studios that work with coding agents, and organizations that deliver documentation and quotes to clients; - who it does not fit yet; - the principles behind it: agents as first-class users, every change recorded with who made it, safe retries, and strict tenant isolation. Read it first to decide whether the rest of the guide is relevant.

This guide describes Quasar 2026.10.15. Where a statement depends on the version, it says so.

In short

Quasar is a project-management tool for teams that build software with AI coding agents. An agent and a person work the same project: they read the same issues, follow the same workflow and are held to the same rules.

  • People use the web app.
  • Agents use the REST API and an MCP server (the Model Context Protocol, which coding agents speak natively).

Both reach the same services underneath. An agent cannot do anything a person could not, and the reverse is also true.

Beyond tracking work, Quasar carries the work to the client:

  • documents reviewed and accepted on a revision;
  • documentation published as frozen releases in PDF, Word, HTML and Markdown;
  • priced quotes built from the issues' estimates;
  • versions followed through the git repository.

The problem it solves

Most project tools were designed for people clicking through screens. An agent can be connected to them, but the tool was not built for the agent:

  • writes are not safe to retry, so a repeated call duplicates work;
  • errors do not say which rule was broken;
  • nothing distinguishes what an agent did from what a person did;
  • the agent's working rules live in a prompt nobody maintains.

Quasar starts from the opposite end. A coding agent should read and update the project state as naturally as it reads and writes code. Every person and every agent that touches a project should also be able to see:

  • what was decided;
  • what the plan was;
  • what was delivered.

Who it is for

  • Software teams and studios that work with coding agents. You plan in Quasar, your agents pick up issues, record their plan, move the work through the workflow, and log the time they spent. A person stays in charge: work sessions an agent opens become work logs only when a person confirms them, and the agent contract reserves the acceptance of documents to a person's word.
  • Teams that deliver to clients. Quasar produces client-ready material from the same data:
    • quotes priced from estimates;
    • a client-facing summary per issue;
    • documentation released as frozen, accepted revisions.
  • Organizations that need isolation and an audit trail. Every organization (a tenant) is isolated by the database itself. Administrative actions, sign-ins and changes to work are logged.
  • Teams that want to self-host. The same product runs as a hosted service or on your own infrastructure.

Who it is not for (yet)

  • Teams that need a mobile app. The interface is designed for desktop screens.
  • Teams that need the interface in a language other than English, today. The application is in English; Italian and French are next on the roadmap. Documents can be written in any language, and content templates exist in English and Italian.
  • Teams looking for a general-purpose wiki or chat. Quasar's documents are structured, reviewed project documentation, not a free-form knowledge base.

The chapter What Quasar does not do lists the limits in detail.

The principles behind it

  • Agents are first-class. Every capability is designed for the API and MCP as much as for the screen. Agent tools are workflow-oriented: one call does what a person would do in one step, and every refusal explains the rule that refused it.
  • Everything is recorded, and by whom. Each change is attributed to the person whose key or session made it, and Quasar marks when an agent acted on that person's behalf. Event logs keep the history of issues, documents and sprints.
  • Retries are safe. Every write accepts an idempotency key, so a repeated call replays instead of duplicating. Every entity carries a version, so two concurrent edits conflict instead of one silently winning.
  • Nothing is hidden. An action that cannot run is shown disabled, with the reason. A figure Quasar could not compute says so instead of showing zero.
  • Isolation is enforced by the database. Tenant separation relies on PostgreSQL row-level security, not on a filter someone might forget.
  • Built with itself. Quasar is planned, built and documented in Quasar, by AI agents working under the workflow it offers, with an architect who supervises and accepts. See Crucial points and objections.

Where to go next

  • Capabilities by area — everything Quasar does, one area at a time.
  • Working with AI agents — how agents connect and what they can do.
  • Deployment, tenancy and security — hosting options and how data is protected.
  • What Quasar does not do — the limits, stated plainly.