The two scariest parts of autonomous agents — runaway loops and exposed APIs

Halil Agin — Sun, 12 Jul 2026 17:21:54 +0000

Everyone I talk to about autonomous agents has the same two fears, and they're both justified:

The loop runs away. You give an agent a goal, it starts iterating, and it either burns your API budget at 3am or cheerfully does the wrong thing forty times in a row.
The access problem. For an agent to do real work it needs your internal APIs — billing, inventory, the admin service that has no auth story because it was never supposed to leave localhost. Every "just expose an endpoint" answer makes your security team (rightly) say no.

I've been building rysh — an agentic terminal multiplexer where every pane
can be a shell, an agent, or a chat — and these two fears shaped two features I want to walk
through properly, because I think the mechanics matter more than the pitch. As always on
dev.to: real commands, and an honest list of what's not done at the end.

Part 1 — Loop engineering: autonomy with a leash you define

rysh has saved, reusable automations. You write the goal once, then run it with hard limits:

# save a recipe (stored under .rysh/automations/)
##auto web save scout "find the pricing page, extract the plan names and prices"

# run it — with a leash
##auto web run --budget-size 50p --max-duration 10m --takeover-when 80 scout

Three things are going on there, and each one exists because of a real failure mode:

Hard budgets, not vibes. --budget-size, --max-iterations, and --max-duration are
ceilings, not suggestions — when a ceiling is hit, the loop stops. Budgets are measured in
context tokens with units I'm unreasonably fond of: pages, books, and shelves. A page is
1,000 tokens, a book is 200 pages, a shelf is 20 books — so --budget-size 50p is a 50k-token
run and 3b (the default) is 600k. "How much should this cost?" becomes a number you set,
not a surprise you discover. There's also --passes N for fixed-round runs, --while-duration
/ --while-budget for open-ended-but-bounded work, and --dry-run to see what a recipe
would do before it does it.

LLM-judged loop conditions. The loop doesn't just count iterations — after each pass, a
judge step evaluates whether the goal is actually met. "Run until the tests pass" means
something; "run 10 times and hope" doesn't.

Graceful takeover, not a wall. --takeover-when 80 means: when 80% of any ceiling is
consumed, the run switches to a takeover leg — a wrap-up prompt you wrote (in the recipe's
takeover_prompt) takes over the remaining budget to finish cleanly: save partial results,
report what's missing, print where it stopped. The agent lands the plane instead of hitting a
wall mid-task. (Plain-language guardrails — "stop on any login wall or rate limit" — live in
the recipe prompt itself, where the agent obeys them per-step.)

The same engine fans out and schedules:

# run one recipe across a list
##auto web run --each "site-a.com,site-b.com,site-c.com" scout

# put it on a schedule — cron can fire ANY rysh input: prompts, @agent calls, shell, automations
##cron add nightly-scout "0 2 * * *" --pane scout-pane --mode rysh "##auto web run scout"
##cron next     # when does it fire?
##cron logs     # what happened last night?

And because interruptions happen, automations (and agents generally) checkpoint:

@@researcher stop        # interrupt mid-run — state is preserved
@@researcher continue    # resume from the checkpoint, not from zero

Recipes are files (this is where loop engineering gets real)

The one-liner save is just the front door. A recipe is a markdown file with YAML
frontmatter under .rysh/automations/ — versionable, reviewable, PR-able like everything
else in your repo. Here's a real one from my own setup (lightly trimmed): a scout that
browses Instagram for podcast-guest candidates on a topic, discovery-only, and saves a
shortlist to a results folder.

# .rysh/automations/webs/guest-scout.md
---
description: Discover potential podcast guests on Instagram, scoped to a topic.
  Discovery-only (never messages/follows/likes); saves a reviewed shortlist.
web_profile: ig-podcast        # persistent, pre-authenticated browser profile
url: https://www.instagram.com/
args: [topic]                  # run as: ##auto web run guest-scout tango
output_dir: guest-scout/results
loop:
  do:                          # the INNER loop — one working session
    interval: 30
    max_iterations: 300
    max_duration: 7m
    auto_continue: true
    budget:
      size: 3b                 # 3 "books" = 600k tokens, hard ceiling
      watch:
        takeover_when: 90      # at 90% consumed, switch to the wrap-up leg
        takeover_prompt: >
          The discovery budget is used up — stop browsing now. Save the
          shortlist as-is, mark it PARTIAL at the top, print the file path
          and what to cover next time.
  while:                       # the OUTER loop — repeat sessions until the GOAL holds
    enabled: true
    max_iterations: 5
    max_duration: 40m
    budget: 15b
    prompts:
      until: >
        The saved shortlist contains at least 12 strong candidates, each with
        a handle, a why-they-fit line, and a public contact or an explicit
        "on-platform only" note — with no duplicate handles.
      iterate_with: >
        Continue scouting for podcast guests about {{args}}, same rules as
        before (discovery only; stop on any login wall or rate limit). The
        current shortlist is seeded above: find NEW candidates it is missing,
        merge, and save back to the same file.
---
You are browsing Instagram looking for potential podcast GUESTS about: **{{args}}**.

If **{{args}}** is empty, ask me which topic to scout and stop — do not guess.

This is **discovery only** — do NOT message, follow, like, or DM. Just read
public pages. If you hit a login wall, captcha, or rate-limit notice: STOP
immediately and report it.

For each candidate collect: handle, why-they-fit, follower count, public
contact (or "none"), and one post that makes them relevant. Aim for 8–12.

