Introducing connic apps: Host the Frontend for Your AI Agents

Today we are shipping connic apps, hosting for the frontends of AI agents. A chat window, a review inbox, or a customer portal now lives in the same project as the agents behind it, ships with the same deploy, and can sign people in before the first file loads.

One project for the agents and their frontend

Sooner or later, an agent needs a screen that people use: a chat on a website, an inbox where someone approves what the agent wants to do, a portal where customers upload documents and follow the result. Until now, that screen lived outside connic. It needed hosting of its own, a backend that kept API keys out of the browser, a login, and a deploy pipeline of its own that could drift out of step with the agents.

With apps, the frontend moves into the project. It ships with the same deploy as the agents, gets its own URL in staging and production, and rolls back together with the agents it calls. A connic project now holds the agents, the connectors that start them, the data they keep, and the screen people use.

What you can build with apps

An app has your own design, built with the framework your team already uses. Its data and answers come from the agents and storage in the same project. The mockups below show three apps for fictional companies.

A claims portal for an insurer

Policyholders report water damage, upload photos and the repair invoice, and follow the claim while an agent assesses it. They sign in with the insurer's customer login, and each of them sees only their own claims.

Contract review for a legal team

Lawyers upload a contract and get findings per clause, rated by risk and saved to the database. Follow-up questions go to the agent in a chat next to the document.

An ops console for the agents themselves

The operations team sees run volume, failures, and pending approvals across all agents, and cancels runs that are stuck. The app reads the environment's run stats through the data API. The team signs in with the company login and needs no connic account.

Declare an app next to the agents

Each app is a YAML file in apps/ plus a folder with its sources. The file name is the app's key: apps/portal.yaml builds from apps/portal/.

my-agent-project/
├── agents/
│   └── support.yaml
├── connectors/
│   └── portal-chat.yaml
└── apps/
    ├── portal.yaml          # the app's settings; the file name is its key
    └── portal/              # the app's sources
        ├── package.json
        ├── package-lock.json
        └── src/

Vite with React, Vue, Svelte, or Solid works, and so do Angular, Astro, SvelteKit, Nuxt, and other frameworks that build static files. On every deploy, connic installs the dependencies from the lockfile, runs the build command, and serves the output. Server rendering and API routes don't run; agents and the data API do that work.

The app file says how to build the app, who may open it, which agents it can call, and which data it may touch:

name: Support portal
build:
  command: npm run build
  output: dist
auth:
  mode: oidc
  issuer: ${PORTAL_ISSUER}
  client_id: ${PORTAL_CLIENT_ID}
  client_secret: ${PORTAL_CLIENT_SECRET}
  allowed_domains: [example.com]
connectors:
  - portal-chat
access:
  database:
    tickets:
      read: doc.author_id == user.id
      insert: true
      set:
        author_id: user.id

Each environment gets its own app with its own address, such as https://portal-1a2b3c4d.connic.app. An environments block can give each environment its own sign-in and domain, for example connic accounts in staging and the company login on portal.example.com in production. When a build fails, the deploy fails with it and the active deployment keeps serving the last good version. Every deployment keeps its own build, and a rollback brings the older frontend back together with the older agents.

Sign-in without an auth backend

Every app has one of three sign-in modes, set in the app file or on the app's Settings tab in the dashboard, where a change applies without a deploy:

On apps that require sign-in, connic checks the session before it serves any file. Not even the app's JavaScript reaches someone who isn't allowed in. Sessions last up to 12 hours. For connic accounts, connic checks project membership and permission groups again every ten minutes, so removing someone from the project ends their access within minutes.

Call agents straight from the browser

The browser reaches agents through connectors on the app's own host. A sync webhook or WebSocket connector with apps_only: true accepts requests from the apps that list it and from nothing else. The app's code contains no secret or API key. With streaming on, a chat shows the reply while the model writes it:

type: websocket
apps_only: true      # only apps that list this connector can reach it
config:
  streaming: true
agents:
  - support

connic attaches the visitor to every run the app starts: their ID, email, name, and groups land in the run context, set by connic from the request and never from the message. An agent can look up the visitor's orders by email, or connect each person's own account to an MCP server through per-user sign-in.

Access rules decide what each visitor sees

Many screens only show data: a list of tickets, the files a customer uploaded, the runs someone started. They should not wait for an agent run. The data API gives the browser the database, files, runs, sessions, and approvals of the app's environment, plus search over Retrieval namespaces. These requests read and write directly and never start an agent run.

In this IT desk, an employee and the IT team send the same request and get different answers:

The access block in the app file makes that happen, with one rule per resource and operation:

access:
  database:
    tickets:
      read: doc.author_id == user.id or "it-support" in user.groups
      insert: user.signed_in == true
      set:
        author_id: user.id

connic adds the rules to the query itself. Lists, counts, updates, and deletes therefore only touch records the rules allow. Anything without a rule is denied. set stamps the author on every insert, whatever the browser sent. A rule that connic can't enforce fails the deploy, and every write lands in the audit log with the app and the visitor.

Example: a refund approval inbox

A support agent proposes refunds and has to wait for an approval before it pays one out. The finance team decides in a small app of its own, with the order, the amount, and the customer's reason next to the buttons:

Members of the Finance permission group sign in with their connic account and may decide refunds below 5,000. The app can't decide larger ones; they need a decision elsewhere, such as in the dashboard. An approval resumes the waiting run.

name: Refund approvals
build:
  command: npm run build
  output: dist
auth:
  mode: connic
  groups: [Finance]
access:
  approvals:
    read: '"Finance" in user.groups'
    decide: '"Finance" in user.groups and approval.tool == "issue_refund" and approval.params.amount < 5000'

Build the app locally with connic dev

connic dev builds every app locally and serves it at its URL in the dev environment, running against the agents of the dev session with the same sign-in, connectors, and access rules as after a deploy. Saving a source file rebuilds the app. When a build fails, the last good build stays live until the next one succeeds.

Custom domains, stats, and connic MCP

Every app answers on its connic.app address. A verified custom domain of the project can serve it as well, set in the app file or in the dashboard. Once the connic.app address is switched off in the dashboard or through connic MCP, it redirects to the custom domain. Old links keep working, and search engines index only the custom domain.

The Apps page in the dashboard lists every app of an environment with its URL, its sign-in, and the last seven days of visitors, views, sign-ins, and data requests. An app's details add 30 days of stats, with failed sign-ins and denied requests counted separately, and show the access rules that are deployed. Coding agents get the same through connic MCP, which can also change an app's domain and sign-in.

Availability

Apps are part of the pro and enterprise plans. On pro, each environment serves up to 5 apps, each with up to 25 MiB of build output. Enterprise plans can set other limits. Runs that an app starts are billed like any other agent run. Pricing compares the plans.

Get started

1. 1

   Update the composer SDK. Version 0.1.59 or later includes apps and every access rule this article mentions:

   Copy

   pip install --upgrade connic-composer-sdk

2. 2

   Add the app. Create apps/<key>.yaml and put the frontend in apps/<key>/ with its package.json and lockfile. For agent calls, add a connector with apps_only: true and list it under connectors.

3. 3

   Run connic dev. Install the app's dependencies first, for example with npm install in apps/<key>/. Then open the URL connic dev prints and edit the app. Every save rebuilds it.

4. 4

   Deploy. connic deploy builds the app together with the agents, and the Apps page shows its URL. The apps docs cover every setting.