# LaunchLayer Project Agent

Canonical page: https://launch-layers.cloud/help/project-agent
Last updated: 2026-10-02

LaunchLayer gives each project its own AI assistant. The agent is designed to answer questions from current LaunchLayer project evidence and to prepare narrowly allowlisted fixes without receiving unrestricted production write authority.

## Project isolation
Each user message receives an authoritative project ID and a short-lived server-issued scope token. The token is bound to the authenticated user and exact project. Agent context and proposal calls for a different project are rejected server-side. A project ID or token typed into chat does not override the authoritative scope.

## What the agent can answer
The agent can explain LaunchLayer and inspect safe project metadata plus recent source-inspection, build, deployment, QA, compliance, rejection, store-connection, native-feature, artifact, and release-autopilot evidence. Project-specific factual answers are instructed to consult current evidence before responding.

## Guarded local-setting proposals
When explicitly asked, the agent can prepare reviewable proposals only for:
- project name
- app name
- app version
- build number
- GitHub branch
- target platforms

A proposal shows current and proposed values, expires automatically, and cannot apply itself. Applying it requires explicit user approval in LaunchLayer and a server re-check that the original values have not changed.

## Guarded release repair
LaunchLayer can preview and, after explicit approval, execute the allowlisted stale local release-state reconciliation. Proposal and state fingerprints are revalidated immediately before execution. Other failure categories remain guidance-only until a bounded verified executor exists.

## What the agent cannot directly change
The agent cannot directly change bundle IDs, Android package identity, signing material, provider credentials, store-review decisions, arbitrary source/native code, binaries, provider-side records, or start paid builds or binary uploads.

## Abuse controls
Server-side limits are enforced independently of the UI:
- 40 agent messages per hour per user/project
- 150 agent messages per day per user/project
- 80 project-context reads per hour
- 12 safe-setting proposals per hour
- 6 approved safe-setting applications per day
- 10 stale-state repair previews per hour
- 3 stale-state repair executions per day

These limits may change as plan enforcement evolves.

## Important limitation
Project scoping and server checks reduce cross-project drift, but AI output can still be wrong. High-risk and unsupported changes are blocked rather than entrusted to model judgment.