Stop burning tokens on work your team has already solved.

Empower forward deployed engineers to build

Let'em Cook converts one-off AI work into reusable, governed Tools your team can securely run and share. Each versioned recipe carries the context, inputs, permissions, execution policy, and proof people and agents need to call it again—without paying the token and engineering cost of rediscovery.

Sheriff sayings 33 unplayed
    See the savings
    Ride on

    The reinvention tax

    Your AI spend should create capabilities from velocity, not disappear into sessions.

    Without Let'em Cook

    Every outcome starts over.

    • Tokens
    • Context reconstruction
    • Implementation
    • Credential setup
    • Validation
    • Execution and handoff

    One outcome

    With Let'em Cook

    Convert manual Playbooks into repeatable Tasks for the whole team.

    First outcome
    Describe the outcome Build review Publish as an app
    Every later outcome
    Authorize Run

    The bottom line

    Pay AI & your engineers once to invent the Process—not to rediscover it every time.

    Install and see the demo

    Jared hands Chris a button

    Read how Let'em Cook solves a distributed team's problem.

    A 24-hour GCP jump host moves from Jared’s operating knowledge to one governed action Chris can run himself—or ask an agent to run through the same authenticated path.

    1. 01 Ask for the capability

      Chris asks Jared for a jump host.

      Chris wants the ability to create a GCP jump host. But Chris tends to be forgetful and may leave it running for a long time. And that guy cannot be trusted with reusable GCP auth tokens to save his life.

    2. 02 Author the operating contract

      Codex turns Jared’s runbook into a recipe.

      Jared already has code that does the job, but handing it to Chris would create a stale copy—and sharing the GCP credentials behind it is out of the question. He asks Codex to turn his prechecks, approved GCP project and subnet, connection-result contract, failure paths, and mandatory 24-hour teardown into one reviewed recipe.

    3. 03 Bind least privilege

      Ship the key without shipping the value.

      Jared creates a GCP service account limited to compute.instances.create/get/delete, disk lifecycle, and the approved subnet. He pipes its JSON key to lemcli cookbooks secrets set "$COOKBOOK_UUID" GCP_JUMP_HOST_KEY --stdin; Chris receives the action, never the value.

    4. 04 Package and publish

      The container and cookbook travel together.

      Codex packages the GCP tooling in a tested container, then drives lemcli to publish its managed digest and the cookbook—wiki, form, launch recipe, 24-hour teardown recipe, secret declaration, and expected receipt—and bind its secret. The recipe gives Codex only the GCP_JUMP_HOST_KEY reference; at binding time, lemcli streams the value from Jared-controlled input straight to LEMC, so Codex never sees or records the credential.

    5. 05 Grant the outcome

      Chris gets the action, not Jared’s authority.

      Jared installs the cookbook as an app and grants Chris run access. Chris can read the operating context and launch the approved job, but he cannot read the GCP key, edit the cookbook, or turn the app into general cloud access.

    6. 06 Run it by hand

      Chris could click the button.

      Chris signs into LEMC, opens Jared’s app, reviews the wiki and permitted inputs, then clicks Build jump host. The browser follows the authorized job and renders the result as it arrives.

    7. 07 Delegate the same action

      However, Chris is technical and can instead bring his own agent.

      Chris installs lemcli, sets the LEMC base URL, and authenticates as himself. Then he tells Grok: “Hey, Jared made an app that lets me spin up a 24-hour jump host. Find it, launch it, and print the details when it’s done.” Grok discovers the authorized action and runs it with Chris’s exact rights.

    8. 08 Mark what this run owns

      The recipe leaves a precise trail in GCP.

      At runtime LEMC resolves the secret only inside the authorized job. The recipe labels every label-capable asset with the resource UUID, task ID, Chris’s normalized username, recipe identity, and expiry; names or metadata carry the same run key where GCP has no labels.

    9. 09 Return proof, then clean up

      Every caller gets the same job, guardrails, and receipt.

      Whether Chris clicks or Grok calls lemcli, LEMC applies the same API authorization, injects the same hidden binding, and returns the same host details, expiry, task ID, and terminal reason. At 24 hours, teardown locates the exact label tuple, verifies ownership, deletes only those assets, and preserves the result.

    Install + first demo

    Install the client, enter the versioned demo, and publish one reviewed Tool.

    The hosted beta path will use stock OpenSSH through LEMCSSH at a versioned demo-vN.letemcook.dev host. Native lemcli remains the authoring path, while teams ready to own the runtime can install the Linux/KVM server stack.

    1. Native authoring client

      Install lemcli for the authoring path.

      The installer detects Linux amd64 or arm64, resolves the current first-party release, verifies its SHA-256 checksum, and installs only the matching CLI. The hosted demo itself needs only stock OpenSSH.

      Request beta access 
      $ curl -fsSL https://letemcook.dev/lemcli/install.sh | bash
