AlchemyLab

The agentic workbench

Every request is reviewed, tested and kept on the record.

Runs on your machine Works with Claude, ChatGPT, Gemini or your own model

Code is one kind of work.
So is a simulation, a report, a nightly check.

Software got reliable through specs, tests, review and version history. AlchemyLab uses the same for engineering, research, office work and operations.

  • Research

    Published foil profiles are looked up and the sources named.

  • Code

    The geometry is written as code, with tests.

  • Simulation

    Ten runs at once. Five converge, and only those are quoted.

  • Office work

    A report is written. Every number links to its run.

Engineering in AlchemyLab, 1:28. One foil, from the first ask to the signed-off report.

Agentic work minus the YOLO.

Two dials set how much the agents decide alone and how much proof a request needs. Three guarantees stay the same at every setting.

Autonomywho decides

The work goes on with the recommended answer while you decide. You sign off.

Strictnesshow much proof

Your checks, plus a reviewer for each criterion and your guidance.

At every setting
  • The work stays apart from your project until it is completed.
  • The receipt says what was checked, and what was not.
  • A completed request can be undone.

Set the bar. Stay in the loop.

Each job becomes a request with its own workspace and its own gates: the checks it has to pass before delivery. While it runs, you talk to it from one place, next to everything else that is running.

You say what you want; the request records the criteria agreed up front; it runs in its own workspace; the gates test, review and sign it off; it is delivered once with a receipt. Underneath every step, Steer keeps you in contact with the running request. “Lock out repeated failed logins.” you in plain words REQ 4821 Add a login lockout Keyed on the client IP Unlocks after 15 minutes the request criteria agreed up front BOX req 4821 main its own workspace kept apart from other work test review sign-off the gates checked before delivery RECEIPT criteria2 of 2 met testspassed reviewpassed the result with a receipt of the checks Steertalk to the request at any step, and answer its questions, without stopping it You say what you want; the request records the criteria agreed up front; it runs in its own workspace; the gates test, review and sign it off; it is delivered once with a receipt. At every step, Steer keeps you in contact with the running request. “Lock out repeated failed logins.” you in plain words REQ 4821 Add a login lockout Keyed on client IP Unlocks in 15 min the request criteria agreed up front BOX req 4821 main its own workspace kept apart from other work the gates test, review, sign-off RECEIPT criteria2 of 2 testspassed reviewpassed the result with a receipt of the checks Steer talk to it at any step
  1. 1 · The request

    Each job is a request. It stays apart from your project until it passes.

    Write it the way you would brief a colleague.

    You can have five requests running while you write the sixth. When two touch the same thing, each is told about the other.

    Related requests form a thread, which can carry a budget and a target.

    req 4817 · writing
    requests/004817
    Rewrite the onboarding guide for the new setup flow
    Acceptance criteria
    • Every step matches what the installer actually does now
    • No screenshot older than the 3.0 interface
    • Links from the old guide still resolve
    1. Build
    2. Test
    3. Review
    4. Sign-off

    A failed gate sends the work back with the feedback, and a delivered request can be undone, together with any later work built on it.

  2. 2 · Steer

    One place where every running request talks to you.

    Every running request reports to Steer. A comment reaches a working agent right away, without stopping it. Questions come with one-tap answers, and an agent can show you an exhibit, such as a chart, that you can answer from.

    Sign-offs and disputed rules wait for you, with no default and no timeout.

    Before you leave it running, you agree on a goal and a spend ceiling. The morning page shows each change with Keep or Undo.

    you · on req 4821
    Use the client IP, not the account, for the lockout key.
    agent · while working
    Switching the key to the client IP. Rewriting the second criterion to match.
    reviewer asks · decides in 2h on the starred option
    Should the lockout also apply to the password reset route?
    ★ Yes, same limits No, login only Ask me later
    Sign-off is held for you. It waits until you decide.
    autonomy · assisted strictness · reviewed

You answer once. The project remembers.

Answers, decisions and sign-offs are saved with the work they came from. When a later agent runs into the same question, it gets your earlier answer instead of asking again.

  1. Every decision keeps its history.

    Each decision records who made it, which later questions it answered, and whether it was revised or disputed. One that is reused often enough is offered to you as a standing rule, for this project or for every project you own.

    product decision
    area · auth
    Q: Should rate limits apply per account or per client IP?
    Per client IP. Decided by you, on req 4821.
    Trail
    • day 1answered req 4821
    • day 4answered a question on req 4863 without asking you
    • day 9confirmed by an agent that used it
    • day 9suggested as a standing rule for auth
    shaping decision · reused on 2 requests

Your way of working. Written down once.

A workflow is how a project's work is done. Guidance is what the work must respect, and kept checks make sure it stays that way.

WORKFLOW practices guidance team dials gates hooks exports as one file PRACTICES 1 2 3 coarse mesh refine settled runs report GUIDANCE Every field’s final residual is below 1e-5 The report states each idealisation TEAM worker reviewer rules reviewer DIALS autonomyassisted strictnessreviewed effortmedium GATES build test review sign-off HOOKS request completesprompts an agent

The workflow says how. Your guidance says what.

A practice is a way of working, like "run the coarsest mesh first, then refine". Guidance is what the result must respect, like "every field's final residual is below 1e-5". Each says where it applies, and guidance that can be measured becomes a criterion on every request it reaches.

A criterion that passed can be kept: every later change that reaches it is measured against it again. Agents cannot reword or drop guidance or a kept check. When one does not fit a request, you make an exception and say why.

