Five things happen in every step. Always in this order.
The step is the unit of work, and every step leaves an entry in the run's record.
1. What the agent is given is kept
Alchemy keeps exactly what the member is given for this step: its instructions, the task, the files handed to it, its tools and permissions, and the versions of any memory or knowledge it can read. Later you can see precisely what the agent was working from, not just what it said, and a retried step starts from the same place.
2. Ceilings are checked
Alchemy checks the run's spend ceiling and any daily or monthly limits for the project and account, allowing for steps already in flight. When a ceiling is reached, no new step starts until an administrator decides.
3. The member works
Claude runs one turn in the member's own workspace. Tool calls are checked against the member's grants; reads and writes outside the workspace are refused. Text from outside is marked as observed content, not instruction.
4. Outside actions are logged, and never happen twice
When a member asks to push code, post a comment or make a paid call, Alchemy logs the request and then the result. If anything is interrupted in between, Alchemy checks what actually happened instead of trying again, so nothing is done twice. Actions that cannot be undone, or that need approval, run as their own step, never inside the agent's work.
5. The outcome is recorded
The turn ends in one of four outcomes, checked against the manifest. Delegating outside permitted edges, requesting an action the member does not hold, or citing a deliverable it never received is refused and logged. Spend, tokens and time are recorded with the outcome.
Agents never call each other. Every turn ends in one of four ways.
Deliver
The task is done. The member hands over its deliverables and a short handoff note. For the lead, the definition of done decides whether the run may finish.
Delegate
The member creates tasks for named teammates within its permitted edges. Independent tasks run side by side, and the parent waits as a recorded entry, not an open session.
Need a person
The member asks a question with options. That task waits for the person who started the run or an administrator, while the rest of the run keeps working. The record shows who answered.
Fail
The task cannot be done, and the member says why, with evidence. A task that reaches no outcome within its turn limit is failed; a person can reopen the run.
Done is written down. An independent member checks it.
Before a run can finish, a member that did none of the work opens every deliverable against the project's written definition of done. The check is on by default.
- 01
The definition comes first
Each project declares what it must deliver (the files, their types and minimum sizes) and which member checks them. The definition is pinned when the run starts, and the lead knows its terms before work begins.
- 02
Alchemy checks the contract
When the lead reports done, a missing, empty, undersized or mistyped deliverable is sent back for correction.
- 03
An independent member checks the work
The checker receives the deliverables, the goal and the lead's handoff, but none of the lead's reasoning. It cannot be the lead or have written anything it checks, and it must open every file, including every image.
- 04
A person settles the last word
The lead fixes what the checker finds and submits again. If the work still falls short after two rounds, a person decides: accept it as it stands, recorded as a waived check, or say what still has to change.
Properties of the runtime. Not instructions in a prompt.
These hold on every run, whatever the manifest, the model or the task.
Exactly what each agent saw
For every step, Alchemy keeps exactly what the member was given, so any decision can be traced back to the information behind it.
At most once, then reconciled
A declared outside action is never repeated after a crash. One with a recorded result is finished from its receipt; one whose result is uncertain goes to an administrator, never back out automatically.
Only a person approves
An approver can be a person or nobody. A manifest that names an agent as approver is refused when it loads. Approvals are decided by an administrator, in the control center or from an alert.
A pinned manifest
The manifest is fingerprinted into the run's first record. Moving a running project onto an edited manifest is an explicit, recorded change.
Allow-listed reach
Each member reaches only the files, tools, connections and actions its manifest entry grants. Tool servers are held to an approved tool surface, checked when each step starts.
A tamper-evident record
The run's record is append-only, hash-chained and encrypted on your disk. Every view in the control center is rebuilt from it, and an exported copy can be verified independently.
Every declared action has an approval, a reservation and a receipt.
Anything that leaves the machine through Alchemy, such as a branch push, a pull request, a ticket update or a paid generation, is declared in the manifest as an action. Agents request declared actions; Alchemy runs them under the rules you set.
Model spend is governed alongside. Every run carries a spend ceiling you set, checked before each step. Optional daily and monthly limits apply per project and across the account, and hold even when many runs start at once. At a ceiling, an administrator continues with a new figure or stops the run.
Approval
a person or nobodyMark an action for approval and it waits for an administrator's decision in the control center or from a Slack, Teams or webhook alert, while the rest of the run keeps working.
Executor
any member, or one named memberName the one member allowed to run an action, and it runs as its own recorded step, separate from the member that asked for it.
Reversibility
yes or noIrreversible actions never run inside an agent's turn. If the outcome of one is uncertain, it goes to an administrator rather than being retried.
Reservation
per paid callActions billed per call reserve against the run's paid-call ceiling before they go out. A call that would exceed the ceiling is not sent.
Receipt
every callEach action is recorded as attempted before dispatch and as done, with its result, when it returns. After a crash, Alchemy reconciles from that receipt instead of calling again.
A Jira ticket, taken all the way to a pull request. With a signed-off release at the end.
One manifest describes the whole project: eleven members, what each may touch, which actions wait for a person, and what counts as done. Once a ticket is picked up, the team takes it through the delivery lifecycle most teams still run by hand.
Intake
The requirement reader checks the ticket against your intake standard: is it clear enough to build and to test as written?
Questions back to the creator
If the ticket falls short, up to five focused questions go back to the person who raised it as a Jira comment. The comment waits for a person's approval before it posts, and only one member can post it. The run then pauses, at no cost, until the creator answers.
Vetting
The requirement vetter accepts a numbered set of goals and requirements, every line traced to the ticket or to the creator's reply, or returns it with what is still missing.
Test cases
The QA designer writes test cases for every requirement and goal, working from the accepted requirements alone. It never sees the code.
The plan
The tech lead writes the developers' plan: the interface, the tasks, and which test cases each task must pass. It cannot write code.
The build
The developer works on the application code and the test automator on the tests. Neither can read the other's work, and every refusal is recorded.
QA and QC
The QA validator applies the final changes to a clean copy, runs the whole test suite and writes the UAT pack: each requirement, its test case, its test and the result. It cannot edit what it measures.
UAT sign-off
The release manager requests the push. The delivery manager's approval of that push is the UAT sign-off.
Pull request and Done
The branch is pushed and the pull request opens on GitHub, where your repository's own checks can run on it. The ticket moves to Done with a comment citing the evidence. Only the release manager can take these steps, and each is recorded and happens once.
Completion check
Before the run can finish, the delivery auditor reads the seven delivery documents and confirms the work is complete. It authors nothing itself.
A crash costs only the steps in flight. The rest of the run is already on disk.
People decide how a run ends. Accept as done requires a note and is refused while any action is uncertain. Stop closes open approvals as abandoned; no ending approves anything. Reopen continues a finished run with a recorded reason.
The process stops
restartOn restart, Alchemy replays the record. An outcome already recorded is finished without another model call, and each step that was in flight runs again from its saved context in a fresh workspace.
An action was in flight
reconciliationActions with a receipt are completed from it. An action whose result is uncertain is never sent again automatically; a paid one keeps its reservation, and an administrator decides whether it happened.
The provider pushes back
errors and capacityTransient errors are retried with back-off. When usage capacity runs out, the step is parked and resumes as the same turn once capacity returns.
A decision is pending
waitingA task waiting for a person holds no live process, so it can wait over a weekend at no cost while other work continues.
Common questions. Short answers.
What goes in the manifest?
The manifest describes your organization of agents in one place: its members and lead, what each member may touch, which actions need a person’s approval, the spend ceilings that apply and the written definition of done. Alchemy reads the manifest and enforces it while the work runs, so the rules you review are the rules that run.
What happens when an agent reaches an action that needs approval?
That action waits, and the request appears in the control center, with an alert to Slack, Teams or a webhook if you use them. An administrator reviews what the agent intends to do and approves or declines it. Other work carries on meanwhile, and the decision is written to the record alongside the action itself.
What happens if the process crashes mid-run?
Alchemy picks up from its record. Governed actions on outside systems, such as a push, a pull request or a ticket comment, are logged when requested and when completed, so after a restart Alchemy knows which ones already happened and never repeats them. If it cannot tell whether an action landed, it asks a person instead of guessing.
How do I show an auditor what the agents did?
Export the record. It holds what every agent was given, did and changed, together with every approval and the definition-of-done check. It is encrypted and hash-chained, so alterations show when it is verified, and it can be checked independently of Agiliti. Reviewers get direct evidence of human oversight instead of a summary written afterwards.
What do I need to run Alchemy?
A Windows or Linux machine you control with Node.js 22, and your own Anthropic API key. Alchemy runs as a single process, so there is no cluster or container platform to operate. Your manifests, records and deliverables stay on that machine, under your existing security controls and backup routines.
See it run on your own work.
Evaluation access comes under a short written agreement. A design partnership puts Alchemy to work on one of your processes for eight weeks.