Installed lemcli 0.x to /usr/local/bin/lemcli (amd64)
$ lemcli version
lemcli 0.x · linux/amd64

    2. Planned hosted beta entry

      Enter the versioned demo through LEMCSSH.

      An accepted beta invitation will name the concrete demo generation, exact username, public-key enrollment flow, and host-key fingerprint. Verify that fingerprint out of band; LEMCSSH is a restricted LEMC command endpoint, never a server shell.

      $ ssh-keygen -t ed25519 -a 64 -f ~/.ssh/lemc-demo
# Enroll only ~/.ssh/lemc-demo.pub after invitation.
# ~/.ssh/config
Host lemc-demo-vN
    HostName demo-vN.letemcook.dev
    Port 2222
    User YOUR_EXACT_USERNAME
    IdentityFile ~/.ssh/lemc-demo
    IdentitiesOnly yes
    StrictHostKeyChecking yes

$ ssh lemc-demo-vN auth whoami --format=json
{"username":"YOUR_EXACT_USERNAME","account":"invited-account"}
$ ssh lemc-demo-vN apps list --format=json

    3. From demo Run to authored Tool

      Use native lemcli when you are ready to publish.

      LEMCSSH exposes reviewed remote-safe commands for discovering and running the demo. Native lemcli owns local authoring and secret binding, so the downloaded key stays outside the Git checkout and model context.

      $ lemcli init
LEMC server URL: https://demo-vN.letemcook.dev
Account: invited-account
Username: YOUR_EXACT_USERNAME
Password: ••••••••••••••••
✓ Server capability contract verified
✓ Context "demo-vN" is ready
$ lemcli auth whoami --format=json
{"username":"YOUR_EXACT_USERNAME","account":"invited-account"}
$ lemcli cookbooks create --name "GCP Server Lifecycle"
Created cookbook GCP Server Lifecycle (cb_7f31)
$ lemcli cookbooks push --uuid cb_7f31 --file cookbook.yaml
Published cookbook.yaml
$ lemcli cookbooks secrets set cb_7f31 \
    GCP_SERVICE_ACCOUNT_JSON \
    --from-file ../credentials/gcp-service-account.json
