Forge Sites now composes Build, Identity, and AI around one exact-source application release. Build produces the immutable release. Identity can attach an app-scoped principal. AI can attach a bounded server-side inference profile. One forgeBuild.ts declaration requests the three capabilities without merging their credentials, authorization, runtime, or availability contracts.

The 523-route AI Engineer migration is the clearest production case study: three independently deployable applications retained one public URL surface while routing, assets, releases, and rollback stayed explicit.

A builder making a collaborative tool had previously encountered three different Forge products where the application expected one path. Hosting produced a release, Identity lived in a separate manual, and AI appeared as another product surface. The UI described Forge's organization chart instead of the route from source to a working application.

The straightforward product change was composition, not a services grid. A grid would have made Build, Identity, AI, and Agent look like interchangeable add-ons even though they have different trust boundaries and availability. Forge Sites instead treats Build as the release foundation and attaches Identity and AI as optional capabilities. All three are available in Alpha under those constraints; Forge Agent remains a roadmap item because its end-user authority and rollback contract do not exist yet.

One application had to cross three product surfaces

Forge Sites first read like hosting infrastructure. The repository UI emphasized deployment, Identity lived in a deeper manual, and AI appeared as a separate product card. Each surface was defensible on its own, but the set obscured the application workflow:

exact source commit
  -> immutable application release
  -> optional app-scoped identity
  -> optional bounded server-side AI

That framing matters to application builders. A dashboard or collaborative tool should not build a new account system merely to recognize a visitor. An application should not ship a provider key merely to summarize a result. Both capabilities belong near the release that uses them.

The tempting mistake was to present the services as peers in a product grid. That would imply that they share a trust model and availability level. They do not. The useful unit is a composed release, not a bundle of interchangeable features.

One declaration composes three services

The repository remains the composition surface. forgeBuild.ts declares the build and the narrow capabilities the application requests:

export default defineForge({
  version: 1,
  name: 'team-room',
  build: {
    command: 'pnpm run build',
    workingDirectory: '.',
  },
  app: {
    entrypoint: 'dist/server.js',
    assets: { directory: 'dist/client' },
    identity: {
      scopes: ['user:basic'],
    },
    ai: {
      profiles: {
        explainResult: {
          model: 'forge/text-fast@1',
          audience: 'server',
          funding: ['host'],
          maxInputTokens: 2_500,
          maxOutputTokens: 220,
          privacy: { contentLogging: 'off' },
        },
      },
    },
  },
  routes: [
    { pattern: '/assets/*', to: 'app.assets' },
    { pattern: '/*', to: 'app.http' },
  ],
});

This file is policy, not a bag of credentials. Forge evaluates it from an exact commit and binds the result to an immutable release. A successful smolforge deploy check proves that the declaration parses. It does not prove entitlement, provisioning, activation, or a working user-facing route.

The boundaries are easier to see as a contract comparison:

What each Forge Sites service gives the application, what Forge keeps, and its current availability.

Service	Application receives	Forge retains	Availability
Forge Build	An immutable release and preview	Build policy, publication controls, evidence, and rollback pointer	Alpha
Forge Identity	An app-specific principal and approved claims	Control-plane session, signing material, and directory access	Alpha; deployment-specific runtime
Forge AI	A named server-side model capability	Provider credentials, routing, admission, and usage enforcement	Host-funded Alpha
Forge Agent	No runtime	No public contract exists to grant authority	Roadmap; not available

The common declaration reduces configuration drift. It does not merge these trust boundaries.

Identity supplies a principal, not permission

Forge Identity lets a Site recognize a person without giving repository code that person's Forge control-plane session. The smallest scope, user:basic, provides an application-specific random ID and a small public-profile snapshot. accounts:read and teams:read add membership context only when the product requests it.

The application never receives the Forge bearer token, session-signing secret, email address, or an unrestricted organization directory. Native and connected deployments also have different delivery paths, so “Identity is available” does not mean every hosting model injects it in the same way.

This boundary stops at recognition. A game may associate the principal with match history, but the game still decides who can join, move, resign, or moderate. The trusted runtime must bind the authenticated principal to every state-changing request. Product authorization remains product-owned.

AI supplies inference, not agency

Forge AI follows the same composition rule with a different contract. The repository declares a logical server-side profile with token ceilings, privacy policy, funding, and cost limits. Forge owns the private binding, provider credential, routing, admission, and usage enforcement.

Application code still validates the result and keeps a safe fallback. In the current Alpha, Forge can parse requested JSON output, but the application must validate it against product rules. AI must not become the source of truth for permissions, prices, scores, or other deterministic state.

This is why Forge AI does not imply Forge Agent. Model inference is a bounded server capability. Acting for an end user requires scope, approval, progress, cancellation, audit, and rollback. Calling both features “AI” would erase the most important design difference.

The Agent fence is a product requirement

Forge already has a repository agent in its control-plane UI. It operates in repository context. The proposed Forge Sites Agent is different: it would let a Site's end users request bounded personalization, such as arranging a dashboard or generating user-owned configuration.

Before that service can ship, an application must define what a request may read and change, whether a person approves the result, how much time and compute it may use, and how to preview, reject, cancel, audit, and undo it. It must not expose repository administration, arbitrary source writes, account authority, provider credentials, or production deployment controls.

That missing contract is why the shared product model marks Agent as roadmap; not available. Showing the direction is useful. Presenting it as a current peer would claim a safety boundary that has not been designed or implemented.

The source proves composition, not every runtime

Commit 1251a9f added the shared four-service model, the services overview, and its landing-page, repository, and docs integrations. Merge 6d76564 brought that change into the main release line. The current source still defines three current services and one fenced roadmap service, and focused tests assert those names, links, configuration paths, and availability states.

That evidence proves the product model and its implementation surfaces. It does not prove every binding-dependent Identity or AI path for every deployment model. Those need separate release and browser checks: activate a release, verify the trusted principal on a state-changing request, exercise revocation, then repeat the process for an admitted AI profile and its fallback.

Forge Sites now presents Build, Identity, and AI as one application path while keeping the authority of each attachment visible. “Works together” does not mean “inherits everything.” The next proof is an end-to-end Site that exercises the composed release through activation, identity revocation, AI failure, and rollback.

The detailed contracts live in the Forge Sites services map, Forge Identity v1, and Forge AI v1.