When done, write the list as Markdown to {{output_dir}}/<topic>-<date>.md
and print the saved file path here.

Read the loop block again, because the two-level structure is the whole idea:

The do loop is one bounded working session: step interval, iteration cap, wall-clock cap, token budget — and at takeover_when: 90 the takeover_prompt takes the last 10% to finish gracefully (save partial results, say what's missing).
The while loop wraps it: after each session, the until condition is judged by the LLM against actual output — "at least 12 candidates, each with a contact, no duplicate handles" — and if it doesn't hold, iterate_with re-enters with the current shortlist seeded, under its own outer budget (15b) and iteration cap.

So the recipe encodes: what to do, when to act, when to stop, how to stop gracefully, what
"done" actually means, and how to continue if it isn't. That's what I mean by loop
engineering — the loop is data, not code, and every safety property is declared next to the
goal it protects. {{args}} templating makes one file a family of automations
(##auto web run guest-scout tango today, guest-scout "science communicators" tomorrow),
and results land in output_dir as dated markdown files you can diff.

##auto isn't just for browsers — the same save/run/schedule/budget machinery drives task,
agent, and code automations (##auto code anchors prompts to a project working directory).
Browser automations can run headless (##web headless on), so this works on a server without
a desktop session.

The design position: the interesting engineering in agent loops isn't the loop — it's the
brakes. Budgets, judges, takeover predicates, checkpoints. That's what makes "let it run
overnight" a reasonable sentence instead of a horror-story opener.

Part 2 — Forge: your private API, callable by agents, never exposed

Now the access problem. Say your team has an internal REST service on localhost:8080 —
or behind your VPN — and you want agents (yours, or a teammate's in another rysh session)
to call it. The standard options are all bad: expose it publicly behind auth you now have to
harden, hand out credentials to every agent runtime, or don't do it at all.

Here's the rysh flow. First, turn the spec into tools:

##forge add billing ./billing-openapi.yaml
##integration enable billing
# your agents can now call the billing API as ordinary tools — locally

Forge ingests the OpenAPI spec and generates governed agent tools, plus a standalone MCP
server, SDKs (Go/Python/TypeScript/Java), and docs. That alone is useful. But here's the part
I haven't seen elsewhere — share the API to another session's agents without exposing it:

# you (the API owner):
##forge share api billing

# your teammate, in their own rysh session:
##forge subscribe billing --scope pane
# their agent now sees the billing operations as normal tools

What actually happens when their agent calls one of those tools:

The subscriber side sends only the operation name + arguments over the rysh upstream (NATS over WebSocket — the same channel used for live pane sharing).
Your session receives the request, checks it against your allowlist, and — this is the key part — executes the real HTTP call locally, from your machine, where localhost:8080 actually resolves.
The response is redacted (secrets stripped) and sent back as the tool result.

The remote agent never learns the API's address. The API is never bound to a public interface.
No credentials leave your machine. The endpoint stays exactly where it was — behind your
firewall — and requests tunnel through rysh to be executed by the only party that was already
trusted to call it: you.

The safety posture, because this feature is only as good as its defaults:

Off by default. API sharing requires explicit opt-in configuration and a control-mode share — you can't leak an API by accident.
Default-deny mutations. Shared operations are read-only unless you explicitly allowlist mutating ones. A remote agent can GET /invoices; it cannot DELETE anything you didn't name.
Forge-origin only. Only Forge-generated API tools can enter the shareable set — built-in tools (bash, file access) provably cannot be shared through this path.
Redaction + rate limits. Responses pass through secret redaction before leaving your session, and the server enforces per-day quotas and rate limits on invocations.

This path is end-to-end tested and went through an adversarial security audit before I'd let
anyone use it — I'll happily go deeper on the invariants in the comments.

Honest scope note: Forge is OpenAPI-only today. gRPC ingest is a stub and there's no
GraphQL runtime. If your API has a spec, this works now; if not, not yet.

Why these two features are the same feature

Both are answers to the same question: how much power can you give an agent while keeping a
human meaningfully in control?

Loops: as much autonomy as you want, bounded by budgets and takeover legs you wrote.
APIs: as much access as you grant, executed only on your machine, read-only by default.

That's the design thesis behind rysh generally — every tool call visible in the pane, dangerous
actions gated behind approval, secrets redacted before anything leaves your session. Agents you
can trust because you can see them and bound them, not because a vendor promised.

The stack, briefly

Go; an actor runtime over NATS for all messaging (the tunneling above is "just" the same
actor/subject machinery that powers live pane sharing); Bubble Tea TUI. It runs on Anthropic
Claude — I'm not claiming a better model; the value is the governance and the surfaces around
it. Self-hostable on your own key; the provider layer is pluggable, Claude is the live backend.

What's not done (don't believe me if I imply otherwise)

Forge: OpenAPI only — gRPC ingest is a stub, no GraphQL runtime
WhatsApp / phone humanoid channels (not live)
Token-by-token streaming in the CLI (responses land on completion)
Hosted billing is gated on dev, not live

Try it / shape it

Rysh is in private beta — the code isn't public yet. It's self-hostable (you run it on
your own infra with your own Anthropic key), and access right now is through the
design-partner program: free access, a direct line to me, and your feedback sets the
roadmap. If you have one internal API you'd love agents to use safely, or one workflow you
want to run overnight on a leash, that's exactly the conversation I want:
apply to the design-partner program.

Feedback on the tunneling trust model is especially welcome — poke holes in it in the comments.

DEV Community: Halil Agin