✓ Configured GCP_SERVICE_ACCOUNT_JSON · value never returned
    Agent terminalcodex

    Resulting cookbook

    Two buttons share one reviewed server lifecycle.

    Create a replacement safely, or tear down the tracked server now. Both actions use the same guarded computation.

    • Create a server Destroy any tracked server, create the replacement now, then destroy it in 24 hours.
    • Destroy the server now Run the same ownership-checked teardown immediately.
    cookbook.yaml reviewed contract 
    cookbook:
  name: GCP Server Lifecycle
  canonical_name: gcp-server-lifecycle
  environment:
    secrets:
      - GCP_SERVICE_ACCOUNT_JSON
  pages:
    - page: 1
      name: Timed GCP server
      recipes:
        - recipe: Create a server
          canonical_name: create-server
          description: Create one server and tear it down after 24 hours.
          callbacks:
            before_run:
              steps:
                - step: 1
                  name: Destroy if present
                  image: gcp-server-destroy:dev
                  timeout: 10.minutes
          now:
            steps:
              - step: 1
                name: Apply the declared server
                image: gcp-server-create:dev
                timeout: 20.minutes
          in:
            duration: 24.hours
            steps:
              - step: 1
                name: Destroy after TTL
                image: gcp-server-destroy:dev
                timeout: 10.minutes
        - recipe: Destroy the server now
          canonical_name: destroy-server-now
          description: Verify & destroy server
          now:
            steps:
              - step: 1
                name: Destroy the tracked server
                image: gcp-server-destroy:dev
                timeout: 10.minutes

    One review. One publish.

    Publish one managed capability from a single reviewed bundle.

    The cookbook, container, Terraform, and tests stay readable together. At runtime, the published action keeps reviewed defaults, a server-bound secret, timed teardown, and immutable image references on one path.

    1. Review cookbook.yaml · Dockerfile · terraform/ · tests/
    2. Publish lemcli cookbooks images push --build
    3. Run Reviewed defaults · bound secret · timed teardown · immutable digest

    The agent may write the declaration and invoke lemcli. A human or protected local input supplies ../credentials/gcp-service-account.json; the value never needs to appear in the prompt, cookbook YAML, logs, or returned artifacts.

    Where LEMC earns its keep

    Jobs that should not depend on who is awake.

    Start with work that is repeatable, privileged, infrequent, time-bound, or expensive to explain. Those are the jobs where a shared wiki, fixed runtime, narrow ACL, and durable receipt pay for themselves.

    BYOK / DigitalOcean WordPress migration

    Patch WordPress, move it to a clean host, and keep the proof.

    Bind a scoped, expiring DigitalOcean token and source-site access. A pinned recipe snapshots and inventories the site, provisions a clean host, installs a WordPress release with the WP2Shell fix, migrates reviewed content, and stages a preview before cutover.

    Author grants Patch + migrate one WordPress site wiki · source URL · secret refs · app ACL
    Site operator Bind cloud + source access
    Ephemeral LEMC job Snapshot · patch · migrate · verify
    Allowed outcome Reviewed WordPress host preview · approved cutover · rollback window

    LEMC retains source inventory · backup manifest · Terraform state · checksums · validation · cutover proof

    Security operations corporate network scan

    Scan the corporate network and deliver a reviewable PDF.

    Put the owned target inventory, scan window, fixed Nmap profiles, exclusions, and retention in the wiki. A teammate or agent selects a declared scope; the recipe runs without arbitrary flags and turns the evidence into a branded PDF.

    Author grants Run one bounded network assessment wiki · target set · scan profile · app ACL
    Security teammate or agent Choose target set + profile
    Ephemeral Firecracker jail nmap → XML → PDF
    Allowed outcome Review-ready scan report hosts · ports · services · evidence

    Durable receipt target-set revision · exact profile · raw XML checksum · PDF artifact · terminal proof

    Media operations authenticated transcode

    Turn one video into an MP3 without handing off the login cookie.

    Put source rules, output rules, and retention in the page wiki. Supply a Netscape-format cookie file through a cookbook secret binding; only the assigned media team can run the app, and the cookie never appears in logs or output.

    Author grants Fetch + transcode one video wiki · URL input · app ACL · cookie secret
    Assigned teammate or agent Submit video URL
    Ephemeral Firecracker jail yt-dlp → ffmpeg
    Allowed outcome MP3 artifact audio · checksum · bounded retention

    Durable receipt request · source metadata · selected format · MP3 checksum · jail cleanup

    Enablement 24-hour lab

    Give the whole class a real environment—then leave no orphan bill.

    A trainer publishes a Terraform-backed cookbook for the full stack. Learners launch from the web; an agent can run the same action through lemcli.

    Author grants Launch one governed personal lab region form · class image · individual ACL
    Learner or agent NOW provision the stack
    LEMC scheduler IN 24h tear it down
    Allowed outcome 24-hour lab real environment · paired cleanup · bounded cost

    Durable receipt form inputs · private state · provision result · teardown proof

    Explore restore drills, diagnostics, Day-2 operations, cloud hygiene, and more

    One unit, two callers

    The button and the binary share a trail.

    Publish the cookbook once. Teammates read its wiki and click a clear browser action; agents discover the same wiki, inputs, and action contract through structured CLI output. Nobody invents a second automation path.

    Caller 01

    Humans click

    Web UI

    Wiki guidance, forms, permissions, progress, rich output, and terminal reason stay legible to the person doing the work.

    Caller 02

    Agents call

    lemcli
    agent@trail 
    $ lemcli jobs surface app \
  --uuid "$APP_UUID" \
  --scope individual \
  --format=json

