One manifest. Every member, rule and deliverable.
Describe an organization of agents the way you would describe a team: who does what, who may hand work to whom, and which actions need a person.
Each project is one manifest. It names a lead and its members, gives each its instructions and the exact tools, actions, files and knowledge it may reach, and defines the finished deliverable. The runtime refuses any hand-off that crosses the lines you drew, and every run is pinned to the manifest version it started on.
Approval rules live in the same place. Mark the actions that need a person, such as pushing code, opening a pull request, filing, publishing or paid calls. That task waits for an administrator's decision while other work carries on; no agent can approve. Members reach the outside world only through the actions and tool servers you grant.
Start from the setup wizard, a role template or a demonstration project.
Plan, delegate, deliver. In parallel where the work allows.
Hand the project a piece of work, or talk to one member directly. The lead breaks it into tasks, and independent tasks run side by side within the limits you set.
Gates are precise. An action marked for approval holds only the task that asked for it, so the rest of the run keeps moving. A spend ceiling pauses the whole run until you set the next figure. Either way, the control center shows it and your alerts reach you wherever you are.
Runs survive crashes. The run resumes from its last recorded step, without repeating model calls whose results were already decided. Outside actions are never repeated blindly: Alchemy reconciles each against its receipt, re-sends a web API call only under the same idempotency key, and otherwise asks a person first.
Done is written down. And checked independently.
Each project states what its deliverable must be: the files, their types and which one a reviewer should open first. The lead sees those terms before any work starts.
When the lead reports the work complete, a member that did none of it checks it against that definition. The checker receives the goal, the lead's summary and the files, not the lead's reasoning, and must open every deliverable, images included.
If the check fails twice, a person decides: accept the result or say what still needs to change. The check is on by default for every run.
Every finished task opens on its deliverable, with who checked it and what they opened.
Budgets you set in advance. Enforced before every step.
Before you start, a project previews the approvals the work is likely to reach and a likely cost, based on its past completed runs.
Run ceiling
Every run has a dollar ceiling, checked before each step and each billed model turn. When it is reached, the run pauses for your next figure.
Paid-call ceiling
Each call to a paid service is reserved against its own ceiling before it is sent.
Daily and monthly limits
Optional limits for each project and the whole account. Every way of starting or continuing work is checked against them.
Your key, your bill
Model use is billed to your own Anthropic API key, directly and never marked up. Nothing is metered by Agiliti.
Connect your systems. Govern every action.
Bind outside systems as declared actions. Each can require approval, is reserved against a ceiling when it costs money, returns a receipt to the record, and is reconciled after a crash.
Each tool server's tool surface is pinned when first seen; if it changes, the server is held until an administrator approves. A person starts every run.
| Capability | What members can do | How it is governed |
|---|---|---|
| GitHub | Push a branch and open a pull request | Declared actions; mark either for approval and name the member that may run them |
| Jira | Read, comment on and close tickets | Comments and closures as declared actions, each with its own approval rule |
| Tool servers (MCP) | Use the tools of any MCP server you grant | Tool surface pinned; any change held for an administrator |
| HTTP APIs | Call any web API bound as a declared action | Approval rules, receipts and idempotent retries |
| Media generation | Generate images, video and audio | Paid actions, reserved against the paid-call ceiling |
| Voice | Generate voice and music with ElevenLabs | Paid actions, reserved against the paid-call ceiling |
A complete trail of every run. Sealed on your disk.
For every step, Alchemy keeps what the agent was given, what it did and what it changed, including every action that reached your systems. The trail is not a log added afterwards: it is the run itself, so an interrupted run picks up exactly where it stopped.
Each run is stored on your own disk, encrypted with AES-256-GCM under a key kept apart from the data, and hash-chained so any edit shows. An export carries digests an auditor can verify independently, without Agiliti and without your key.
Step through a run event by event, fork it from an earlier step, or compare two runs. A deleted run leaves a tombstone of what it did outside your infrastructure and who approved it.
Nothing is sent to Agiliti. Everything that can leave your infrastructure is documented on Trust.
Shared knowledge, governed memory. Change you can measure.
Knowledge bases
Give a project your standards, style guides and system documentation. Each step searches a pinned version, and you decide which members may read it.
Governed memory
Let members learn across runs, including what a checker rejected. Every note records its source, notes from outside content can be held for review, and any note can be revoked.
Regression evaluations
Before changing a model, instruction or member, rerun past checked work under the new version and see what held and what regressed.
Role templates
Start members from an open-source library of role templates. A template sets responsibilities; your project sets what a member may touch.
Five views of a live organization. One place to decide.
Watch the work, answer approvals when something waits for you, and open the deliverable when it is done.
Approvals. Every waiting action lands in one Decisions inbox. An administrator decides in the control center or from an alert, and every decision is recorded.
Alerts. Waiting decisions reach you in Slack, Microsoft Teams, by webhook or as a desktop notification, with reminders while they wait.
Reporting. Spend by member and by model, decisions requested, and review time per accepted deliverable.
Team
Who is on the project and what each member is doing now.
Work
One lane per task in motion, with the members in the order they worked.
Floor
An isometric office showing where the work is happening, desk by desk.
Score
Every step, who took it and what it cost, one lane per member, live.
Board
Every file the team made, what it came from, and which one is the deliverable.
Questions about the platform. Answered plainly.
What does a governed AI agent runtime do?
A governed runtime executes AI agents while enforcing your organization’s rules at every step. In Alchemy that means scoped permissions for each member, human approval of the actions you mark, spend ceilings checked before work continues, an independent check against a definition of done, and a complete, tamper-evident record of what every agent was given, did and changed.
How do spend ceilings work?
You set a ceiling for each task, plus optional daily and monthly limits for each project and for the whole account. Alchemy checks spend against those limits before each step, and when a limit is reached the work pauses and an administrator decides what happens next. Because models run on your own Anthropic API key, the spend you see is your own.
What does the audit record contain?
What every agent was given, what it did and what it changed, along with every approval, refusal and spend decision. The record is encrypted and hash-chained, so altering a past entry shows when the chain is checked, and it can be exported and verified independently of Agiliti. Actions on outside systems are logged and never repeated after a crash.
How does Alchemy verify that work is actually done?
Every organization has a written definition of done. Before a run can finish, a member that did none of the work opens each deliverable and checks it against that definition. If the check fails, the work goes back for another round, and a person decides if it fails twice. Done means checked, not merely claimed by the agent that did it.
Which integrations does Alchemy support?
Alchemy connects to GitHub for branch pushes and pull requests, Jira, MCP tool servers, HTTP APIs, media generation and ElevenLabs voice. Actions on these systems can be declared as governed actions, so the manifest decides which members may use them and whether a person must approve first. Alerts reach Slack, Microsoft Teams or any webhook.
What does the control center show?
The control center shows your organization of agents at work: who is doing what, which actions are waiting for approval, how spend compares with its ceilings and which deliverables are finished. It is where administrators approve or decline marked actions, and alerts to Slack, Teams or webhooks mean decisions never depend on someone watching a screen.
Run it on your own infrastructure.
Evaluation access is a private source checkout under a short written agreement. Alchemy runs as one self-hosted process on Windows or Linux with Node.js 22, and a built-in check confirms which model credential a run will bill before any real work starts.