docs: refonte Get Started navigation, retire AI Builder Portal, docum…

docs/configuration/agent-tasks/build-deployment-optimizer.mdx

@@ -0,0 +1,32 @@
+---
+title: "Build & Deployment Optimizer"
+description: "Ready-made Agent Task that proposes faster, cheaper build and deployment configurations"
+---
+
+<Warning>
+**Alpha.** Agent Tasks is in early development and not yet generally available. Capabilities and setup will change before release.
+</Warning>
+
+## Overview
+
+Identifies build and deployment optimization levers and their expected gain, then opens a PR with the proposed change and/or updates the build configuration in Qovery directly. It never merges a fix on its own.
+
+## How It Works
+
+To find concrete ways to make builds and deployments faster and cheaper, the agent:
+
+1. Inspects the service's build setup: Dockerfile, dependency installation, layer caching, image size, and the build/deploy configuration in Qovery.
+2. Identifies optimization levers, for example better layer ordering and caching, multi-stage builds, smaller base images, pruning unused dependencies, or parallelisable steps.
+3. For each lever, estimates the expected gain (build time, image size, or cost) and the risk.
+4. Opens a PR with the proposed changes to the build configuration, and/or updates the build configuration in Qovery directly.
+5. Summarises what it changed, the expected gain, and anything that needs a human decision. It never merges, the human always stays the gate.
+
+## Setting It Up
+
+- **Context**: add the service's Git repository so the agent can inspect the Dockerfile and build setup.
+- **Access**: add the Qovery MCP server manually (`https://mcp.qovery.com/mcp`). A read-only [API Policy Token](/configuration/organization/api-policy-token) is enough to read the build/deploy configuration and propose changes via PR. Use one with write permissions instead if the agent should update Qovery directly.
+- **Resources and environment variables**: see [Configuration](/configuration/agent-tasks/overview#configuration) for the general settings shared by every agent task.
+
+## Triggering It
+
+Add a schedule trigger, for example weekly, to periodically review build performance, or trigger it from a webhook. See [Automations](/configuration/agent-tasks/overview#automations) for how triggers and outputs work in general.

docs/configuration/agent-tasks/incident-analyser.mdx

@@ -0,0 +1,47 @@
+---
+title: "Incident Analyser"
+description: "Ready-made Agent Task that correlates a firing incident with recent changes, logs, and metrics"
+---
+
+<Warning>
+**Alpha.** Agent Tasks is in early development and not yet generally available. Capabilities and setup will change before release.
+</Warning>
+
+## Overview
+
+Correlate a firing incident with recent changes, logs and metrics, then report and open a PR. When an incident fires, the agent investigates it and hands a clear summary back to the human on-call, it never merges a fix on its own.
+
+## How It Works
+
+When an incident fires, the agent:
+
+1. Reads the incident details (id, title, severity, affected services) from the trigger, fetching any missing details from your incident management tool.
+2. Correlates the incident with recent change context: the latest deployments, config changes, and merged PRs for the affected services around the incident start time.
+3. Pulls the relevant signals: application logs, metrics, and any runbooks for the affected services.
+4. Determines the most likely root cause and the blast radius, and is explicit about its confidence and what it could not verify.
+5. Reports its findings to the on-call human in chat: a short summary, the suspected root cause, and a recommended next step.
+6. If the fix is small and well-understood, opens a PR with the proposed change and links it in the message. It never merges, the human always stays the gate.
+
+## Setting It Up
+
+- **Credentials**: add your incident management tool's API key and a chat webhook URL (a [Slack Incoming Webhook](https://api.slack.com/messaging/webhooks), for example) as secrets, then reference them by name in the agent's instructions.
+- **Domain allowlist**: add the hostnames the agent needs to reach, your incident management tool's API and your chat webhook's domain.
+- **Resources**: this agent mainly makes API calls and reads logs and metrics, a small allocation is enough to start. See [Configuration](/configuration/agent-tasks/overview#configuration) for how resources are set.
+
+## Triggering It from incident.io
+
+The template is meant to be triggered by incident.io itself:
+
+<Steps>
+  <Step title="Create a Workflow in incident.io">
+    In incident.io, go to **Workflows** and create a new one.
+  </Step>
+  <Step title="Set the trigger">
+    Set the trigger to **Incident created**, or **Incident updated** filtered to severity changes.
+  </Step>
+  <Step title="Add a Send a webhook step">
+    Point it to this agent task's webhook URL (shown on its overview page). incident.io includes the incident payload, id, title, severity, and affected services, in that request, which is what the agent reads in step 1 above.
+  </Step>
+</Steps>
+
+See [Automations](/configuration/agent-tasks/overview#automations) for how triggers and outputs work in general.

docs/configuration/agent-tasks/overview.mdx

@@ -0,0 +1,104 @@
+---
+title: "Agent Tasks"
+description: "Configure AI agents that run as jobs on your Qovery infrastructure"
+---
+
+<Warning>
+**Alpha.** Agent Tasks is in early development and not yet generally available. Capabilities and setup will change before release.
+</Warning>
+
+## Overview
+
+Agent Tasks are one-time or scheduled jobs delegated to AI agents, running on your Qovery-managed infrastructure like any other service. Each agent runs with its own resources, environment variables, and a domain allowlist controlling exactly what it can reach.
+
+## Creating an Agent
+
+<Steps>
+  <Step title="Add Context (Optional)">
+    Connect a Git repository for the agent to load as context.
+  </Step>
+  <Step title="Choose a Provider">
+    Only Anthropic is supported today, with your own API key.
+  </Step>
+  <Step title="Add MCP Servers (Optional)">
+    Qovery's own MCP server is not added automatically, add it manually (`https://mcp.qovery.com/mcp`), or connect any remote HTTPS MCP server with its own name, URL, and headers. Authenticate with an API token or an [API Policy Token](/configuration/organization/api-policy-token) for scoped access. MCP servers added here are shared with every agent task in the organization, and can also be managed from **Organization Settings > AI settings > Agents**.
+  </Step>
+  <Step title="Write Instructions">
+    Describe the agent's role and the steps it should follow in plain text. Reference credentials by the environment variable names you configure below, for example `INCIDENT_IO_API_KEY`.
+  </Step>
+  <Step title="Add Automations">
+    Trigger the agent automatically and optionally send its result somewhere when it's done. See [Automations](#automations) below.
+  </Step>
+</Steps>
+
+## Automations
+
+An automation needs at least one trigger, and can optionally send its result to one or more outputs.
+
+### Triggers
+
+- **On a schedule**: a cron expression and timezone, for example `0 8 * * 1-5` for 8:00 AM, Monday through Friday.
+- **From a webhook**: Qovery generates a unique URL for the agent task, visible later in the environment's **Agent Tasks** list (for example `https://webhook.qovery.com/api/v1/hook/...`). Anything that can send a POST request to that URL starts the agent.
+
+### Outputs
+
+Send the automation's result to a webhook: a destination URL, custom headers, and a prompt describing how to shape the result before sending it.
+
+For example, to post the result to a Slack channel:
+
+<Steps>
+  <Step title="Create a Slack Incoming Webhook">
+    In Slack, add the **Incoming Webhooks** app to the channel and copy the generated URL (`https://hooks.slack.com/services/...`).
+  </Step>
+  <Step title="Add the output in Qovery">
+    In **Add output**, paste that URL into **Webhook URL**. No custom headers are needed, Slack's incoming webhooks accept a plain JSON POST.
+  </Step>
+  <Step title="Write the prompt">
+    In **Prompt**, describe the message you want, for example: "Summarize the result as a short Slack message with the root cause and the recommended next step."
+  </Step>
+</Steps>
+
+<Info>
+The Incident Analyser template uses a different, more direct pattern: it stores the Slack Incoming Webhook URL as a secret (`SLACK_WEBHOOK_URL`), adds `hooks.slack.com` to the domain allowlist, and instructs the agent to post to it directly as one of its own steps. Use this pattern when the agent itself, not just the automation's final output, should decide when and what to post.
+</Info>
+
+## Configuration
+
+<AccordionGroup>
+  <Accordion title="General Settings" icon="sliders">
+    A description of what the agent does.
+  </Accordion>
+  <Accordion title="Resources" icon="gauge-high">
+    CPU (mCPU), memory (MB), and storage (GB) allocated to the agent, same as any other Qovery service.
+  </Accordion>
+  <Accordion title="Governance" icon="shield-check">
+    A domain allowlist controls which external hosts the agent task can reach: comma-separated hostnames, or `*` for all domains.
+  </Accordion>
+  <Accordion title="Environment Variables" icon="key">
+    Plain variables or encrypted secrets the agent's instructions can reference by name. Secret values can't be viewed again once set.
+  </Accordion>
+  <Accordion title="Advanced Settings" icon="code-branch">
+    A Dockerfile fragment lets you install additional CLIs or binaries in the agent's runtime before it starts.
+  </Accordion>
+</AccordionGroup>
+
+## After You Create It
+
+Agent Tasks appear in your environment overview under **Agent Tasks**, jobs delegated to AI agents, run once or on a schedule. Each one lists its status, last operation, underlying model, and a dedicated webhook URL you can call to trigger it from outside Qovery. That same webhook URL is also shown on the agent task's own overview page.
+
+## Related Resources
+
+<CardGroup cols={2}>
+  <Card title="Incident Analyser" icon="triangle-exclamation" href="/configuration/agent-tasks/incident-analyser">
+    Ready-made agent that correlates a firing incident with recent changes, logs, and metrics
+  </Card>
+  <Card title="Build & Deployment Optimizer" icon="gauge" href="/configuration/agent-tasks/build-deployment-optimizer">
+    Ready-made agent that proposes faster, cheaper build and deployment configurations
+  </Card>
+  <Card title="Agent Tasks Overview" icon="robot" href="/getting-started/agent-tasks">
+    Use cases and ready-made agent templates
+  </Card>
+  <Card title="Environment Variables" icon="key" href="/configuration/environment-variables">
+    Manage configuration and secrets for your services
+  </Card>
+</CardGroup>

docs/configuration/organization.mdx

@@ -113,6 +113,14 @@ Configure basic organization details:
 
 Click **Update** to save your changes.
 
+### AI Settings: Agents
+
+<Warning>
+**Alpha.** Agent Tasks is in early development and not yet generally available.
+</Warning>
+
+Under **AI settings > Agents**, manage the MCP servers shared with every [Agent Task](/configuration/agent-tasks/overview) in the organization. Qovery's own MCP server is not added automatically, add it manually (`https://mcp.qovery.com/mcp`), or connect any other remote HTTPS MCP server here (name, URL, and headers) to make it available when configuring an individual agent. Authenticate with an API token, or an [API Policy Token](/configuration/organization/api-policy-token) to scope the agent's access, for example to read-only.
+
 ### Other Settings
 
 <CardGroup cols={2}>

docs/custom.css

@@ -417,7 +417,8 @@ html[data-theme="dark"] .badge-icon-scaleway-dark {
 .badge-container,
 .badge-cronjob,
 .badge-job,
-.badge-helm {
+.badge-helm,
+.badge-new {
   display: inline-block;
   padding: 3px 8px;
   border-radius: 4px;
@@ -469,6 +470,10 @@ html[data-theme="dark"] .badge-icon-scaleway-dark {
   background-color: #0f1689; /* Helm Blue */
 }
 
+.badge-new {
+  background-color: #642DFF; /* Qovery Purple */
+}
+
 .badge-terraform {
   background-color: #4040b2; /* Terraform Purple */
 }