Concepts

Every project lives at a unique subdomain (e.g. myshop.coagentic.site) and gets its own database, file system, integration credentials, and workflow registry. Projects don't share data with each other — a customer table in one project is invisible to another.

That subdomain is also the project's email identity: it sends mail as [email protected] by default (each project sends as itself), and can upgrade to a dedicated myshop.coagentic.site domain for noreply@ addresses.

You can have many projects in one workspace (a Pro plan keeps it unlimited). Each project groups its dashboard into Overview, Site (files, media, database, branding, analytics), Team, Email, Automation (workflows, integrations), and Activity (drafts, approvals, runs, submissions).

Projects start in draft, move through building → deploying → live. Toggle Live in Overview to expose the public URL.

The agent is fronted by a chat panel (Ctrl+. on Windows / Linux, ⌘+. on macOS) and backed by a hybrid LLM — a fast variant for routine tool calls and a deeper reasoning variant for code generation and planning. The platform's current provider is named in the sub-processor list; the dual-variant routing is provider-agnostic. Each user prompt becomes a series of tool calls executed against your workspace.

Talk to it in whatever language you like — Turkish, English, or anything else. It detects the language of your latest message and replies in it, and follows you if you switch mid-conversation. (Tool names, code, and identifiers stay as-is.)

Tools fall into a few buckets: project lifecycle (create_project, delete_project), files (write_file, read_file), database (provision_database, create_table, add_column, insert_row), integrations (connect_integration), workflows (create_workflow, update_workflow, delete_workflow — including branching graphs), and the customer-facing site assistant (create_assistant, add_knowledge).

Every tool call shows in the panel as a card you can expand. Inputs, outputs, and errors are persisted to the project's audit log — you can replay what the agent did days later.

Built on a drag-and-drop canvas (Automation → Workflows → open a workflow). Drag nodes from the palette, connect their handles, and double-click any node to configure it. A condition node branches on two outputs — green (true) and red (false) — so you can build real if/else and parallel flows, not just a straight line. It runs as a DAG: each node fires once its incoming path resolves.

Seven trigger types: webhook (external HTTP, HMAC-SHA256 signed via X-Coagentic-Signature), integration_event (another service calls in, signed the way THAT service signs — you describe the scheme), form_submit (HTML form on your site), cron (5-field schedule), db_change (row inserted / updated / deleted), analytics_threshold (traffic crosses a target), and inbound_email. Actions include send email / SMS / WhatsApp, insert / update / query / delete a row, HTTP request, checkout / refund, and more.

Everything is configured on the canvas — the trigger (incl. its webhook URL + secret), each action, and each condition — by double-clicking the node. Full execution history is under Automation → Workflows. The assistant can build and edit the exact same graphs for you (create_workflow / update_workflow).

Common shapes: confirmation email on order; if order total > 100 alert the owner by SMS, else just log it; abandoned-cart reminder cron; daily inventory check.

Each project provisions one database the first time you ask the agent for one (or directly via Site → Database). You add tables and columns from the agent or the UI. Schema changes are non-destructive — adding a column starts existing rows at null, removing one drops the column data.

Rows are queryable from three places: the dashboard (browse, insert, delete), the agent (it inserts when site forms submit), and your workflows (read or write rows when triggers fire).

Your SITE reads it too, and that is what makes a starter template a working site rather than a brochure. There are 54 of them — bakeries, breweries, solicitors, electricians, campsites, podcasts, job boards, a shop, a blog — grouped by the kind of business rather than by the kind of page, because nobody goes looking for "a landing page". Search the picker for what you do and preview any of them before you commit; the preview shows the real page with its real content in it.

Every template ships wired to its own tables — the shop's products, the blog's posts, the restaurant's menu, the solicitor's practice areas, the campsite's pitches — so changing a price or publishing a post is editing a row, never editing HTML. The tables arrive with content in them, so the site looks finished on day one. Each table also says what the site may do with it: a menu is readable by anyone, while reservations, orders, subscribers and waitlists are write-only, because they hold names, emails and addresses that must never be readable from the street.

Data is yours: export the whole workspace (rows + schema + files + integrations) as a JSON archive any time from Settings → Backup & export. No vendor lock-in.

A project can let its visitors register and sign in. These are your customers, not Coagentic users: they have no dashboard, no workspace and no access to anything of yours — a site account exists only on the site it was created on, and the same email on two of your projects is two separate accounts, because a bakery customer should not be identifiable to your photography studio.

Your pages call /auth/register, /auth/login, /auth/logout and /auth/me on their own address. The session is an http-only cookie, so page code cannot read it and a stolen script cannot forward it. Sign-ups and sign-ins are rate-limited per IP, sign-in never reveals whether an address has an account, and blocking a customer signs them out immediately rather than at the end of their session.

In the Database tab, a public table has a switch: **each customer sees only their own rows**. Its public endpoints then stop meaning "anyone may read this" and start meaning "a signed-in customer may read and write their own rows" — the server stamps the owner on insert and filters every read by it, so an orders table becomes an order history rather than a published order book. The owner column is the server's: a visitor cannot claim somebody else's rows by sending it, cannot fetch one by guessing its id, and is not even told how many rows exist that are not theirs. (site_user_id is reserved for exactly this reason — you never declare it, and the switch is how you ask for it.)

Site → Customers is where you see who has an account: their name, when they joined, when they last signed in, and a Block button. Blocking signs that person out everywhere immediately and shuts them out until you unblock them; their rows stay where they are. Your assistant can read the same list, but blocking a named person is yours to press — an agent may recommend it and cannot do it.

This is what makes a members' area, an order history or a paid tier possible on a site you built here — the pieces the SaaS starter template needs to become an actual SaaS.

Voice is not a second bot. The agent you already hired takes the call with the same briefing, the same knowledge base, the same tables and the same permissions it uses on your site — because a business whose phone and website disagree is worse than one with no phone line.

Bring your own voice platform. Vapi, Retell, Bland, Twilio with anything on top — you keep your account, we take no margin on your minutes, and moving provider is changing one webhook. Point it at /voice/<project>/turn with the secret from your project's voice settings; it sends what the caller said and speaks what comes back.

Every caller hears, first, that they are speaking with an AI assistant and not a person. That line is spoken before anything else on every call and there is no setting to turn it off — it is what the law requires of an AI voice and what anyone picking up the phone deserves. What you choose is the greeting that follows.

The whole call is recorded as one conversation you can reopen, and if your agent could only queue something for your approval, the caller is told that rather than promised it was done.

And the room shows it. An agent on a live call is drawn at its desk as **on a call** — hover it, open its card, and that is what it says. It is the strongest claim the office makes about anybody, because it is the only state with a person waiting in real time: it outranks even work waiting on your approval. When the caller hangs up, the agent goes back to whatever it was doing.

Every project can ship a public site assistant. You feed it a knowledge base (text, URLs, files), set the tone in a system prompt, and it answers visitor questions in your brand voice — automatically in each visitor's own language, whatever they write in. (The opening greeting is a fixed string you set, so translate that yourself if your audience isn't English-speaking.)

Distinct from the builder agent: the builder agent has full workspace tools and operates on your behalf; the site assistant is read-only against your knowledge, can't edit your project, and lives behind the chat widget your visitors see.

Conversations are logged to the project, so you can review what your assistant said and patch the knowledge base if it got something wrong.