We are using AgentMail for sourcing quotes here at scale with various top shippers. It’s not about letting the agent act in fully deterministic ways, it’s about setting up the right guardrails. The agents can now do most of the job, but when there’s low confidence on their output, we have human in the loop systems to act fast. At least in competitive industries like logistics, if you don’t leverage these types of workflows, you’re getting very behind, which ultimately costs you more money than being off by some dollars or cents when giving a quote back.

Okay that makes sense.

Do you see more pushback in specific industries? I did some quote/purchasing automation work in food mfg a decade ago, and those guys were super difficult to work with. Very opaque, guarded, old-school industry.

I've seen different industries. CPG, mfg, and others are very old school still. Logistics moves so fast. I think it's due to how frequent feedback loops are that puts pressure on players to adopt to new tools.

More context on what I’m building:

runtm is an open-source runtime + control plane for agent-written software. It works with any AI IDE / CLI (Cursor, Claude Code, etc.), and is built around a simple belief:

If code is cheap, deployment shouldn’t be sacred.

As agents generate more software, the bottleneck stops being writing code and becomes safely turning intent into something live, observable, and disposable, without humans babysitting infra.

runtm keeps the agent loop tight:

generate → deploy → observe → adjust → repeat

Agents can redeploy repeatedly, using real production feedback, until the objective is achieved.

Quick taste:

    uv tool install runtm
    runtm login
    runtm init backend-service
    # prompt agent to write code
    runtm deploy
    # URL generated at https://<app>.runtm.com
    runtm logs

What it is:

A small set of lifecycle primitives: init, run, validate, deploy, destroy.

Opinionated templates with a stable deployment contract so agents don’t guess what prod looks like:

    name: my-api
    template: backend-service
    runtime: python
    env_schema:
      - name: DATABASE_URL
        secret: true
        required: true

Validation before deploy, so failures surface before you ship a broken container.

Guardrails:

Agents can propose capabilities; humans approve them.

An agent writes a runtm.requests.yaml like:

    I need a database
    I need STRIPE_KEY

A human runs runtm approve.

Secrets live in .env.local, which is auto-added to .*ignore. The agent cannot read them. Secrets are injected only at deploy time.

Infra (today):

Deploys to Fly.io Machines (Firecracker, auto-stop for cost control). Zero-config persistence via SQLite on a volume, or BYO Postgres. Provider layer is swappable (Cloud Run / AWS next).

Observability:

Logs, traces, and metrics via OTLP. We treat time from code to live URL as a first-class metric.

Links:

Repo: https://github.com/runtm-ai/runtm Site: https://runtm.com Quickstart: https://github.com/runtm-ai/runtm#quickstart

Question:

What is the single capability you would never allow an autonomous agent to approve on its own?

Curious where people draw the line.