Core concepts

The handful of terms that run through every screen on Quodara: apps, resident agents, chats, the app main version, test and production.

Get these straight once and the rest of the platform stops needing explanation.

App

An app is a project you want AI to build and operate for you. Every app comes with four things:

A code repository — where the agent actually edits code. Quodara can create one, or you can bring your own GitHub repository.
A resident agent — a cloud execution environment that clones the code, understands the request, makes changes, commits, and triggers deployments.
Two environments — test and production, each with its own domain, database and configuration.
Runtime configuration — domain, database, object storage, logs and monitoring, injected per environment by the platform.

Your apps live on the Apps page, which has three tabs: Mine, Collect and Board.

Resident agent

The agent is not a code-completion model. It works inside a real container: it can read and write repository files, install dependencies, run commands, inspect logs, generate images and video, and call the skills and MCP servers you have installed.

You never deploy the agent yourself — it is provisioned when the app is created. Every message you send in a chat is executed by that app's agent.

Chat

A chat is an ongoing conversation with the agent, and it is the only way work gets done on Quodara.

Each chat is bound to one app, chosen in the composer
Before it starts, a chat branches off the app main version into a temporary branch, and all edits happen there
A chat can run for many rounds; the context carries over
Four statuses: Queued, Running, Done, Stopped — the list on the left can be filtered by them

The first sidebar item, new chat, starts a new conversation. Recent chats sit below it, with Recent / Collect tabs. Chats do not have to be started by hand either — a scheduled task creates one for you when it fires, see 08-schedule.md.

App main version

The app main version is the default branch of the repository, usually main. Production ships from it, but it is not necessarily what is live right now:

A chat's edits reach the default branch only when you click Merge into the app's main version
The default branch reaches your production domain only when you click Publish
So the live version is whatever state of the default branch was last published, which may lag behind the newest commit

If you know Git, treat the app main version as your main branch.

Concept	Git equivalent
App main version	the `main` branch
A chat's branch	a temporary `chat/xxx` branch
The live version	the commit on `main` that was last published

Test and production

	Test	Production
Triggered by	Preview under a chat message	Publish under a chat message
Domain	a `test.` subdomain	your real subdomain
Database and storage	isolated from production	isolated from test
Audience	you, verifying	the public
Indexed by search engines	no, crawling is fully disabled	yes

The two environments share no data. Anything you create while testing stays in the test database.

Everything else

My skills — capability packs that teach the agent how to handle a class of task
My MCP servers — external tool services the agent can call
Marketing channels — your positioning and per-platform profiles, used whenever the agent writes marketing content
OKR and To-dos — your goals and loose ends, which the agent takes into account
API keys — tokens for calling the Quodara API
Store — plans and redeem codes

All of these live in the feature list on your profile; the sidebar no longer lists them individually.

One diagram

   you ──a request──► Chat (temp branch)
                        │
                        ├─ Preview ──► test environment (test domain)
                        │
                        └─ Merge ──► default branch ──Publish──► production