$ lemcli jobs run app \
  --uuid "$APP_UUID" \
  --action "$ACTION_ID" \
  --follow \
  --render html

    Page wiki_text, stable action IDs, JSON discovery, idempotent admission, live follow output, status, logs, and artifacts keep agents on the same governed path.

    One action ID, one policy check, one event stream, one terminal proof.

    Corporate theming

    Let an agent shape the interface from your logo and company colors.

    Theme the real LEMC workflow, not a separate dashboard. The same app, wiki, recipe action, signed-in user, and job proof remain in place while the company logo and colors reshape the interface.

    Default Let'em Cook 1 / 2

    Same governed workflow, company-fit presentation. Maya can discover People Operations and run its Individual action from the branded web UI. Separate app ACLs keep Finance Reporting, Leadership Briefing, and Web Filter Review visible only to the teams that need them. The theme controls appearance; LEMC controls discovery, execution, events, logs, and artifacts.

    Read the operator, admin, and agent-assisted theme guide

    Ephemeral compute, durable work

    A mini serverless runtime for the jobs your team owns.

    Trigger a cookbook from the web, lemcli, or a schedule. LEMC gives that job fresh isolated compute, streams its progress, saves its work, and removes the runtime when the job ends.

    1. 01Triggerweb · CLI · schedule
    2. 02Jailfresh Firecracker guest
    3. 03Rundigest-pinned steps
    4. 04Syncevents · logs · artifacts
    5. 05Destroyevery terminal path

    Ephemeral compute

    The jail disappears.

    Every hosted-untrusted job gets one fresh jailed Firecracker microVM. LEMC loads authorized, digest-pinned container steps, brokers the narrow access they need, and destroys the guest on success, failure, cancellation, timeout, or lost heartbeat.

    fresh guest · pinned image · bounded policy · proven teardown

    Durable record

    The work survives.

    Live events, terminal state, logs, rendered output, artifacts, cache, and workspace state return to LEMC before cleanup. The team can review the result, download its artifacts, or hydrate later work without keeping the microVM alive.

    one task ID · later review · reusable output · central proof

    Think “team-owned mini Lambda,” not AWS API compatibility. The useful analogy is submit → isolate → run → retain → tear down, with your LEMC server holding policy and proof.

    Comparison, not dependency

    MCP standardizes AI integration. LEMC distributes deterministic compute.

    Connecting the tool is the easy part. Teams still have to keep implementations current, decide who can change and run them, protect credentials, schedule cleanup, and prove what happened. MCP helps AI applications discover and invoke capabilities—including resources, prompts, Apps, progress, logs, and experimental Tasks. LEMC handles the operating work around those capabilities.

    • Versioning

      Where teams get stuck

      Two MCP hosts can quietly expose different versions.

      One host refreshes its MCP capability list, another keeps an older one, and nobody can easily prove which implementation handled a particular run.

      How LEMC solves it

      LEMC points everyone at the reviewed release.

      A versioned cookbook points at managed, digest-pinned images. Every job records the exact computation that was selected.

      The result: browsers and agent loops converge on the same release.

    • Contribution

      Where teams get stuck

      A useful local improvement can still get stuck on one laptop.

      MCP makes the tool callable. The team still has to decide who reviews a local change, where it is published, and how every caller receives the approved build.

      How LEMC solves it

      LEMC gives authors a path from laptop to team.

      An admin grants narrow cookbook authority; an author ships YAML and a container through lemcli; an app owner grants run access.

      The result: contributors improve the job without inheriting platform administration.

    • ACLs

      Where teams get stuck

      An MCP login can become the whole permission model.

      MCP can authenticate a caller; the server still needs to separate people who edit the computation, publish it, or simply run it.

      How LEMC solves it

      LEMC separates building from running.

      Cookbook ACLs protect view and edit authority. App ACLs protect individual, shared, and admin execution on every run.

      The result: give a teammate the outcome without giving them the author’s authority.

    • Context + proof

      Where teams get stuck

      The action arrives; its operating context does not.

      Resources, prompts, tools, progress, and logs can travel through MCP while approved inputs, retention rules, artifacts, and the final receipt live somewhere else.

      How LEMC solves it

      A LEMC cookbook keeps the wiki, action, and receipt together.

      The cookbook bundles the wiki, inputs, pinned steps, timing, ACL, retention rules, live events, logs, artifacts, and the terminal receipt in one governed unit.

      The result: every caller receives the same events, terminal state, logs, and artifacts.

    • Secret delegation

      Where teams get stuck

      An MCP tool still needs a safe credential story.

      Putting a call behind MCP does not decide how its underlying token is delegated, scoped, rotated, or kept away from the teammate or agent invoking it.

      How LEMC solves it

      LEMC shares the capability, not the secret.

      YAML carries a named reference. LEMC stores the encrypted, versioned binding server-side and redacts its exact value from logs, events, artifacts, and errors.

      The result: people and agents receive the capability, never the reusable credential.

    • Live trust

      Where teams get stuck

      Revocation can arrive late through another path.

      A server may reject new callers while an older client token, image grant, or copied MCP configuration still opens another path.

      How LEMC solves it

      LEMC checks today’s authority on every run.

      LEMC rechecks account membership, ACLs, digest grants, runner state, and owning resources before accepting the next job.

      The result: revoke once; the next browser, CLI, or API run is denied.

    • Execution path

      Where teams get stuck

      MCP says what can be invoked, not where its code will run.

      The same MCP action can sit in front of very different workload classes, image policies, runner choices, isolation, and resource limits.

      How LEMC solves it

      The server owns the execution path.

      Callers select an authorized action and inputs; LEMC owns preflight, queue admission, runner choice, and isolation.

      The result: an agent cannot request “run this on the host” or bypass policy.

    • Network authority

      Where teams get stuck

      A tiny tool can inherit the server’s whole network.

      Unless its implementation narrows the path, an MCP tool may see the runner host, private LAN, cloud metadata, or primary API simply because the server can.

      How LEMC solves it

      LEMC gives each job a narrow network boundary.

      Hosted jobs receive narrow registry, storage, DNS, event, and permitted-egress paths while private targets remain denied.

      The result: network authority becomes part of the reviewed computation.

    • Idempotent admission

      Where teams get stuck

      An MCP request ID is not business-action idempotency.

      After a timeout, an MCP client can retry while the team still has to decide whether the first request already changed the real resource.

      How LEMC solves it

      LEMC checks and deduplicates before execution.

      Stable action IDs, idempotency keys, input validation, image authorization, ACL checks, and queue locks run before enqueue.

      The result: network retries do not have to mean duplicate mutations.

    • Scheduling

      Where teams get stuck

      MCP Tasks can track work; they do not invent its teardown.

      An experimental MCP Task can be polled or cancelled, yet the team still arranges the paired launch, recurrence, or cleanup schedule that makes the work safe.

      How LEMC solves it

      LEMC schedules through the same governed job path.

      NOW, IN, and EVERY jobs share the same authorization, image, isolation, event, storage, and cleanup path.

      The result: create now and destroy in 24 hours without relying on memory.

    • Workflow composition

      Where teams get stuck

      One tool name can conceal a whole workflow.

      MCP callers see one action, while its step order, state transfer, timeouts, stop-on-failure rules, and final reason stay hidden in implementation code.

      How LEMC solves it

      LEMC makes the workflow a recipe everyone can inspect.

      Pinned container steps pass declared state, enforce timeouts, stop deterministically on failure, and share one result.

      The result: authors compose the job once instead of rebuilding orchestration per client.

    • Durable state

      Where teams get stuck

      The task finishes, but its evidence vanishes with the runner.

      MCP Tasks can provide durable handles, polling, cancellation, terminal states, and deferred results. The team still decides which evidence must outlive the machine.

      How LEMC solves it

      LEMC keeps useful state after the machine is gone.

      Output, logs, artifacts, cache, private state, and terminal proof synchronize before ephemeral scratch is deleted.

      The result: a later browser or agent can hydrate the result without preserving the runner.

    • Storage governance

      Where teams get stuck

      MCP can return a file without deciding who owns it.

      Content can come back through MCP while ownership, quotas, retention, checksums, audit history, and deletion remain separate chores.

      How LEMC solves it

      LEMC turns logs and artifacts into governed records.

      Durable objects carry account ownership, checksum, exact-task selection, quota, audit, and retention metadata.

      The result: output becomes reviewable team evidence, not a caller’s loose file.

    • Runner fleet

      Where teams get stuck

      A healthy MCP endpoint does not prove a healthy runner.

      The endpoint responds, but its Firecracker, jailer, kernel, rootfs, runtime files, pool state, or self-tests may have drifted.

      How LEMC solves it

      LEMC makes the runner prove it is ready first.

      Hosted-untrusted work is admitted only to a ready, drift-free, self-tested Firecracker runner that passed hardware validation.

      The result: a runner must prove capability before it can lease hostile work.

    • Agent discovery

      Where teams get stuck

      Discovery can find work before an agent knows to trust it.

      Refreshing an MCP list finds new work, but the agent still needs a stable identity, current permission, and reviewed release before it should run anything.

      How LEMC solves it

      Agents rediscover only authorized releases.

      An agent can relist authorized apps and stable action IDs with lemcli each loop, then run only what is needed.

      The result: new team tooling appears without weakening the hard authorization gate.

    • Workspaces

      Where teams get stuck

      MCP resources do not define a team’s file boundary by themselves.

      Each MCP implementation decides where files live and who can see them, so callers cannot tell what belongs to one person, the team, or the cookbook.

      How LEMC solves it

      Each kind of state gets an explicit home.

      LEMC distinguishes individual and shared execution, public artifacts, private state, cookbook state, cache, and task proof.

      The result: the application’s data boundary is declared instead of implied.

    • Cleanup proof

      Where teams get stuck

      An MCP tool can succeed while cleanup is still unfinished.

      The MCP result arrived, but nobody knows whether its output synchronized, the guest stopped, scratch was deleted, or the queue lock was released.

      How LEMC solves it

      Cleanup is part of success.

      LEMC requires sync, terminal events, guest and process teardown, bounded disk growth, scratch deletion, and lock release.

      The result: cleanup failure can fail the job instead of hiding behind a green exit code.

    • Mixed skill levels

      Where teams get stuck

      MCP serves agents well; human parity still takes product work.

      Even with MCP Apps, a team can end up with one human form and approval flow while automation gets different progress, errors, and results.

      How LEMC solves it

      LEMC gives people and agents the same action.

      Humans get wiki, forms, buttons, progress, and downloads; experts and agents get YAML, API, JSON, and lemcli.

      The result: both audiences use the same job path and receipt.

    • Language independence

      Where teams get stuck

      Wrap five languages and policy may be wrapped five times.

      Separate MCP servers for Go, Python, Bash, Terraform, and vendor CLIs can each rebuild the same image, input, secret, network, output, and proof rules.

      How LEMC solves it

      Govern the job boundary, not the language.

      Compose Go, Python, Bash, Terraform, security tools, or vendor CLIs while LEMC governs the surrounding execution contract.

      The result: cook with the right tool without creating a second control plane.

    • Auditable denial

      Where teams get stuck

      MCP can return an error without leaving a denial receipt.

      Protocol errors are useful, but rejected elevation, invalid credentials, image grants, and runner-policy decisions can still disappear into separate MCP server logs.

      How LEMC solves it

      Denials leave receipts too.

      LEMC audits rejected execution, service-token, storage, registry, image, runner-policy, and cleanup decisions.

      The result: mixed-trust teams can inspect both what ran and what was blocked.

    LEMC does not use MCP. LEMC directly owns the layer a small team needs after standardized integration: distribution, governance, isolated execution, and durable proof. MCP could be used to reach a system that implements these things. LEMC’s advantage is that these things are the system.

    Read the source trail and full comparison

    Your next reliable action

    Stop handing out scripts & skills.
    Start building governed computations.

    Build the wiki, inputs, container steps, timing, ACL, and proof once. Then let every authorized teammate and model run the same deterministic compute.

    Open the docs Request beta access

    Agent in town? Start at letemcook.dev/llms.txt