DEV Community: Halil Agin

Meet rysh.ai: one agent engine for your terminal, browser, Slack, and website

Halil Agin — Mon, 20 Jul 2026 11:15:05 +0000

Originally published at rysh.ai/blog/meet-rysh

Your company probably runs five AIs that don't know each other exist. rysh is one agent engine for every surface — observable and owned.

Your company probably runs five AIs that don't know each other exist.

A coding assistant in the editor. A chatbot bolted onto the website. Someone's LangChain script in a cron job. A Slack bot nobody trusts. And a ChatGPT tab where the actual work happens. Five vendors, five bills, five silos — and not one of them can see what the others did.

I've been building rysh because I think that's the wrong shape entirely. Not five AIs. One agent engine, every surface.

What rysh is

rysh starts life as an agentic terminal multiplexer — think tmux or Zellij, but every pane is a conversation, not just glass in front of a shell. A pane can be:

a plain shell (it's a real terminal — vim and htop work),
an AI conversation wired to that shell, your files, and 46+ built-in tools,
an autonomous agent you spawned from a markdown file,
or a live external channel — an agent answering your email or your website chat.

You flip a single pane between shell and AI with a double-tap of Escape. Same pane, same working directory, same context. The AI isn't in another tab; it's in the terminal with you.

Getting started is one binary — the message broker is embedded, so there's no daemon zoo to stand up:

brew install rysh-ai/rysh/rysh
rysh

But the terminal is the starting surface, not the whole product. That's the part I want to be precise about, because "AI terminal" undersells what we're actually attempting.

One engine, every surface

Here's the core move. In rysh, an agent is a markdown file — persona in the body, configuration in the frontmatter, secrets as ${ENV_VAR} tokens:

---
name: support-bot
description: "Support engineer for our CLI product"
---
You are support-bot. Answer briefly, only from the product
facts below. If you don't know, say so and open a ticket.

Spawn it and it becomes a named coworker in your workspace:

##agent spawn support-bot.md
@support-bot triage the failing CI run in pane 2

That same file — the same engine underneath — can be wired to external channels as a humanoid: today that's Slack, email (IMAP/SMTP), and website chat, with WhatsApp and phone on the roadmap. The same logic that answers you in a pane answers a customer on your site. One definition, versioned in git, deployed everywhere.

And the engine's reach keeps going:

Browser — an agent can drive a real Chrome: navigate, click, extract, fill forms, with recipes written (again) in one markdown file.
Your APIs — Rysh Forge points at an OpenAPI spec and generates agent tools and an MCP server from it (GraphQL/gRPC are roadmap).
The MCP ecosystem — rysh is an MCP client, so external MCP servers' tools plug straight into the engine.
Your team — any pane can be shared live to a teammate, view-only or full control, through the collaboration server.

The unifying idea: every one of these is the same engine with the same governance. Competitors do one surface. The bet behind rysh is that the surface count is the product.

Agents you can trust because you can see them

The reason most companies keep AI at arm's length isn't capability — it's that agents run in black boxes. rysh's answer is architectural, not a dashboard bolted on later.

Every tool call an agent makes is visible in a pane, as it happens. Dangerous operations don't just execute: file edits show you a coloured diff before anything touches disk, mutating shell commands stop for explicit approval, git commit waits for a yes. Safe, read-only commands flow without friction — the allowlist is safe-by-default, not naggy-by-default.

For external channels, governance is per-channel: run a humanoid autonomous, or in draft-and-confirm mode where every outbound reply waits for a human in the terminal before it posts (live for email and website chat today). Start careful. Earn trust. Flip the switch when you're ready.

And when your agent needs to reason about credentials, SecretNAT (##snat) translates real secret values into stable tokens before anything reaches the model provider — we've verified on the wire that the provider receives the token, not the value. Your keys stay yours in the most literal sense.

You own it

The third pillar, and the one I'd argue matters most in five years: ownership.

Your agent logic lives in markdown files in your repo — reviewable in PRs, diffable, revertable. rysh is self-hostable: run it on your own machines with your own Anthropic key (rysh runs on Claude — more on why we build on the best available model rather than pretending we trained one in a separate post). Your data path is your machine → Anthropic, not your machine → our servers → who knows.

That's the difference between adopting AI and renting it.

Where this is going

I call the destination an AI-native company: agents doing real work across dev, ops, and customer support — writing code, running incident response, answering customers — with humans able to see every action, approve the risky ones, and own the logic and the data.

Most companies today are AI-painted: a chatbot on the website, a copilot in the editor, and a strategy deck. The gap between those two states is exactly the gap rysh is built to close.

We're early, and I'd rather say that plainly than hide it. Some things are shipped and filmed (we've timed brew install → agent answering on company Slack at 1 minute 47 seconds, real clock on screen). Some things are roadmap, and we label them as roadmap every time.

If the shape of this resonates — one engine, every surface, observable, owned — the best way in right now is below.

We're recruiting design partners. Hands-on early access, a direct line to the founder, and your workflow shaping the roadmap. Early is a feature: rysh.ai/design-partner

I budget my AI agents like a library — pages, books, and shelves

Halil Agin — Thu, 16 Jul 2026 10:39:40 +0000

My biggest fear with autonomous agents was never "will it work."

It was walking away. You give an agent a goal, it starts looping — browse, extract, save, judge, repeat — and the moment you close the laptop, a question starts nagging: what is this costing right now? I've checked an API dashboard at 7am the way you check your phone after a night out. Nervously.

The fix sounds boring: give the loop a budget. But when I actually tried to do that, I ran into a problem I didn't expect — and it wasn't technical.

"This run gets 600,000 tokens" means nothing

Tokens are the natural unit for LLM spend, and they are a terrible unit for humans. Quick: is 600,000 tokens a lot for a research task? Is 50,000 stingy? If a teammate says "I capped the nightly job at 2 million tokens," do you nod because you understand, or because nodding is easier?

Nobody has intuition for raw token counts. Which means token budgets don't get set — or get set once, wrong, and never touched again.

While building rysh (an agentic terminal multiplexer — every pane can be a shell, an agent, or a chat), I ended up giving agent budgets a vocabulary borrowed from reading:

1 page = 1,000 tokens — about a page of dense text, honestly
1 book = 200 pages (200k tokens)
1 shelf = 20 books (4M tokens)

So a run gets --budget-size 20p — twenty pages. My Instagram-scouting automation gets 3b — three books per session. A serious overnight job might get a shelf.

The units changed the conversation more than the enforcement did. "This run gets three books" is a sentence you can say out loud in a planning meeting, and everyone in the room has the same rough picture. "This run gets 600,000 tokens" is a number you paste into a config file and forget. Legible budgets get set, argued about, and tuned. Illegible ones rot.

(And yes — the ceiling is enforced, not advisory. The loop cannot outspend it.)

The anatomy of a budgeted loop

In rysh, an automation is a markdown file with YAML frontmatter, stored under .rysh/automations/ — so the whole loop lives in git, next to the code it serves. Here's the (trimmed) recipe for a real one I run: it scouts podcast-guest candidates on Instagram for a show, discovery-only, and saves a shortlist file.

loop:
  do:                       # inner loop — one working session
    interval: 30
    max_duration: 7m
    budget:
      size: 3b              # 3 books = 600k tokens, hard ceiling
      watch:
        takeover_when: 90   # at 90% spent, switch to the wrap-up leg
        takeover_prompt: >
          The discovery budget is used up — stop browsing now.
          Save the shortlist as-is, add a note that it is PARTIAL,
          then print the file path and what to cover next time.

  while:                    # outer loop — repeat until the goal holds
    max_iterations: 5
    max_duration: 40m
    budget: 15b             # whole job: 15 books
    prompts:
      until: >
        The saved shortlist has at least 12 strong candidates, each
        with a handle, a why-they-fit line, and a contact — no dupes.
      iterate_with: >
        Continue scouting for {{args}}. The current shortlist is
        seeded above: find what's missing, merge, save back.

Two loops, two budgets:

do is one working session. It gets its own token ceiling (3 books) and its own wall-clock cap (7 minutes). Whichever ceiling is hit first wins.
while wraps the whole job. Its budget (15 books) bounds everything the job can ever spend, across all sessions. Even if the goal is never met, the total cost has a known worst case before the job starts.

That last sentence is the whole point. You can answer "what will this cost tonight?" at review time, from the diff.

The takeover leg — because dying at 100% is also a failure

Budgeted loops usually fail in one of two default ways:

No budget → the bill surprises you.
A hard cutoff → the run dies mid-thought at 100%, and the work in flight is lost.

Both are bad, and the second one quietly teaches teams to remove budgets — which gets you back to the first one.

So the budget has a watch. takeover_when: 90 means: when 90% of the ceiling is spent, the task's own prompt is taken off the wheel and the takeover_prompt takes over — with the reserved 10% as its budget. Its job is not to make progress. Its job is to land the plane: save what exists, label it PARTIAL, note what's missing, exit clean.

The run always ends with saved, labeled output. Never a wall.

Reset and resume — the loop is interruptible by design

When a do session ends (goal-ish reached, budget spent, or clock expired), an LLM judge reads the saved output against the until: text — a stop condition that's written down in the file, reviewable in code review like everything else.

Goal met → the loop ends.
Not yet → the inner budget resets to a fresh 3 books, and the next session starts — seeded with the shortlist the last one saved (that's the iterate_with prompt). It resumes the work, not the transcript. Each pass starts with a clean context and the artifact, which is both cheaper and less noisy than dragging a 200k-token history along.

And because sessions checkpoint their state, you can interrupt the whole thing:

##auto web stop scout        # park it
##auto web continue scout    # resume from the last checkpoint, budget re-armed

stop isn't a kill. continue isn't a restart. The loop picks up where it left off, with a fresh session budget. Then you schedule it and go to sleep:

##cron add nightly-scout "0 7 * * *" ##auto web run --headless scout

Design decisions I'd defend (and what I'm less sure about)

Human units over raw tokens. Covered above, but it's the hill I'll die on: a budget nobody can reason about is a budget nobody maintains.

Percentage-based takeover over "detect when stuck." takeover_when is a number (10–99), not a natural-language predicate. Detecting "the agent is stuck" reliably is a research problem; "90% of budget is gone" is a fact. Plain-language guardrails ("stop on any login wall") live in the recipe prompt itself, where the agent applies them per-step.

Artifact-seeded resume over transcript replay. Restarting from the saved file keeps each pass cheap and forces the automation to define what "its output" actually is — which turns out to be great discipline.

What I'm less sure about: the judge. An LLM evaluating until: is far better than iteration counting, but it's still an LLM reading your criteria — vague goals get vague verdicts. Writing a crisp until: is the skill; mine took three edits before "12 strong candidates, no dupes, each with a contact" stopped being gameable.

Honest footer

rysh is my product. It's in private beta, built on Claude (bring your own Anthropic key), self-hostable — your automations are files in your repo, not rows in my database. The longer write-up, with the takeover and tunneling mechanics side by side, is here: agents on a leash

If you run agents in loops and want to kick the tires while it's early, we're onboarding design partners: rysh.ai/design-partner — or tell me why pages/books/shelves is the wrong abstraction. I've been wrong before; that's what the takeover leg is for.

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.