# Alchemist Architecture: The Two Planes

How Chipp's Alchemist separates the autonomous development plane (AI agents that plan, build, test, review, and deploy) from the production application plane (what actually runs). AI does the engineering work; it does not have to run in your deployed software.

---

Chipp's Alchemist platform is an autonomous software-development and delivery
system. It is easiest to understand as two separate planes: the **development
plane**, where AI agents do the engineering work, and the **production
plane**, where the software they build actually runs. The two are
independent. AI agents write, test, and ship the code; the code itself does
not have to contain any AI at all.

> **Note:** This page is about how Alchemist is structured, not a tutorial. To ship your
> first change, see [Alchemist: Getting Started](/docs/guides/alchemist-getting-started).
> For the ticket-to-deploy mechanics, see [Alchemist Tickets: Autonomous Development](/docs/guides/alchemist-tickets).

## The autonomous development plane

This is where the engineering work happens, and it is entirely AI-agent
driven:

1. **Intake.** A request comes in from the dashboard, the API, or a
   connected Slack workspace. Slack and chat are optional intake and
   governance surfaces here, not a production dependency; you can dispatch
   every ticket from the dashboard or API and never touch chat.
2. **Project agent.** A project agent reads the request in the context of
   your existing codebase and conversation history and clarifies it before
   any code is written.
3. **Ticket and acceptance criteria.** The project agent drafts a ticket
   with a testable definition of done, so the outcome is judged against
   something concrete rather than a vague ask.
4. **Planning and execution graph.** Agents break the ticket into a graph
   of specialized steps instead of one long, unauditable generation.
5. **Implement.** One or more agents write the change in an isolated
   sandbox, against your project's real repository, with checkpoint
   commits to source control.
6. **Test, review, and security-check.** Independent agents exercise
   the change, review the diff for correctness and convention, and run an
   adversarial security check.
7. **Semantic merge.** The reviewed branch merges into your project's main
   line through source control, coordinated with any other in-flight work
   so nothing races or double-ships.
8. **Deploy.** A normal CI/CD pipeline builds and rolls out the merged
   change.
9. **Verify.** Agents check the deployed result against the original
   acceptance criteria, including runtime checks against the live app.

Every step above is a recorded, auditable stage on the ticket, not a
black box: you can see the plan, the diff, the test results, the review
notes, and the verification evidence for anything that shipped.

## The production application plane

This is what actually runs after a ticket lands, and it is ordinary,
deterministic software. Nothing about Alchemist requires the production
output to contain a chatbot, an LLM call, or any other AI component:

- **APIs and backend services** that other systems call over HTTP or gRPC.
- **Service-to-service integrations** that connect your existing systems.
- **Workers and background job processors.**
- **Scheduled jobs and cron-style tasks.**
- **Event processors** that consume a queue or webhook stream.
- **Data pipelines** that move and transform data between systems.
- **Conventional web applications**, with or without a chat surface.

See [Alchemist Production Workloads: Non-Chat Examples](/docs/guides/alchemist-production-workloads)
for a concrete ticket example of each of these.

A published Chipp chat agent (an AI-powered conversational app) is one thing
Alchemist can build and operate for you. It is a supported use case, covered
in depth elsewhere in these docs (see the **Agent Capabilities**, **Publish &
Share**, and **Voice & Phone** categories), but it is not the definition of
the platform. If your ticket asks for a REST endpoint, a nightly ETL job, or
a webhook handler with zero natural-language surface, Alchemist builds and
ships exactly that, and no AI runs anywhere in the resulting service.

## Why the split matters

Because the two planes are independent, you can adopt Alchemist for its
engineering throughput (agents doing the work of planning, coding, testing,
reviewing, and shipping) without changing what your production architecture
looks like or introducing an AI dependency into a system that has to behave
deterministically. The AI agents are part of how the software gets built and
maintained; they are not part of what the software has to be.

## Related reading

- [Alchemist: Getting Started](/docs/guides/alchemist-getting-started) -- create a
  project and ship your first ticket.
- [Alchemist Production Workloads: Non-Chat Examples](/docs/guides/alchemist-production-workloads) --
  concrete tickets for APIs, workers, jobs, and pipelines.
- [Alchemist Tickets: Autonomous Development](/docs/guides/alchemist-tickets) -- the
  ticket-to-deploy lifecycle in detail.
- [Alchemist: Working with Tickets](/docs/guides/alchemist-working-with-tickets) -- how to
  describe work and respond when an agent asks a question.