A week in an AI-native company: dev, ops, and support on one engine
Not a case study — a concrete, capability-accurate walkthrough of what Monday to Friday looks like when agents do real work on one governed engine.
Let me be upfront about what this is and isn't.
This is not a case study. There's no anonymized "Company X" that did all of this last quarter — we're an early-stage platform and we don't invent customers. What follows is an illustrative composite: a walkthrough of what a working week looks like when a small company runs dev, ops, and support workflows on rysh. Every capability named below ships in rysh today; the week itself is a construction to show how the pieces fit.
The point of the exercise: "AI-native" is abstract until you can picture Tuesday. So here's the week — a ~20-person product company, a few engineers, one ops-minded person, one support lead.
Monday: the team you hire from a git repo
The engineering lead opens a terminal and runs one command:
##agent spawn-all ./agents/
That folder is in the company repo. Each subfolder in it holds one agent's SKILL.md — a name, a system prompt, the behavior — versioned like any other source code. This morning it holds a code-reviewer, a test-triager, and a backlog-gardener. Spawning the team is not a procurement process; it's reading a directory.
Each agent's output is registered to a pane, next to the humans' shells, in the same multiplexer. When an engineer wants the reviewer's eyes on a change, it's one line:
@code-reviewer review the diff on this branch
The response lands in that pane. Rysh draws each tool call it makes there — the files it reads, the commands it runs. New teammates learn what the agents do the same way they learn what the humans do: by watching them work.
The backlog-gardener spends the day on the boring-but-important pile: the small refactors, the dependency bumps, the lint debt. A spawned agent has no terminal to ask from, so its tool calls run without a prompt by default; the gate lives in the panes. When an engineer hands the same chores to the agent in their own pane, it can read and search freely, but anything that writes — an edit, a commit — surfaces as a preview with a diff, waiting for a human's approval. Autonomy for the safe stuff, a gate on the rest.
Tuesday: ops that watch while you sleep
The ops engineer maintains a set of scheduled agents — ##cron entries that run checks on a cadence: build health, disk usage on the staging boxes, a morning summary of anything that drifted overnight. Each run is bounded — a cap on agent iterations, and for the ##auto recipes among them a token budget, in plain numbers the team agreed on — because an unattended agent without a budget is just a bill with initiative.
Mid-afternoon, something in staging misbehaves. The engineer investigating shares their pane with a colleague:
##share pane view
The colleague subscribes from their own terminal and watches the live investigation — the shell, the agent's analysis, all of it — without screen-share ceremony. When it makes sense to hand over the keyboard, the pane is shared in control mode instead. Human and agent output sit in the same pane, so "what happened here?" has one place to look.
Wednesday: support that drafts before it sends
The support lead runs a humanoid — an agent wired to external channels. Its definition is, again, one markdown file: the personality, the knowledge, the contacts section that connects it to the support inbox, the team's Slack, and the website chat widget.
On email, it runs in draft-and-confirm: each incoming email shows up in the terminal awaiting the support lead's word; the agent writes the reply as a draft, and nothing is sent until the support lead approves it. The customer gets a fast, well-written answer; the company gets a guarantee that no unreviewed text reaches a customer. On the internal Slack channel, the same agent answers teammates' product questions directly.
That per-channel governance dial is the whole trust model in miniature: start every channel careful, watch the drafts, grant autonomy where the evidence supports it.
Thursday: the browser is a surface too
Marketing wants a recurring research chore handled: checking a list of directories and communities for mentions and opportunities. An engineer writes it as a browser recipe — a markdown file describing the task — and runs it with ##auto web. An agent drives a real Chromium on a browser profile the team logged into once: navigating, reading, extracting, saving a shortlist to the recipe's results.
It's the same engine that ran Monday's code review, on a different surface, with a budget the runtime enforces and a human deciding what happens with the output. Discovery is automated; the humans do the outreach.
Meanwhile the CTO, traveling, checks on the week's long-running agents from a laptop with nothing installed but SSH:
ssh office 'cd acme && rysh send ops-session "status summary" --mode prompt'
The session at the office takes the prompt, and rysh attach ops-session over the same SSH shows the answer. Attach, detach, send from any shell — the agents are processes the company runs, not tabs someone forgot to keep open.
Friday: the review that makes it compound
Friday afternoon, thirty minutes, the whole AI operation in review — and because the work ran in panes and files the team could read, the review is concrete instead of vibes:
- Which approvals fired this week, and were any of them surprises?
- How did the support humanoid's email drafts hold up — is that channel ready for more autonomy, or not yet?
- Did any loop hit its budget or its takeover threshold, and why?
- What edits do the agent files need? Those changes go in as pull requests — reviewed, versioned, in the same repo as everything else.
That last part is easy to underrate. The company's accumulated judgment about how its agents should behave isn't trapped in a vendor dashboard. It's in git, growing, owned.
What the week adds up to
Notice what was absent. No black boxes: every agent was a file the team could read, and the terminal work ran in panes the team could watch. No leap-of-faith autonomy: writes in the panes were gated, customer-facing replies were drafts until earned. No integration sprawl: dev, ops, support, and browser work ran on one engine — rysh, its CLI on the company's own machines, running on Claude by default with the company's own API key — instead of four disconnected AI subscriptions with four audit stories.
And no transformation program. Just workflows, moved one at a time onto a foundation where the company could see, gate, and own the work.
That's the honest picture of AI-native: not a company run by AI, but a company where agents hold real jobs, in the open, on infrastructure and logic the company controls. The week above is illustrative — but every piece of it ships today, and assembling your version of it starts with exactly one workflow.
We're taking on a handful of design partners — companies that want to build their version of this week on real workflows, with us in the loop. If that's you: rysh.ai/design-partner.
Related: What it actually means to be an AI-native company · The governance gap