An agent that finds a way of working worth repeating proposes it as a practice, and nothing applies until you adopt it. Whoever imports your workflow works the same way.

req 4907 · CFD case
engineering
Lift and drag from 0 to 18 degrees
Practice given: run the coarsest mesh first, then refine
Your guidance · engineering work
  • Every field's final residual is below 1e-5
  • The validation case is within 3% of the reference data Exception for this request: no reference data for this foil
  • The report states each idealisation and what it costs
Kept from req 4861
  • Lift changes less than 2% between the two finest meshes
This request
  • One case per angle from the same template
  • Cl and Cd against angle, settled runs only
3 from guidance · 1 kept · 2 added 1 exception by you

Guidance and kept checks come first and cannot be edited on the request. An exception keeps its reason on the record.

Rules show up where they apply.

Rules cover a file, an area, a project, or every project you own. An agent sees an area's rules when it starts work there and a file's rules the moment it opens that file, with who set them and when. If it disagrees with a rule it says so, and only you can retire one.

Busy areas keep an agent assigned and already briefed. The next request there starts with what the last one learned.

Areas · this project
auth
3 rules · agent assigned
billing
2 rules
ui
4 rules
api
1 rule
infra
quiet
docs
1 rule
read_file api/limiter.ts
standing rule · pinned to api/limiter.ts
Rate limits key on client IP, never on account. you · 9 days ago

Local-first. Remote whenever.

Your code, your files and the content of your work are kept on your computer. AlchemyLab's server keeps the structure of the work and the settings you chose, so any device can follow it while your computer is on.

Your machine runs the work with the models you choose and keeps your code, your files, the agents' sessions and the content of the work. AlchemyLab keeps metadata about the work, such as ids and states, and your devices reach it from anywhere. your devices a colleague AlchemyLab METADATA req 4821review req 4817done req 4863draft your machine BOX npm test npm run lint npm run build FILES api/limiter.ts api/auth.ts README.md SESSIONS Alchemist worker reviewer Anthropic OpenAI local model Your devices reach AlchemyLab, which keeps metadata about the work, such as ids and states. Your machine runs the work, keeps your code, your files, the agents' sessions and the content, and calls the models you choose. your devicesyou and a colleague check in from anywhere METADATA req 4821review req 4817done req 4863draft AlchemyLab keeps metadata: ids, states, times BOX your machine the work, your sessions, files and content models your models any provider, or a local one

Your colleague logs in and sees the whole project. Each request is one person's, the work still runs on your computer, and other members install nothing.

On your machine

Your files, your models

One AlchemyLab runs in the background on your computer, built on OpenCode, and keeps working when you close the terminal. Your files, git history and agent worktrees stay on your disk. It works with Anthropic, OpenAI, Google, any OpenAI-compatible endpoint or a local model, and can run on the Claude, ChatGPT or Copilot plan you already pay for.

From anywhere

Any device, shared with others

Log in from your phone, a tablet or another computer and you see the same project and the same running work, read from your computer while it is on. A computer that stays on, such as a server, can run it for you. Invite people by email: everyone sees all of the project, each request is one person's, and other members install nothing.

A sealed box
for every agent you run.

Agents run inside a hardened box with controlled network access, whatever model they use. What they reached, what they were refused and what they changed is logged on the request.

A confined box with a read-only root, no network and dropped capabilities. A catalogued command goes in, a dangerous command waits at the wall for a person, an outbound call is refused at the wall, and the record keeps all three. the box /work api/limiter.ts api/auth.ts tests/lockout.test.ts package.json read-only · no network · no caps $ npm test in the command catalog $ drop index waits for a person vendor-cdn.net refused at the wall the record keeps all three RECORD ran held refused A confined box with a read-only root and no network. A catalogued command goes in, a dangerous command waits at the wall for a person, an outbound call is refused at the wall, and the record keeps all three. /work api/limiter.ts api/auth.ts the box read-only, no network outside inside npm test in the command catalog drop index waits for a person vendor-cdn.net refused at the wall RECORD ran held refused the record keeps all three

Inside the box

Anything beyond editing tracked files runs in a disposable container with a read-only root filesystem, dropped capabilities and no network unless you allow it. Without Docker, commands run in the operating system's own sandbox or wait for your approval.

What you decide

You decide what agents can reach and run. An unapproved connection is refused, an unapproved command waits for a person, and a few dangerous commands never run. Agents never get an open shell and never commit, branch or merge: AlchemyLab does that, and refuses any git command that would change the repository.

How AlchemyLab handles your data and security →

Your tracker is the front door.

Connect Linear once and label the issues AlchemyLab should take. Each one arrives as a draft request for you to start, and what happened to it comes back to the issue in Linear.

PIT-8 Add a pipeline check marker to the README alchemylab
A

AlchemyLab 07:11

AlchemyLab filed this issue as draft request req000182. Work starts when it is started in AlchemyLab. Its receipt will be posted here when it is completed.

A

AlchemyLab 07:24

AlchemyLab receipt · req000182

✓completed 84f4538 ✓criteria 3/3 met ✓tests passed ✓nothing blocked

Reviewed against the criteria by a separate reviewer, and tested on the merge candidate.

Recreated from a real run in Linear.

Use the alchemylab label or your own, for one team or all of them. With auto-import on, labeled issues become draft requests within about a minute. A comment says which request the issue became and the receipt follows when it is completed, if you turn them on.

Other trackers, error reporting, databases and documentation servers connect as MCP servers that agents can use while they work. Finished work can also go out as a GitHub pull request.